govoplan/docs/strategy/ROADMAP.md

GovOPlaN Roadmap

Purpose

GovOPlaN should become the connective, governance-aware operating layer of an institution: people complete services and work without learning the module graph, while the institution can explain authority, policy, source data, effects, evidence, and recovery.

This is the concise product roadmap. It states durable outcomes and sequence, not release dates or issue state. Use Strategy Status for the current reconciliation and Gitea issues for active work. The detailed connected-platform vision retains stakeholder perspectives, configuration archetypes, and the complete outcome-story catalogue.

Product Promise

GovOPlaN will:

1. model institutional context, responsibility, authority, and time;
2. turn incoming information into owned, reviewable human and machine work;
3. connect native and external systems without obscuring the source of truth;
4. preserve decisions, effects, records, corrections, and recovery evidence;
5. support digital, assisted, paper, message, calendar, and system channels as paths through the same governed work; and
6. package successful configurations so institutions can adopt them without code forks or loss of local autonomy.

It will not replace every specialist system, copy all data into one master database, infer authority from membership, or claim production maturity from repository breadth.

Outcome Horizons

Horizon	Outcome	Completion evidence
Trustworthy baseline	A pinned composition can be installed, upgraded, operated, explained, and recovered.	Signed artifacts, clean install/upgrade, provider failure tests, restore drill, coherent UI, and target evidence
Connected work	Intake becomes accountable work with context, assignment, review, communication, and evidence.	One digital and assisted service reaches a decision and eAkte without losing responsibility or state
Reusable products	Complete service, communication, and data outcomes ship as governed configuration packages.	Two materially different deployments adapt packages without code forks
Institutional assurance	Records, transparency, privacy, risk, regulated review, and reporting connect to real operations.	A consequential decision can be reconstructed, corrected, retained, and disclosed under policy
Federated ecosystem	Autonomous installations exchange signed data and configuration across explicit trust boundaries.	Paired-instance exchange, reconciliation, supported deployment profiles, and independent evidence

Current Sequence

The sequence is outcome-led. Shared foundation work enters when one of these proofs needs it.

1. Enforce the platform quality contract. German is the reference locale; help, accessibility, temporal browsing, purpose-aware access, retention, institutional context, optional-module combinations, and recovery behavior become measurable release gates.
2. Complete governed communication. Prove recipient selection, Campaign, Files, Mail, function-bound Postbox delivery, acknowledgement, uncertain outcomes, correction, filing, and recovery against a named target.
3. Complete the monthly-data and sanctions journey. Acquire immutable source snapshots, validate and reconcile data interactively, preserve lineage and review, publish reports and files, and deliver accepted results.
4. Complete inclusive service to decision. Accept digital or assisted input, establish actor and purpose, persist human handoffs, decide, notify, and reconstruct the exact eAkte under current authorization.
5. Complete discovery and external coexistence. Finish native PostgreSQL search coverage, prove reauthorization and reindexing, then prove one external product connector and one paired GovOPlaN federation exchange.
6. Prove production operation. Complete multi-host, provider, restore, accessibility, volume, key-custody, and independently signed target evidence before raising maturity claims.

Continuous Foundation

Every journey applies the same boundaries:

• modules cooperate through versioned Core contracts and typed references;
• permissions, policy, institutional context, purpose, and current authority are evaluated before presenting or acting on data;
• requested actions, durable intent, observed effects, unknown outcomes, retries, reconciliation, and correction remain distinct;
• Workflow Engine coordinates stable module-owned actions and human handoffs; it does not become a second owner of domain state;
• Files owns managed bytes, Records owns institutional filing and retention, and source systems retain explicitly declared authority;
• focused views and product areas reduce interface complexity without granting access or hiding material consequences;
• configuration packages include terminology, forms, policies, workflows, views, reports, providers, documentation, migration, and evidence; and
• maturity advances from scaffold to vertical slice, reference-ready, supported, and LTS only with evidence appropriate to each claim.

Decision Rule

A roadmap item should answer all of the following before implementation:

1. Which real journey and actor outcome does it improve?
2. Which module or external system owns each object and source of truth?
3. Which institutional, temporal, purpose, and policy context applies?
4. Which effects, evidence, retention, failure, and recovery states result?
5. Which package and target evidence will prove the outcome?

If those answers are missing, retain the idea in the Product Input Register or Gitea discovery work rather than opening an unbounded implementation program.