101 lines
5.6 KiB
Markdown
101 lines
5.6 KiB
Markdown
# 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](STRATEGY_STATUS.md) for
|
|
the current reconciliation and Gitea issues for active work. The
|
|
[detailed connected-platform vision](reference/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md)
|
|
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.
|