commit 5a48c828e4980d6c59335ddaf73dd5b01fabc42f Author: zemion Date: Tue Jul 21 16:34:25 2026 +0200 Sync Repo-docs-CONNECTED-GOVERNANCE-PLATFORM-ROADMAP from project files diff --git a/Repo-docs-CONNECTED-GOVERNANCE-PLATFORM-ROADMAP.-.md b/Repo-docs-CONNECTED-GOVERNANCE-PLATFORM-ROADMAP.-.md new file mode 100644 index 0000000..150dbcc --- /dev/null +++ b/Repo-docs-CONNECTED-GOVERNANCE-PLATFORM-ROADMAP.-.md @@ -0,0 +1,1405 @@ + + +> Mirrored from `/mnt/DATA/git/govoplan/docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md`. +> Origin: `repository`. +> Active tasks and changing state belong in Gitea issues; this wiki page is durable project context. + +--- +# GovOPlaN Connected Governance Platform Roadmap + +## Purpose and status + +This document describes the long-term product destination for GovOPlaN from an +outcome and stakeholder perspective. It answers what a completely connected +governance platform should enable, how the same platform can be configured for +different institutions, and which capability horizons lead from the current +baseline to that destination. + +It is a durable direction, not a release promise or a substitute for issue +tracking. Live work state belongs in Gitea issues. The +[Core master roadmap](https://git.add-ideas.de/add-ideas/govoplan-core/src/branch/main/docs/GOVOPLAN_MASTER_ROADMAP.md) +remains the technical module and wave sequence; this document supplies the +cross-product vision that sequence serves. + +Read it together with: + +- the [selected reference-journey program](REFERENCE_JOURNEY_PROGRAM.md) +- the [current capability and infrastructure fit assessment](CAPABILITY_AND_INFRASTRUCTURE_FIT.md) +- the [interface pattern language](INTERFACE_PATTERN_LANGUAGE.md) +- the [interface surface inventory](INTERFACE_SURFACE_INVENTORY.md) +- the [module contract and install model](MODULE_CONTRACTS_AND_INSTALLS.md) +- the [repository and module index](REPOSITORY_INDEX.md) +- the [Gitea issue workflow](GITEA_ISSUES.md) + +### How to read this roadmap + +- Start with the [North star](#north-star) and + [Roadmap at a glance](#roadmap-at-a-glance) for the product direction. +- Use [Perspectives](#perspectives-what-the-platform-should-feel-like) to see + how the same platform should feel to different actors. +- Use [Configurable platform visions](#configurable-platform-visions) for + service and operating configuration archetypes and + [Connected outcome stories](#connected-outcome-stories) + as end-to-end acceptance journeys. +- Use [Roadmap horizons](#roadmap-horizons) and + [Capability maturity](#capability-maturity-and-intended-direction) for + sequencing and the present-to-future boundary. +- Use [Near-term portfolio order](#near-term-portfolio-order) for the bridge to + implementation and [Product decisions](#product-decisions-to-make-progressively) + for choices that can remain deferred. +- Use the [dated snapshot appendix](#snapshot-appendix-2026-07-20) only to + understand which live backlog and release facts informed this revision. + +### Planning ownership + +| Question | Canonical source | +| --- | --- | +| What product should GovOPlaN become, for whom, in which configurations, and through which outcome horizons? | This meta roadmap | +| Which module owns a capability, which technical wave should deliver it, and what implementation gates apply? | The Core master roadmap and owning-module concepts | +| What is actively planned, blocked, implemented, or closed now? | Gitea issues | +| What can a named composition credibly claim in a target environment? | A dated capability/infrastructure fit assessment | + +The horizons and near-term order below express product outcomes and portfolio +priority. They do not replace module issue decomposition or the Core technical +wave plan. + +## North star + +GovOPlaN should become the connective, governance-aware operating layer of an +institution. + +A person should be able to request a service, participate in a decision, +respond to a scheduling request, provide evidence, or receive an outcome +without needing to understand which module or external system performs each +step. A staff member should see the current context, the next responsible task, +the authority for acting, and the likely consequence in one coherent surface. +Managers should see obligations, bottlenecks, risk, and service outcomes. +Operators should be able to explain how the configured installation works. +Auditors and affected people should be able to reconstruct consequential +decisions from source data to observed effect. + +GovOPlaN should not become a universal replacement for every ERP, DMS, +groupware suite, project system, or specialist public-sector procedure. It +should: + +1. own the governance and coordination gaps between systems; +2. provide native capabilities where a coherent GovOPlaN journey benefits from + them; +3. connect, link, import, or synchronize with an established source of truth + where replacement would be wasteful or unsafe; +4. preserve responsibility, policy, provenance, and recovery across every + boundary; and +5. package successful configurations so another institution can adopt and + adapt them safely. + +The mature product is therefore not one fixed application. It is a governed +platform from which different, internally coherent operating systems can be +composed. + +## Roadmap at a glance + +| Horizon | Product outcome | +| --- | --- | +| Current baseline | One credible Campaign-centric pilot cluster and one emerging scheduling/calendar/poll cluster on a substantial modular/governance foundation | +| Selected reference program | Campaign demonstration -> function-bound Postbox -> data-backed templates/reports -> governed BI -> collaborative documents | +| 1. Trustworthy baseline | A pinned, installable, recoverable, target-tested release with a coherent interface and explainable composition | +| 2. Human-work spine | Intake becomes owned, reviewable work with shared context, evidence, communication, and explicit external effects | +| 3. Service packages | Complete public service, internal operations, learning, meeting, and communications outcomes can be imported and adapted | +| 4. Assurance | Records, transparency, risk, export control, financial handoffs, and regulated decisions become first-class connected capabilities | +| 5. Ecosystem | Supported deployment profiles, federation, trust, protocol adapters, signed catalogs, governed data, and cross-institution operation mature | + +The central progression is: + +```text +safe modules -> connected work -> reusable services -> institutional assurance -> ecosystem +``` + +The active implementation path is the +[Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md), selected on +2026-07-21. Its five stages do not replace these product horizons: they are the +ordered demonstrations through which the shared platform contracts and horizon +gates are to be proved. Connector safety, identity/function semantics, +provenance, external-effect handling, adaptive documentation, focused UI, and +release evidence form one continuous foundation lane across all five stages. + +Each horizon retains the same design promise: configuration packages describe +the procedure that exists here; focused views describe what this actor needs +now; policy constrains what may happen; evidence explains what actually +happened. + +## What “completely connected” means + +A connected GovOPlaN installation satisfies seven promises. + +| Promise | Meaning | +| --- | --- | +| One context | A service, case, task, message, meeting, decision, document, payment, and external reference can be followed without re-entering or manually correlating the same context. | +| One responsibility model | The current actor, represented function, delegation, required review, and next responsible party remain explicit. | +| One governed effect model | Human and automated actions use the same permission, policy, consequence-preview, idempotency, audit, retry, and reconciliation rules. | +| One evidence chain | Inputs, versions, decisions, generated outputs, communications, external receipts, corrections, retention, and disclosure remain connected. | +| Many channels | Public portal, postbox, email, calendar, forms, APIs, files, and external systems are interaction channels around the same governed work, not separate silos. | +| Many sources of truth | Ownership is explicit per object or field. Native, external, and hybrid modes are supported without pretending every datum belongs in one database. | +| One explainable configuration | Users and operators can see which modules, packages, policies, connectors, and defaults produce the behavior they experience. | + +“Connected” does not mean that every user sees everything. Permission, policy, +privacy, purpose limitation, and tenant boundaries are applied before a view is +composed. Nor does it mean that every remote update is synchronous. Pending, +failed, uncertain, retried, reconciled, and manually corrected effects are +first-class states. + +## The platform model + +The product can be understood as six cooperating planes. These planes describe +responsibilities, not a new dependency hierarchy. + +| Plane | User-visible purpose | Representative capabilities | +| --- | --- | --- | +| Experience | Present only the context and tools needed for the current task while preserving an escape to the full system. | Core shell, central components, focused views, dashboard, configured documentation, accessible public and staff surfaces | +| Participation and channels | Let internal and external actors enter, receive, discuss, schedule, and respond through suitable channels. | Portal, postbox, mail, notifications, calendar, scheduling, appointments, campaign, consultation, poll | +| Work coordination | Turn an input into owned, reviewable work and make exceptions visible. | Forms/runtime, cases, tasks, approvals, workflow, booking, resources, domain modules | +| Evidence and institutional memory | Preserve what was known, decided, produced, sent, received, retained, corrected, and disclosed. | Files, templates, DMS, records, audit, search, reporting, transparency | +| Institutional governance | Establish who may act, in which capacity, for which organization and tenant, under which policy. | Identity, access, IDM, tenancy, organizations, policy, identity trust, risk/compliance | +| Integration and operations | Connect sources and destinations, operate them safely, and prove their health and recovery. | Connectors, REST/SOAP and public-sector protocols, mail/calendar/file adapters, ERP handoffs, ops, release and configuration packages | + +Across these planes, GovOPlaN should maintain a connected context graph rather +than a giant copied master record. Stable references link people and +organizations, roles and functions, services and cases, tasks and decisions, +files and records, messages and appointments, payments and external objects. +Each reference states its owner, provenance, visibility, version or concurrency +token where applicable, and lifecycle. This makes navigation and reporting +coherent without erasing domain ownership. + +## Perspectives: what the platform should feel like + +### Resident, applicant, member, supplier, or participant + +> As an external participant, I can use one comprehensible service entry point, +> provide information once, see what is required and why, respond through an +> appropriate channel, and follow the state of my matter so that institutional +> boundaries do not become my problem. + +The participant may be anonymous, locally identified, federated, represented by +another person, or associated with an organization. A configuration may expose +only a receipt and notifications, or a full portal/postbox history. Accessible +offline or assisted alternatives remain possible where policy requires them. + +### Caseworker, coordinator, clerk, or service agent + +> As the person currently responsible for work, I can open a task-focused view +> that combines the relevant case, evidence, messages, dates, decision options, +> and external-system links so that I can complete the task without hunting +> through modules. + +The interface explains missing information, blockers, authority, downstream +effects, and the next responsible actor. It does not expose unrelated modules +merely because they are installed. + +### Delegated or substitute actor + +> As a person acting for a colleague, office, or institutional function, I can +> select the represented capacity explicitly, see its time and scope limits, +> and distinguish my own identity from the authority I exercise so that +> substitution never becomes invisible impersonation. + +Permission and audit evidence record both the real actor and represented +function or account. Expiry, revocation, conflicts, and actions outside the +delegation remain visible and explainable. + +### Specialist reviewer or decision-maker + +> As a reviewer, I can see the exact material and policy basis for a proposed +> decision, request correction or additional evidence, approve within my +> authority, and record a reason so that the outcome is contestable and +> reconstructable. + +The configured model can be single-person, four-eyes, committee-based, +threshold-based, delegated, or advisory. A workflow may coordinate it later, +but the decision and evidence contracts do not depend on a workflow UI. + +### Organizer, committee clerk, or participation manager + +> As an organizer, I can assemble participants, availability, agenda material, +> consultations, votes, communications, minutes, decisions, and follow-up work +> around one institutional event so that participation leads to durable action. + +Privacy settings decide whether participants see one another, only aggregates, +or only their own response. Public publication is a separate governed effect, +not an automatic consequence of internal participation. + +### Manager and process owner + +> As a manager, I can see workload, waiting time, obligations, exceptions, +> service quality, and recurring causes across processes without gaining access +> to unnecessary case content. + +The platform distinguishes operational measures from personal performance +surveillance. Reports declare their source, freshness, filters, visibility, and +privacy classification. + +### Records, data-protection, compliance, and export-control officer + +> As an assurance officer, I can define and inspect retention, purpose, +> disclosure, screening, review, and evidence obligations across processes so +> that compliance is part of normal work rather than a disconnected +> after-the-fact exercise. + +Policy hooks can advise, require review, block an action, or create a follow-up +task. Overrides require authority, reason, and audit evidence. The underlying +domain remains responsible for its decision; compliance services do not +silently take ownership of unrelated records. + +### Tenant administrator and product configurator + +> As a configurator, I can assemble modules and connectors into a named service, +> preview the consequences, supply environment-specific values, test the +> result, and export the configuration as a versioned package so that a working +> procedure can be reviewed and reused. + +Normal configuration uses typed, guided interfaces. Secrets remain references. +High-risk changes support preflight, approval, audit, rollback or correction, +and post-change health checks. + +### Platform operator and security administrator + +> As an operator, I can see whether the installed composition, migrations, +> workers, connectors, storage, delivery queues, backups, and recovery paths are +> healthy so that failure is detected and repaired before users have to infer +> it from missing outcomes. + +Operational access is distinct from permission to read all business content. +Diagnostics minimize personal data and link to governed evidence when deeper +inspection is authorized. + +The complete installation and lifecycle journey is specified in the +[System Administrator Lifecycle User Story](SYSTEM_ADMINISTRATOR_LIFECYCLE_USER_STORY.md): +one-command Core-only bootstrap, signed online module installation and updates, +stateless scale-out, versioned configuration transfer, undo, and reproducible +environment-promotion recipes. + +### Integration owner and enterprise architect + +> As an integration owner, I can inventory external systems, declare direction +> and source-of-truth rules, test credentials and schemas, observe lag and +> conflicts, and retire a connection safely so that the organization can evolve +> its IT landscape without opaque point-to-point coupling. + +### External supplier, grantee, or institutional partner + +> As an external organization, I can submit an offer, invoice, milestone, +> evidence item, or formal response through a narrowly scoped portal, postbox, +> or API and follow only my own relationship so that cooperation does not +> require broad internal access. + +The configured relationship determines identity assurance, representation, +signing, deadlines, corrections, communication, and which internal or external +system remains authoritative. + +### Auditor, oversight body, or authorized public reviewer + +> As an authorized reviewer, I can follow a consequential outcome from source +> through policy, human or system action, observed external effects, +> reconciliation, corrections, and retention so that accountability does not +> depend on informal institutional memory. + +## Configuration dimensions + +Every packaged journey should make the following choices explicit. They are +configuration dimensions, not forks of the product. + +| Dimension | Typical choices | Required clarity | +| --- | --- | --- | +| Operational ownership | GovOPlaN-native; external source of truth; GovOPlaN record with external effect; read-only link/import; governed synchronization | Which system may create or change which state, and how conflicts are resolved | +| Identity | Local accounts; OIDC/SAML; LDAP/AD or SCIM provisioning; hybrid; service and system actors | Account correlation, deprovisioning, MFA/assurance, group mapping, delegation and break-glass behavior | +| Organization | Single office; multi-department tenant; shared-service tenant; multiple isolated tenants; cross-institution cooperation | Data boundary, role/function scope, shared objects, administration and reporting scope | +| Participant channel | Portal; postbox; email; assisted entry; API/webhook; physical/offline handoff | Receipt, identity assurance, accessibility, privacy, legal effect and fallback path | +| Decision model | Informational; advisory; one-person; four-eyes; committee; threshold escalation; policy-assisted automation | Authority, reason, review, contestability, override and correction | +| Automation | Fully manual; suggested next action; approved batch; event-driven; scheduled; automatic with exception queue | Preview, idempotency, observed effects, failure state, retry, reconciliation and responsible system actor | +| Evidence | Operational history; formal record; archive handoff; legal hold; public disclosure | Classification, retention, version, integrity, access, redaction and disposal authority | +| Privacy | Own data only; aggregates; named participants; role-limited details; purpose-specific disclosure | The minimum data shown at each surface and the policy source for broader access | +| Experience | Full module; user or role default view; manually selected view; task-suggested view; future workflow-step suggestion | Why the view is active, unsaved-work behavior, deterministic composition and full-interface escape | +| Hosting | Single-node pilot; supervised small production; horizontally scalable services; sovereign/private cloud; restricted or disconnected network | Availability, storage, secrets, observability, patching, RPO/RTO, recovery and egress constraints | +| Integration failure | Stop and block; queue and continue; permit manual fallback; accept locally then reconcile; compensate/correct | What users see, who is alerted, whether the action may proceed and how uncertainty is closed | +| Localization and policy | One language/policy set; multilingual; tenant variants; jurisdiction-specific package | Source and version of texts, forms, rules, templates, accessibility and policy interpretations | + +A package must not hide these choices behind defaults when they materially +change rights, disclosure, money, records, external effects, or responsibility. + +## Configurable platform visions + +The following configurations are deliberately overlapping. An institution may +start with one and add capabilities without replacing the platform. +They describe coherent service and operating configurations and their choices; +the later connected outcome stories describe end-to-end acceptance journeys +that one or more configurations must be able to pass. + +### 1. Controlled communications and outreach office + +**Vision.** A communications team creates a governed campaign, imports or +selects approved recipients, validates personalized content and attachments, +tests one message without consuming send state, approves the send, and follows +every recipient to a known, uncertain, reconciled, or manually resolved +outcome. + +**Perspectives.** + +- As an author, I can prepare and preview the exact communication each person + will receive. +- As a reviewer, I can distinguish test, send, resend, and recovery actions and + see their consequences before approval. +- As an operator, I can recover worker/provider uncertainty without silently + duplicating delivery. +- As a data steward, I can prove the recipient source, purpose, retention, and + disclosure path. + +**Composition.** Campaign, files, mail, addresses/distribution lists, policy, +access, audit, docs, notifications, and ops; calendar or scheduling is optional. +Mail owns profiles, credentials, protocol policy, and provider execution. +Campaign stores only the selected Mail profile reference plus its own delivery +intent and evidence; SMTP/IMAP material is never part of Campaign JSON. + +**Configuration choices.** Local lists versus CardDAV or another directory; +local files versus managed external providers; synchronous versus queued +delivery; single author versus reviewed send; visible recipient detail versus +minimized operational views; SMTP/IMAP or another future provider. + +**Roadmap role.** This is the strongest current product slice and Stage 1 of the +selected reference-journey program. It is the proving ground for shared UI +patterns, adaptive multi-perspective documentation, durable external effects, +module-owned profiles and data, audit evidence, and operator recovery. It should +become the first pinned, target-tested reference configuration rather than +expanding indefinitely into a marketing suite. + +### 2. Scheduling, meeting, and institutional decision office + +**Vision.** An organizer creates a scheduling request using an available +calendar, proposes slots, invites structured participants, collects private or +shared responses, determines a time, creates the governed calendar event, and +then carries agenda, material, decisions, minutes, and follow-up into the same +institutional context. + +**Perspectives.** + +- As an invitee, I can answer or revise my choices without learning internal + module structure. +- As an organizer, I can separate my requests from requests awaiting my answer, + understand their lifecycle, and reconcile calendar failures. +- As a committee clerk, I can turn the determined meeting into an agenda, + decision record, publication, and assigned follow-up work. +- As a participant, I see other names and response states only when the + configured privacy policy permits it. + +**Composition.** Calendar, scheduling, poll, committee, consultation, files, +templates, notifications, tasks, approvals, records, transparency, access, +policy, and audit. + +**Configuration choices.** Native or CalDAV calendar; tenant-wide scheduling +management versus organizer ownership with administrator override; aggregate, +named, or private participant visibility; advisory poll versus formal vote; +internal minutes versus public publication; manual follow-up versus later +workflow coordination. + +**Roadmap role.** Calendar, scheduling, and poll remain separate domain +capabilities. Their shared value appears in a committee/participation package, +not by merging their ownership boundaries. + +### 3. Public service from request to durable outcome + +**Vision.** A resident or organization finds a service, submits a structured +application and evidence, receives a receipt, follows requests and appointments, +and obtains a reasoned decision or permit. Staff receive owned tasks and a +coherent case view; generated documents, communication, payment evidence, +external handoffs, and retention remain linked. + +**Perspectives.** + +- As an applicant, I can understand requirements, save progress, supply missing + evidence once, and see what happens next. +- As a caseworker, I can process the current task with relevant case, form, + files, messages, dates, and specialist links in one focused view. +- As a reviewer, I can approve, return, or deny with visible authority, reason, + policy, and consequence. +- As a records officer, I can see which outputs form the formal record and when + retention, hold, archive, or disclosure rules apply. + +**Composition.** Portal, forms and forms runtime, files, cases, tasks, +approvals, templates, postbox, notifications, appointments, calendar, +permits or another domain owner, payments/ledger handoff, records, policy, +audit, docs, and eventually workflow. + +**Configuration choices.** Anonymous or authenticated intake; native portal or +external portal webhook; native case or link to a Fachverfahren; email-only +updates or trusted postbox; manual appointment or booking; external cashier/ERP +as settlement truth; one-person, four-eyes, or specialist decision; GovOPlaN +record versus DMS/archive handoff. + +**Roadmap role.** Permit-to-payment remains the primary proof that independently +installed modules can form one administrative service. Workflow is a strategic +part of the complete journey but remains deliberately outside immediate work +until it is reprioritized. + +### 4. Internal service, issue, facility, and asset operations + +**Vision.** A person reports a problem, the institution triages it to the right +service, staff or an external provider completes work, and evidence and status +are preserved. Recurring problems become visible across locations and assets +without creating disconnected ticket systems. + +**Perspectives.** + +- As a reporter, I receive a receipt and useful status without seeing internal + assignment detail. +- As a triage agent, I can classify, merge, route, or escalate with suggested + context and visible service commitments. +- As a technician, I see the location, asset, safety information, appointment, + files, and exact task needed in a field-appropriate view. +- As a manager, I can distinguish demand, backlog, SLA risk, recurring cause, + and verified resolution. + +**Composition.** Issue reporting, helpdesk, cases, tasks, facilities, assets, +inspections, booking, resources, calendar, files, notifications, connectors, +reporting, policy, and audit. + +**Configuration choices.** Native task execution versus OpenProject/Jira/ +Redmine link; anonymous versus identified reporting; public status versus +private updates; internal team versus contractor handoff; asset registry native +or external; reactive incident versus scheduled inspection. + +**Roadmap role.** “Report to resolution” should be one package with optional +domain branches, preventing helpdesk, facilities, assets, inspections, and +issue reporting from becoming parallel silos. + +### 5. Training, booking, and verifiable credentials + +**Vision.** An institution plans a course, reserves rooms and equipment, +registers or assigns participants, records attendance and evaluation, issues a +versioned certificate, and retains proof under the appropriate policy. + +**Perspectives.** + +- As a participant, I can discover an eligible offering, register, receive + schedule changes, and retrieve my certificate. +- As an organizer, I can see capacity, room, trainer, resource, participant, + wait-list, and exception state in one view. +- As an issuer, I can prove the criteria, template version, authority, and + issuance or revocation history of a credential. + +**Composition.** Learning, booking, resources, facilities, calendar, +scheduling, forms/runtime, evaluation, notifications, files, templates, +certificates, identity trust, records, reporting, policy, and audit. + +**Configuration choices.** Public registration versus assignment; individual +calendar versus shared roster; internal room/resource truth versus external +booking system; attendance-only versus assessed completion; printable, +digitally verifiable, expiring, or revocable credential. + +**Roadmap role.** This is a bounded administration journey, not a commitment to +build a general learning-management system. + +### 6. Export control, sanctions screening, and governed compliance + +**Vision.** Before a configured high-risk action involving a person or +organization proceeds, GovOPlaN can request screening against approved embargo +or sanctions sources, route possible matches for qualified review, preserve the +source/list/version and matching evidence, and apply a policy outcome without +silently making a legal determination. + +**Perspectives.** + +- As a caseworker or buyer, I know whether screening is required and whether I + may proceed, must wait for review, or need corrected subject data. +- As an export-control officer, I can review exact and fuzzy candidates, + aliases, identifiers, jurisdictions, list provenance, confidence factors, and + prior decisions without unrelated case data. +- As an approver, I can record false positive, confirmed match, insufficient + data, approved exception, or escalation with reason and authority. +- As an auditor, I can prove which list version and subject data were screened, + who decided, whether a later list update caused rescreening, and which action + was allowed or blocked. + +**Potential composition.** The owning repository and exact integration shape +remain an explicit product decision under the meta story. Likely collaborators +include identity/organizations, risk/compliance, cases, tasks, approvals, +policy, audit, records, reporting, and provider/list connectors. Configured +consumer modules such as procurement, contracts, grants, payments, or permits +could request a provider-neutral capability through a versioned contract; +consumer modules must not own the general screening story. + +**Configuration choices.** Internal list mirror versus external screening +provider; exact identifiers versus transliteration/fuzzy matching; advisory, +review-required, or blocking policy; one-person versus four-eyes disposition; +screen once versus rescreen on subject/list/action changes; per-purpose data +minimization and retention; offline/manual fallback versus hard stop. + +**Required safety properties.** Authoritative source provenance, list freshness +and failure visibility, reproducible matching inputs, explicit non-match limits, +human resolution of ambiguous candidates, separation of subject and reviewer +access, no hidden cross-module coupling, correction rather than fictional undo, +and a durable action/effect trail. + +**Roadmap role.** The canonical product story is +[meta issue #12](https://git.add-ideas.de/add-ideas/govoplan/issues/12). It is a +future cross-product configuration and contract program, not Campaign work and +not a claim that screening is implemented today. + +### 7. Records, transparency, and accountable institutional memory + +**Vision.** Operational evidence becomes a classified record when required, +remains under retention or legal hold, can be transferred to a DMS/archive, and +can later support a controlled access or disclosure request without losing +decision context. + +**Perspectives.** + +- As a records officer, I can apply file-plan and retention rules without + taking over daily domain work. +- As a disclosure officer, I can collect responsive material, review access and + exemptions, redact, approve, publish or deliver, and preserve the disclosure + decision. +- As an affected person or authorized public requester, I receive a clear, + traceable response through the configured channel. + +**Composition.** Records, DMS, files, search, transparency, cases, tasks, +approvals, templates, portal/postbox, policy, audit, connectors, and reporting. + +**Configuration choices.** GovOPlaN as record store versus external DMS/archive; +automatic classification suggestion versus explicit declaration; retention by +record class/tenant/purpose; internal access request versus public information +request; redaction and publication review depth. + +**Roadmap role.** This horizon turns operational traceability into institutional +memory. It should follow stable domain references and work/evidence contracts, +not be bolted onto every module independently. + +### 8. Integration overlay for an existing institutional stack + +**Vision.** An institution keeps its identity provider, groupware, DMS, +OpenProject, ERP, portals, and Fachverfahren while GovOPlaN supplies a coherent +service directory, governed handoffs, cross-system tasks and evidence, health +visibility, and selected missing workflows. + +**Perspectives.** + +- As an enterprise architect, I can see the system inventory, source-of-truth + rules, supported directions, authentication, data classes, and failure modes. +- As a user, I can follow an external object from my task and return without + losing context. +- As an operator, I can see stale synchronization, rejected payloads, + certificate expiry, webhook loss, and manual recovery work. +- As a process owner, I can replace one weak handoff without commissioning a + wholesale migration. +- As a data/reporting steward, I can see source lineage, freshness, schema and + quality warnings, access classification, and publication history without + turning integration logs into an uncontrolled analytics store. + +**Composition.** Connectors, IDM/access, mail, calendar, files/DMS, tasks, +search, reporting, ops, audit, REST/SOAP, FIT-Connect, XTA/OSCI, XÖV, +XRechnung, and domain-specific adapters as justified. + +**Configuration choices.** Link, import, publish, synchronize, or replace a +selected workflow; polling versus webhook; service versus delegated user +credentials; cached metadata versus replicated object; stop, queue, manual +fallback, or reconcile on failure; OpenDesk profile versus another landscape. + +**Roadmap role.** Connector-first is the default. A new native domain module is +justified only when several real deployments prove that stable GovOPlaN-owned +semantics exist beyond cases, tasks, forms, files, and workflow. + +### 9. Association and nonprofit governance + +**Vision.** A smaller institution coordinates boards, working groups, members +or stakeholders, events, communications, grants, decisions, and follow-up work +with the same governance and evidence quality as a larger administration, but +without exposing enterprise-scale complexity. + +**Perspectives.** + +- As a volunteer board member, I see the meetings, papers, declarations, + decisions, and tasks relevant to my current function. +- As an office coordinator, I can maintain governed contacts, invite a body, + prepare papers, collect votes, approve minutes, and communicate outcomes. +- As a funder or partner, I can submit and receive evidence through a narrowly + scoped relationship surface. + +**Composition.** Organizations, addresses/distribution lists, committee, +scheduling, poll, campaign, files, approvals, tasks, records, grants, booking, +learning, certificates, policy, and audit as needed. + +**Configuration choices.** Member/participant data native or imported; +volunteer functions and substitution; formal versus informal decision rules; +internal versus public minutes; simple accounting handoff; single-tenant local +operation versus a hosted shared service. + +**Roadmap role.** GovOPlaN does not yet own membership, dues, or donor +semantics. The first package should prove whether organizations, addresses, +distribution lists, cases, grants, and payment/ledger connectors are sufficient +before a new membership module is justified. + +### 10. Multi-tenant shared governance service + +**Vision.** A central operator offers approved GovOPlaN services to several +legally or organizationally separate institutions. Each tenant receives its +own roles, connectors, policies, records, views, and service packages while the +operator governs supported versions, infrastructure, and system-level safety. + +**Perspectives.** + +- As a tenant administrator, I can narrow system policy and configure my + institution without seeing or affecting another tenant. +- As a shared-service operator, I can roll out a tested package version, inspect + health and capacity, and recover infrastructure without routine access to + tenant business content. +- As an auditor, I can distinguish system administration, tenant + administration, delegated support, and cross-tenant incidents. + +**Composition.** Tenancy, organizations, identity/access/IDM, policy, audit, +admin, ops, docs, signed catalogs/configuration packages, tenant-scoped +connectors, and whichever service packages are approved. + +**Configuration choices.** Dedicated versus shared infrastructure; tenant +encryption and key boundaries; centralized versus tenant-owned identity and +connectors; system policy ceiling and tenant narrowing; support access; +capacity, residency, recovery, and upgrade channels. + +**Roadmap role.** Multi-tenancy is already an architectural foundation, but a +supported shared service requires explicit isolation, operation, recovery, +support, and assurance proof rather than only tenant-scoped tables. + +### 11. Procurement, contracts, grants, and obligation oversight + +**Vision.** A need, funding decision, procurement, award, contract, grant, +invoice, payment handoff, and continuing obligation remain connected without +requiring GovOPlaN to replace the institution's finance or procurement system. + +**Perspectives.** + +- As a requester or grant officer, I can state the need, funding source, + criteria, timetable, evidence, and expected outcome once. +- As a procurement or compliance reviewer, I can inspect conflicts, + thresholds, screening, required competition, approvals, and exception + reasons before an award or payment effect. +- As an approver, I see budget/authority context, four-eyes requirements, + irreversible handoffs, and the exact documents or commitments being approved. +- As a supplier or grantee, I can submit offers, invoices, milestones, and + evidence through my scoped relationship surface. +- As a contract owner or auditor, I can follow deliverables, changes, + obligations, invoices, payments, expiry, retention, and external ERP evidence. + +**Potential composition.** Forms/runtime, cases, tasks, approvals, +procurement, contracts, grants, organizations, files, templates, +risk/compliance, optional export-control screening, XRechnung, payments, +ledger/ERP connectors, records, reporting, policy, and audit. + +**Configuration choices.** GovOPlaN-owned intake/oversight versus external +e-procurement/ERP truth; value and jurisdiction thresholds; competitive, +direct-award, framework, or grant paths; advisory versus blocking controls; +one-person, four-eyes, or committee approval; native versus external contract +register; batch/file/API financial handoff; public award publication and +commercial-confidentiality rules. + +**Roadmap role.** GovOPlaN should own the governed context, approvals, +obligations, exceptions, and evidence that cross systems. Settlement, general +ledger, tax, and broad procurement semantics remain connector-first unless a +bounded reference package proves a narrower native responsibility. + +### 12. Public consultation from proposal to accountable response + +**Vision.** An institution can publish a proposal, invite affected groups, +collect accessible structured and free-form input, hold hearings, analyze +themes, answer material comments, make a reasoned decision, assign follow-up, +and publish a durable outcome without exposing restricted submissions. + +**Perspectives.** + +- As a participant, I can understand the proposal, eligibility, use of my data, + deadline, visibility, and how the institution will respond before I submit. +- As a consultation manager, I can combine portal responses, invited + stakeholders, hearings, files, campaigns, and reminders in one governed + process. +- As an analyst or policy owner, I can build a response matrix that preserves + source and redaction while distinguishing evidence, opinion, duplication, + and unresolved questions. +- As a committee member or decision-maker, I can see the proposal, summarized + and source material, conflicts, consultation response, policy basis, and + consequence before deciding. +- As the public or an oversight body, I can reach the approved outcome, + response reasoning, minutes, and follow-up status permitted for publication. + +**Potential composition.** Portal, forms/runtime, consultation, organizations, +addresses, campaign, scheduling, calendar, poll, committee, files, tasks, +approvals, templates, transparency, records, reporting, policy, and audit. + +**Configuration choices.** Anonymous, signed-link, federated, or represented +participation; public, confidential, or mixed submissions; named versus +aggregate visibility; open consultation versus selected stakeholders; +advisory input versus formal hearing/vote; moderation and redaction; multilingual +publication; manual or future workflow coordination. + +**Roadmap role.** Participation is not only a form or a poll. The complete +configuration must connect invitation, accessibility, evidence, analysis, +institutional response, decision, follow-up, publication, and records while +keeping their distinct authorities visible. + +## Connected outcome stories + +These are product stories against which module work and configuration packages +can be tested. + +### Story A: from request to decision, effect, and record + +1. An input arrives through a portal, postbox, email-assisted entry, API, or + external specialist system. +2. The platform verifies the actor/channel context and produces a receipt. +3. Form data and files become a case or domain record with explicit provenance. +4. A task-focused view gives the responsible worker the relevant evidence and + next valid decisions. +5. Missing information, specialist review, appointment, approval, screening, + or payment becomes visible work rather than hidden state. +6. The decision surface shows authority, policy, consequences, downstream + effects, reversibility, and evidence before execution. +7. Native and external effects are committed durably, retried idempotently, and + reconciled when their outcome is uncertain. +8. The participant receives the configured notification or postbox message. +9. The formal output and relevant evidence enter records/retention or an + external DMS/archive handoff. +10. Status, reporting, audit, correction, appeal, and disclosure follow the + same connected references. + +### Story B: from meeting need to accountable institutional action + +1. An organizer selects an available calendar and proposes candidate slots. +2. Participants respond under the configured privacy model. +3. A time is determined and the calendar operation reaches a reconciled state. +4. Agenda items, supporting files, conflicts, and decisions are prepared. +5. The meeting records attendance, votes or consensus, reasons, and minutes. +6. Decisions create assigned follow-up tasks or governed external actions. +7. Approved minutes or decisions are retained and, where configured, + published through transparency/portal channels. + +### Story C: from campaign intent to known delivery outcome + +1. An authorized author selects governed source data, files, template, and + delivery policy. +2. Validation and preview show exact per-recipient effects and blockers. +3. Test-send evidence does not consume the unsent state. +4. Approved single or batch sends create immutable execution intent. +5. Workers and providers report observed effects; unknown outcomes do not + trigger blind duplicates. +6. Retry, resend, reconciliation, and correction remain distinct, authorized, + and auditable. +7. Reports and retention preserve only the personal detail needed by each + role. + +### Story D: from report to verified resolution + +1. A report is received and correlated with location, facility, asset, service, + or prior reports. +2. Triage identifies the responsible queue and urgency without exposing + restricted details. +3. Native tasks or external work packages carry execution. +4. The reporter receives suitable progress; staff see SLA and exception state. +5. Completion requires the configured evidence or inspection. +6. Recurring causes inform reporting, maintenance planning, and service design. + +### Story E: from obligation to screening and controlled action + +1. A domain action declares the subject, purpose, jurisdiction, and required + screening policy. +2. The screening service records normalized inputs and the authoritative source + or provider version. +3. Clear non-candidates may satisfy an advisory policy; possible matches create + qualified review work. +4. A reviewer records disposition, evidence, expiry/rescreen conditions, and + any required second approval. +5. The requesting action proceeds, remains blocked, or is corrected according + to the effective policy. +6. List or subject changes can trigger targeted rescreening without rewriting + the original decision history. + +### Story F: from configuration package to explainable service + +1. An operator selects a trusted versioned service package. +2. GovOPlaN explains required modules, versions, capabilities, connectors, + policies, data, secrets, and deployment assumptions. +3. A guided preflight discovers or collects only the environment-specific + values needed. +4. Dry-run shows creates, updates, bindings, conflicts, irreversible effects, + missing authority, and rollback/correction paths. +5. Approved providers apply their own fragments idempotently. +6. Post-apply health checks prove the configured journey, not merely installed + code. +7. Configured documentation explains the resulting service to each role. +8. The configuration can later be upgraded, compared, exported, or retired + with provenance. + +### Story G: from institutional need to obligation and settlement evidence + +1. A need or funding opportunity enters with ownership, criteria, timetable, + budget reference, and supporting evidence. +2. The configured procurement/grant path identifies competition, screening, + conflict, threshold, review, and publication requirements. +3. Offers or applications arrive through a scoped channel and become + comparable without losing their original evidence. +4. Review and approval show authority, reasons, conditions, commitments, and + irreversible downstream effects. +5. Award, contract, grant, or rejection communications are delivered and + reconciled. +6. Deliverables, changes, milestones, invoices, and exceptions become owned + work against the same obligation context. +7. Payment/accounting handoffs are idempotent and retain external ERP or + provider references; GovOPlaN does not claim settlement from a request alone. +8. Completion, expiry, retention, audit, reporting, and configured publication + preserve the connected institutional record. + +### Story H: from public proposal to reasoned response and follow-up + +1. A proposal is published with scope, authority, accessible material, + participation rules, privacy, and deadline. +2. Individuals and organizations contribute through configured public, + confidential, signed-link, account, hearing, or assisted channels. +3. Every submission receives a receipt and retains its provenance and allowed + visibility. +4. Analysis groups themes and duplicates while preserving a path to source + evidence and recording redactions or exclusions. +5. A response matrix records how material input was considered and which + questions remain unresolved. +6. The decision-maker receives the proposal, participation evidence, + conflicts, policy basis, consequences, and response reasoning. +7. The approved decision creates follow-up work and a governed publication or + notification effect. +8. Minutes, responses, decision, publication, corrections, and records remain + connected for participants and oversight under their respective access. + +### Story I: from sender to current institutional responsibility + +1. A sender selects a governed delivery target: a Postbox or a function in an + organizational unit, not the name or email address of its current holder. +2. Organizations, Identity, IDM, and Access resolve the target and current + acting context through their owned contracts. +3. Postbox accepts one durable message and attachment references and returns a + delivery receipt; Campaign or another sender retains only typed references. +4. An authorized function holder or delegate discovers and handles the message. +5. Vacancy, ambiguity, expiry, or unavailable dependencies create visible safe + states rather than an implicit personal fallback. +6. Reassignment changes future access without moving or rewriting the message; + delivery, access, and correction evidence remains connected. + +### Story J: from specialist-system context to reproducible document + +1. An authenticated user follows an opaque, short-lived launch reference from + HIS or another source system to a GovOPlaN report/document task. +2. GovOPlaN re-authorizes the actor and resolves a curated, versioned source + context server-side; URLs contain neither credentials nor trusted raw data. +3. The user sees source, freshness, parameters, template/report version, and + blockers before generation. +4. Templates renders or Reporting executes from a validated input snapshot; + Files stores the immutable output and checksum. +5. The result is linked or returned through an explicit idempotent contract. +6. Provenance explains exactly which source, data version, transformation, + definition, actor, and policy produced the artifact. + +### Story K: from operational sources to trusted institutional indicator + +1. A governed catalog declares source owner, purpose, classification, schema, + extraction mode, reporting-date semantics, freshness, and credentials. +2. An ingestion run stages a snapshot or watermark and records schema drift, + validation findings, quarantine, and replay evidence. +3. Versioned transformations map official keys, organizational hierarchies, + time dimensions, and measures into a documented analytical data product. +4. Reporting serves policy-aware aggregates and permitted drill-down with the + calculation and lineage visible. +5. Scheduled outputs, APIs, templates, or open-data handoffs use the same + product version rather than reimplementing the calculation. +6. Package promotion reproduces the accepted report in development, test, and + production; corrections create new evidence rather than rewriting history. + +### Story L: from generated artifact to approved collaborative record + +1. An uploaded file or generated template/report becomes a DMS document with a + stable identity and first version. +2. Authorized actors receive an editing session or controlled check-out under + current permission and document policy. +3. Concurrent or stale saves cannot silently overwrite accepted work; comments, + comparison, locks, and recovery make conflicts understandable. +4. Review and approval freeze an immutable rendition with actor, version, + content checksum, and decision evidence. +5. Postbox, Campaign, Cases, or another module links the document through a + typed reference rather than copying its lifecycle. +6. Records classifies and retains the accepted rendition while Files remains + the storage owner and an external editor remains only a connector. + +## Roadmap horizons + +Horizons are ordered by dependency and product confidence, not calendar dates. +Work may proceed in parallel when it does not bypass a gate. A horizon is +complete when its user and operator outcome is demonstrated in a pinned +composition, not when all named repositories contain scaffolding. + +Reference-program stage numbers are delivery order, not alternative maturity +horizons. Campaign primarily proves Horizon 1; function-bound Postbox and the +manual responsibility spine prove Horizon 2; templates/report launches and the +first analytical product prove Horizons 2 and 3; governed BI adds assurance and +ecosystem capabilities across Horizons 3–5; collaborative documents combine +the evidence spine, service packages, and records assurance across Horizons +2–4. The detailed mapping and gates are in the +[Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md). + +### Current baseline: modular pilot foundations + +The current product has credible foundations in module discovery and +composition, local tenancy/identity/access, policy and audit contracts, +Campaign authoring/delivery controls, managed files, mail integration code, +calendar/scheduling/poll capabilities, shared WebUI primitives, configured +documentation, and operational status surfaces. + +The strongest evidence is still a controlled Campaign-centric pilot. Several +external adapters are implemented but unproved against a target environment; +many domain repositories are concepts or first-slice scaffolds rather than +end-to-end product capabilities. The capability fit assessment remains the +controlled source for claims and must be refreshed against a clean, pinned +release after recent integrated work. + +### Horizon 1: trustworthy, reproducible product baseline + +**Outcome.** A bounded installation can be installed, upgraded, operated, +recovered, and evaluated as a release rather than as a collection of source +checkouts. + +Priorities: + +1. Deliver the first slices of the + [System Administrator Lifecycle User Story](SYSTEM_ADMINISTRATOR_LIFECYCLE_USER_STORY.md): + a verified Core-only distribution, first-run control plane, read-only online + module directory, and durable plan/confirm/install progress. +2. Pin and publish a compatible Core/WebUI/module composition and first + reference configuration package. +3. Complete database, files, configuration, secrets, and audit backup/restore + drills with measured recovery objectives. +4. Prove the providers required by the selected reference configurations, + beginning with Campaign's Mail-owned SMTP/IMAP profile, CalDAV, and the + relevant broker/worker and file or directory adapters, including fail-closed + destination pinning and reconciliation behavior. +5. Add external monitoring, alerting, audit export/retention, deployment + hardening, and incident/runbook evidence. +6. Apply the interface pattern language first to Campaign, scheduling, and + admin/configuration. Existing central components are mandatory; any custom + control needs prior product-owner authorization and a narrow recorded scope. + Extend central contracts only after a repeated need is demonstrated. Make + Campaign, Mail, and Files the first complete adaptive, multi-perspective + documentation set. +7. Align executable WebUI contributions with manifest/configured-system + metadata and make focused views manually/default selectable without waiting + for Workflow. +8. Refresh the capability/infrastructure assessment and distinguish code-tested, + target-tested, package-integrated, pilot-approved, and production-approved + evidence. + +**Gate.** A clean release candidate can be installed and restored; the +Campaign reference journey uses only Mail-owned profiles and it and one +external calendar operation survive provider/worker failure without duplicate +or unexplained effects; the UI, adaptive documentation, and operator evidence +are reproducible. + +### Horizon 2: shared human-work and evidence spine + +**Outcome.** Inputs from different channels become owned work with a coherent +context, review path, communication, and evidence chain even before rich +cross-module automation is enabled. + +Priorities: + +1. Deliver the selected function-bound Postbox path from a Campaign delivery + target through Organizations, Identity, IDM, and Access into visible, + assigned responsibility. Extend from that proven path to forms/runtime, + cases, approval, notification, search, and record references only as a + selected journey requires them. +2. Stabilize actor/function/delegation, tenant/organization, permission, policy, + privacy, and audit contracts across those modules. +3. Establish generic external-reference, action/effect, command, outbox, + idempotency, retry, quarantine, reconciliation, and manual-intervention + contracts from proven Campaign and Calendar behavior. +4. Implement connector inventory/profiles, source-of-truth declarations, + health, secret references, webhooks/polling evidence, and lifecycle. + Connector/provider deletion and destructive module retirement immediately + remove provider-owned secrets and emit non-secret audit evidence; failed + external-secret deletion fails closed. +5. Let modules contribute object regions, actions, work items, and focused-view + fragments through Core without optional sibling imports. +6. Expand configuration-package providers, dry-run, apply, export, upgrade, + provenance, and configured documentation. + +Workflow remains a long-term coordination capability, but implementation of +workflow-driven stories is deliberately deferred until reprioritized. This +horizon should make manual work, views, contracts, and evidence strong enough +that Workflow later coordinates stable actions rather than inventing them. + +**Gate.** One Campaign message can reach a function-bound Postbox and follow +current assignment/delegation without personal mailbox ownership; one incoming +submission can create or link a case, appear as assigned work, be reviewed +through a focused view, produce a governed communication and document, and +remain traceable with and without optional modules installed. + +### Horizon 3: reusable end-to-end service packages + +**Outcome.** Institutions adopt complete outcomes, not hand-assembled module +lists. + +Priorities: + +- Consolidate controlled communications as the first hardened reusable + package. +- Deliver data-backed template/report generation with a safe HIS-style deep + launch as the next selected package proof. +- Grow that source contract into one bounded, governed university analytical + data product before opening a general-purpose BI/dataflow program. +- Follow with the collaborative document journey once generation, storage, + provenance, and DMS lifecycle boundaries are stable. +- Add further candidates only after the selected package proves the shared + spine rather than advancing all domain repositories horizontally. +- Add Workflow transition/action execution only where a stable package proves + coordination value and the postponed program is explicitly resumed. +- Give every package onboarding, acceptance tests, role-specific focused views, + configured help, sample/reference data, migration, and health evidence. + +**Gate.** At least two materially different reference deployments can import +and adapt a package without code forks, while choosing native/external/hybrid +sources and retaining the same safety and evidence guarantees. Adoption by two +real institutions is stronger later evidence, not an engineering prerequisite. + +### Horizon 4: institutional assurance, records, and regulated decisions + +**Outcome.** Operational work, institutional memory, transparency, privacy, +risk, and regulated review form one explainable system without collapsing +their distinct authorities. + +Priorities: + +1. Records classification, retention, legal hold, disposal, DMS/archive + handoff, and restoration evidence. +2. Controlled disclosure, redaction, publication, access requests, and + transparency reporting. +3. Risk registers, controls, incidents, audit measures, approvals, and + compliance evidence linked to real operational objects. +4. Export-control/sanctions provider contracts, list provenance, matching, + review, policy hooks, rescreening, evidence, and reporting. +5. Procurement, contracts, grants, payments, ledger, and ERP handoffs with + four-eyes and durable external-effect controls. +6. Stronger identity assurance, function-bound postboxes, and trust/signature + references where a real journey requires them. + +**Gate.** A regulated cross-module decision can be reconstructed, reviewed, +corrected, retained, and disclosed under policy; unavailable providers or +ambiguous matches create visible safe work rather than guessed outcomes. + +### Horizon 5: federated governance ecosystem + +**Outcome.** GovOPlaN can serve multiple institutions and infrastructure +profiles as a scalable, portable ecosystem while preserving local sovereignty +and explainability. + +Priorities: + +1. Production distributions for small, high-availability, private-cloud, and + restricted-network profiles with tested scaling and disaster recovery. +2. Federated identity, cross-organization trust/delegation, and eventually + end-to-end-encryption-compatible role/function postboxes. +3. Mature public-sector protocol adapters and conformance evidence where real + deployments justify them. +4. Signed module and configuration catalogs, compatibility policy, long-term + support channels, reproducible upgrades, and a governed package ecosystem. +5. Cross-process reporting, lineage-aware data products, open-data + publication, and privacy-preserving aggregates. +6. Optional assistive search, summarization, classification, or decision + support only after provenance, human review, model/data policy, and + contestability contracts exist. Automated legal or rights-affecting + decisions are not an assumed product destination. + +**Gate.** An institution can move a governed service package between supported +environments, connect local systems, cooperate across an explicit trust +boundary, and retain operational, security, and evidence guarantees. + +## Capability maturity and intended direction + +| Capability family | Current posture | Next proof | Long-term role | +| --- | --- | --- | --- | +| Module/runtime composition | Implemented foundation with contract checks | Pinned release and package compatibility proof | Safe platform and ecosystem runtime | +| Tenancy, identity, access, policy, audit | Useful local foundation | Actor/function/delegation, audit retention/export and target security proof | Institutional authority and accountability plane; federation later | +| Campaign/files/mail | Strongest connected slice; Mail-profile-only boundary and target provider proof remain | Reference package, adaptive docs, UI acceptance, real delivery/recovery drill | Governed communications capability and demonstration composition | +| Calendar/scheduling/poll | Integrated domain foundations; target calendar and broader product acceptance remain | Accept implemented picker, participant privacy/policy hooks, lifecycle, response editing and CalDAV recovery; decide management ownership | Shared time, participation, and decision primitives | +| Notifications | Inbox and dispatch/recovery foundation; external Mail handoff is not integrated | Mail provider proof, unified-inbox contribution and delivery-state UX | Cross-channel attention and delivery coordination | +| Addresses and directories | Implemented adapters exist but configuration/target proof varies | Directory source, privacy, conflict and lifecycle package | Reusable people/contact source capability | +| Docs/admin/ops/dashboard | Useful cross-product surfaces with incomplete rollout | Configured-system inventory, guided config, monitoring/recovery evidence | Explainability and operation of the configured product | +| Organizations/identity/IDM/access/postbox | Normalized ownership concepts and uneven runtime slices | Function-bound delivery, reassignment/delegation, vacancy and access-evidence proof | Institutional responsibility and durable communication spine | +| Forms/cases/tasks/approvals/search | Concepts and uneven first slices | Extend the proven responsibility path into one manual end-to-end work/evidence journey | Reusable administrative coordination layer | +| Templates/reporting/data sources | Boundary concepts or scaffolds | One reproducible data-backed document/report and safe HIS-style launch | Governed document production, reports, dashboards, and analytical consumption | +| Analytical data products/dataflow | Selected direction; platform contracts not yet implemented | One bounded university source-to-indicator path with staging, quality, lineage and promotion proof | Transparent institutional BI and cross-process reporting | +| DMS/collaborative editing | Boundary concept and tag-only scaffold | One Files-backed version lifecycle, then one provider-neutral editing session | Collaborative documents, review, approval and records-ready renditions | +| Workflow/automation | Concept only; no discoverable Workflow runtime; program postponed | Stable action/effect providers and an explicitly reprioritized bounded journey | Configurable governed process coordination | +| Domain modules | Mostly boundary concepts or seeds | Only the modules required by a reference package | Reusable semantics above the shared spine | +| Connectors and protocols | Catalogue/strategy plus several module-specific adapters | Profile/runtime, source-of-truth, health and one real landscape | Coexistence with institutional IT | +| Records/transparency/risk-compliance/export screening | Planned or early concepts | Evidence contracts and one regulated reference story | Institutional memory, oversight, and assurance | +| Release/configuration ecosystem | Core foundations and meta tooling | First signed/pinned configuration and supported distribution | Portable, governable service packages | + +Repository existence is not evidence of capability maturity. Product claims +must refer to code, contracts, tests, configured composition, operational +drills, and target-environment evidence appropriate to the claim. + +## Portfolio sequencing rules + +1. Prioritize an actor outcome and reference journey, not a repository. +2. Stabilize shared contracts through a real vertical slice before extracting a + platform abstraction. +3. Prefer a connector when an established specialist system should remain the + source of truth. +4. Keep domain semantics with the owning module and optional composition behind + Core-mediated contracts. +5. Ship quiet, task-focused surfaces; installed capability is not a reason to + display every module at once. +6. Treat privacy, access, policy, evidence, retention, failure, and correction + as part of the slice, not later hardening. +7. Distinguish requested action, durable intent, observed effect, and + reconciled outcome whenever an external system is involved. +8. Require configuration-package and operator proof before calling a group of + modules a product configuration. +9. Keep active implementation detail in Gitea; update this roadmap only when + product direction, sequence, or a durable boundary changes. +10. Do not open implementation programs for later horizons merely to populate + every repository. + +## Definition of a connected journey increment + +A connected journey increment may—and should—arrive through a sequence of +small, reviewable, green commits. Each commit stays bounded, preserves module +contracts, includes proportionate tests, and records any durable contract or +behavior change. A single commit need not contain an entire package, runbook, +or release proof. + +Before the combined increment is described as a connected product outcome, it +provides all applicable evidence below. + +- A named actor can achieve a bounded outcome through a documented happy path. +- The domain owner and native/external/hybrid source-of-truth rule are explicit. +- Required and optional module contracts are versioned and permutation-tested; + optional siblings are not directly imported. +- Permissions, represented function/delegation, policy, privacy, tenant, and + organization boundaries are exercised. +- The UI uses mandatory central components and the applicable surface + archetype, states, wording, action order, focused-view behavior, + accessibility, and responsive rules. Any custom component has prior + product-owner authorization and a narrow documented purpose and scope. +- Consequential actions preview context, authority, effects, reversibility, + blockers, policy source, and evidence. +- Local state and external intent are durable. Redelivery of the same command + with the same idempotency key does not duplicate its effect; a deliberate + later action is a new auditable command where the domain permits it. Retry, + uncertainty, reconciliation, correction, and manual intervention are + explicit. +- Audit and provenance connect source input, versions, actor/system trigger, + decisions, observed effects, and later corrections. +- Files, records, retention, disclosure, and data minimization are classified + where applicable. +- Empty, unavailable, degraded, partial, denied, stale, and recovery states are + understandable and tested. +- At configuration-package or release boundaries, guided setup, configured + help, health checks, and an operator runbook make the combined journey + reproducible. +- Migrations, upgrades, rollback or corrective recovery, backup/restore impact, + and target integration evidence are added at the increment or release + boundary proportional to risk. + +## Near-term portfolio order + +This order is now selected. Detailed slices and gates are in the +[Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md). Workflow-driven +user-story implementation remains paused. + +0. **Continuous safe foundation.** Keep the composition green and version + aligned; close connector destination pinning, response limits, throttling, + profile/secret ownership and audited deletion, release/recovery, central UI, + focused-view, provenance, and configured-documentation gaps only as far as + the active reference stage requires. +1. **Campaign demonstration composition.** Enforce Mail-profile-only transport, + finish Campaign/UI/state/audit and target delivery/recovery acceptance, + complete adaptive Campaign/Mail/Files documentation, and package runnable + examples as the first pinned reference product. +2. **Function-bound Postbox.** Implement Postbox and the + Organizations–Identity–IDM–Access responsibility path; add Campaign delivery + to a function in an organizational unit and prove reassignment, delegation, + vacancy, retention, and audit behavior. +3. **Templates, Reports, and deep launch.** Build one data-backed document and + one report through curated source contracts; open the task safely from a + mock and then target HIS-style producer; preserve reproducible input, + definition, output, and return-reference evidence. +4. **Governed university BI path.** Starting from that concrete source, add one + scheduled staging, quality, transformation, semantic-product, lineage, and + policy-aware reporting path. Package it for repeatable promotion between + development, test, and production before generalizing dataflow. +5. **Collaborative document lifecycle.** Add DMS versions, review/approval, + provider-neutral editing sessions, one collaborative editor, conflict and + recovery behavior, and Records handoff over Files-backed content. +6. **Maintain already integrated product slices.** Complete regression and + target acceptance for calendar/scheduling/poll and other shipped foundations + without displacing the selected reference path; implement new feature + programs only when they are required by a stage or explicitly reprioritized. +7. **Resume Workflow only by explicit priority decision.** When resumed, start + with stable actions from a demonstrated package; do not turn it into a + second domain layer. + +## Product decisions to make progressively + +These decisions should be made when their horizon or first deployment needs +them; they do not block the product vision today. + +- Which clean composition and target institution will be the first supported + reference release? +- Which real identity, groupware, file/DMS, and deployment stack should define + the first integration profile? +- When should the postponed Workflow program resume, and which single package + will constrain its first implementation? +- Which objects and fields remain authoritative in GovOPlaN versus each target + system, and which conflict/failure behavior is acceptable? +- Which default participant privacy profiles should ship for scheduling, + consultation, committee, and public participation? +- What assurance, signature, federation, and E2EE levels are required for the + first trusted postbox deployment? +- Which external IDM source and conflict, disable, delegation, and vacancy + policy should prove delivery to organizational responsibility? +- Which HIS or other specialist system should be the first deep-launch + producer, and which callback/reference behavior can it support? +- Which bounded university dataset, reporting date semantics, official keys, + accepted calculation, privacy profile, and drill-down level should define the + first analytical data product? +- After the first source-to-report proof, do repeated source/dataflow contracts + justify separate `govoplan-datasources` and `govoplan-dataflow` modules? +- Which collaborative editor should be the first target, and should its first + accepted experience emphasize concurrent editing, controlled check-out, or + both? +- Which archive/records target and signature or approval assurance level should + receive the first accepted collaborative rendition? +- Which sanctions/embargo data source or provider, matching policy, legal basis, + review roles, evidence period, and rescreen triggers should define the first + export-control package? +- Which RPO, RTO, availability, support, data-residency, audit-export, and + restricted-network profiles will be supported rather than merely possible? +- Who may publish and sign official configuration packages, and what + compatibility/LTS policy should consumers be able to rely on? + +## Success measures + +The roadmap is succeeding when GovOPlaN improves institutional outcomes, not +when it accumulates modules. Useful measures include: + +- fewer context switches, duplicate entries, and manual correlation steps per + completed service; +- time from input to owned work and from blocker to responsible actor; +- percentage of consequential actions with complete authority, policy, + consequence, effect, and correction evidence; +- percentage of external effects reaching a known reconciled outcome without + duplication; +- user success, accessibility, and error recovery for each focused task view; +- time to configure, explain, test, export, import, and upgrade a service + package; +- successful restore and disaster-recovery drills within declared objectives; +- connector health, freshness, conflict, and manual-intervention backlog; +- percentage of generated artifacts and reported measures reproducible from + versioned source, transformation, definition, parameter, and output evidence; +- analytical freshness, validation/quarantine resolution, schema-drift, and + permitted drill-down outcomes for each published data product; +- collaborative save-conflict, recovery, review, approval, and accepted-version + integrity outcomes; +- privacy and records-policy conformance with documented exceptions; +- reuse of the same package across institutions without code forks; and +- reduction in special-case module coupling and deployment-local patches. + +## Deliberate non-goals + +- Replacing every Fachverfahren, ERP, DMS, groupware, project tool, or learning + platform. +- Treating one database as the authoritative source for every connected system. +- Showing every installed module and option to every user. +- Creating a domain module simply because a repository exists. +- Hiding consequential decisions or external side effects behind friendly + automation. +- Describing corrective actions as if they erase already observed effects. +- Making raw JSON, deployment files, or direct database edits the normal + configuration experience. +- Building an unbounded general-purpose dataflow platform before the selected + source-to-document and university source-to-indicator journeys prove the + contracts; BI itself is now an explicit reference-program stage. +- Building native project-management, mobile, or embedded AI programs before a + reference journey proves the shared need. +- Claiming production readiness from unit tests, local source checkouts, or + connector scaffolds alone. + +GovOPlaN reaches the north star when an institution can explain, in ordinary +language, what service it configured, who can act, which systems participate, +what happens when they fail, how a decision can be reviewed, and where the +evidence remains—and the product can prove that explanation at runtime. + +## Snapshot appendix: 2026-07-20 + +This appendix records volatile facts that informed this revision. It is not a +second source of truth and should be refreshed or removed when a later roadmap +review uses a new release/backlog snapshot. + +### Composition and release snapshot + +The cross-repository contract scan found 43 module manifest contracts, 29 +provided interface names, 16 requirements, and no contract error across 65 +scanned repositories. That is meaningful composition evidence, but the release +metadata trailed the integrated code: Core, Policy, Poll, and Scheduling +declared `0.1.9` while the whole-product release requirements remained on +module tag `v0.1.8`; the root self-hosted `.env.example` and release smoke +composition did not yet exercise all installed release modules. Other +development compositions already included some of those modules. This was a +release/composition gap, not evidence that the underlying slices did not exist. + +### Backlog snapshot + +The Gitea audit found 206 open issues across 36 of 66 catalogued repositories +and 362 closed issues. Campaign had 51 open issues and Core 44; together they +held 46% of current work. This reflected substantial completed kernel, +security, and platform work and a deliberate concentration on the first usable +vertical, but also risked crowding out production evidence and the shared +process spine. + +The issue workflow needed a reconciliation pass before another delivery +program could be inferred from labels: 119 open issues remained in triage, 116 +had no milestone, and several recently pushed Calendar, Scheduling, Poll, +Campaign, and Files slices still described themselves as local or awaiting +integration. Conversely, 30 repositories had no open issue; for many +later-wave modules this meant no implementation program had been opened, not +that the capability was complete. + +[Poll #2](https://git.add-ideas.de/add-ideas/govoplan-poll/issues/2) was a clear +tracker-drift example: its configurable transition engine, agreed transition +matrix/history, idempotent keyed retries, re-decision audit, archive/unarchive, +and preservation behavior were implemented and pushed while the issue still +reported `needs-info`. + +Issue anchors that informed the bridge from the baseline into this roadmap: + +- [Meta #10](https://git.add-ideas.de/add-ideas/govoplan/issues/10) for the + capability/infrastructure assessment and its target proof; +- [Meta #11](https://git.add-ideas.de/add-ideas/govoplan/issues/11) for the + universal interface and focused-view direction; +- [Core #225](https://git.add-ideas.de/add-ideas/govoplan-core/issues/225) for + guided, safe configuration; +- [Core #29](https://git.add-ideas.de/add-ideas/govoplan-core/issues/29) for the + backup/restore production gate; +- [Core #263](https://git.add-ideas.de/add-ideas/govoplan-core/issues/263) and + [Campaign #63](https://git.add-ideas.de/add-ideas/govoplan-campaign/issues/63), + [#62](https://git.add-ideas.de/add-ideas/govoplan-campaign/issues/62), + [#65](https://git.add-ideas.de/add-ideas/govoplan-campaign/issues/65), and + [#69](https://git.add-ideas.de/add-ideas/govoplan-campaign/issues/69) for the + reference interface/delivery vocabulary and behavior; +- [Poll #1](https://git.add-ideas.de/add-ideas/govoplan-poll/issues/1) for the + database-enforced respondent invariant exposed by Scheduling; +- [Connectors #6](https://git.add-ideas.de/add-ideas/govoplan-connectors/issues/6) + for the governed connector configuration/simulation foundation; +- [Meta #9](https://git.add-ideas.de/add-ideas/govoplan/issues/9) for the first + permit-to-payment reference process; and +- [Meta #12](https://git.add-ideas.de/add-ideas/govoplan/issues/12) for the + deliberately deferred, consumer-independent export-control story. + +Live Gitea issue state remains canonical. These dated facts explain the roadmap +sequence only.