diff --git a/README.md b/README.md index 093a0dd..62d3363 100644 --- a/README.md +++ b/README.md @@ -125,6 +125,9 @@ Meta ownership and module install/contract boundaries are documented in `docs/META_REPO_SCAN.md` and `docs/MODULE_CONTRACTS_AND_INSTALLS.md`. Frontend layout principles for module pages are documented in `docs/FRONTEND_LAYOUT_PRINCIPLES.md`. +The cross-product destination, stakeholder visions, configuration archetypes, +connected outcome stories, and capability horizons are documented in +the [Connected Governance Platform Roadmap](docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md). The first Campaign-centric capability and infrastructure fit assessment is in `docs/CAPABILITY_AND_INFRASTRUCTURE_FIT.md`. diff --git a/docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md b/docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md new file mode 100644 index 0000000..f88c4ad --- /dev/null +++ b/docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md @@ -0,0 +1,1266 @@ +# 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 [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 | +| 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 +``` + +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. + +### 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. + +**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 the proving +ground for shared UI patterns, durable external effects, 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. + +## 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. + +### 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. Pin and publish a compatible Core/WebUI/module composition and first + reference configuration package. +2. Complete database, files, configuration, secrets, and audit backup/restore + drills with measured recovery objectives. +3. Prove the providers required by the selected reference configurations, + beginning with SMTP/IMAP, CalDAV, and the relevant broker/worker and file or + directory adapters, including reconciliation behavior. +4. Add external monitoring, alerting, audit export/retention, deployment + hardening, and incident/runbook evidence. +5. 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. +6. Align executable WebUI contributions with manifest/configured-system + metadata and make focused views manually/default selectable without waiting + for Workflow. +7. 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 and one external calendar operation survive +provider/worker failure without duplicate or unexplained effects; the UI 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 smallest connected path from a forms/runtime input through a + case or domain record into assigned work. Add approval, template, postbox, + notification, search, and record-reference capabilities only as the 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. +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 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. +- Select one next package by explicit product decision from these unordered + candidates: permit-to-payment, report-to-resolution, + training-to-certificate, or meeting-to-decision. +- 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; target provider proof remains | Reference package, UI acceptance, real delivery/recovery drill | Governed communications capability | +| 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 | +| Forms/cases/tasks/approvals/postbox/search/templates | Concepts and uneven first slices | One manual end-to-end work/evidence spine | Reusable administrative coordination layer | +| 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 keeps the larger destination in view while honoring the deliberate +pause on workflow-driven user-story implementation. + +1. **Release and recovery baseline.** Turn the recently harmonized repositories + into a clean pinned candidate; close backup/restore, target-provider, + monitoring, security, and capability-assessment evidence gaps. +2. **Campaign reference acceptance.** Complete the campaign UI/state/audit + program as the reference for central components, consequence language, + durable delivery, report filtering, and operator intervention. +3. **Calendar/scheduling/poll acceptance.** Run product and target-provider + acceptance over the implemented calendar selection, durable CalDAV effects, + participant privacy, response editing, transition/audit semantics, and + shared scheduling UI. Decide and then prove the organizer/admin management + policy; organizer-only management with an administrator override is not yet + the implemented mutation model. +4. **Focused experience and configured-system metadata.** Align routes and + manifests; implement manual/user/role/task-suggested views, active-source + explanation, and the full-system escape independently of Workflow. +5. **Connector and infrastructure profile.** Select one real identity/groupware/ + file landscape, implement profile/source-of-truth/health contracts, and + exercise degraded and recovery behavior. +6. **Manual human-work spine.** Build the smallest forms-runtime, case, task/ + inbox, approval, template, postbox/notification, search, and evidence path + without requiring workflow automation. +7. **First service configuration package.** Package one bounded journey with + role defaults, focused views, connectors, policies, configured docs, + preflight, acceptance tests, and upgrade/recovery evidence. +8. **Resume Workflow only by explicit priority decision.** When resumed, start + with the already stable actions and one package; do not turn it into a + second domain layer. +9. **Advance records/compliance and later domain configurations** only when the + shared spine and a concrete regulated or institutional journey are ready to + consume them. + +## 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? +- Which service package should follow controlled communications: public + service, internal report-to-resolution, training, or institutional meetings? +- 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 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; +- 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 a broad BI/dataflow, native project-management, mobile, or embedded + AI program before reference journeys prove 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.