GovOPlaN/govoplan-core
1
0
Fork 0
Code Issues 43 Pull Requests Actions Packages Projects Releases Wiki Activity

docs: align technical roadmap to reference program

Browse Source
This commit is contained in:
Albrecht Degering
2026-07-21 15:45:39 +02:00
parent 0845e99cf6
commit 5ab1af803b
1 changed files with 112 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files

180
docs/GOVOPLAN_MASTER_ROADMAP.md
View File

@@ -13,9 +13,11 @@ The meta repository's
[Connected Governance Platform Roadmap](https://git.add-ideas.de/add-ideas/govoplan/src/branch/main/docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md) [Connected Governance Platform Roadmap](https://git.add-ideas.de/add-ideas/govoplan/src/branch/main/docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md)
describes the corresponding cross-product stakeholder visions, configurable describes the corresponding cross-product stakeholder visions, configurable
service and operating configurations, connected outcome stories, and service and operating configurations, connected outcome stories, and
capability horizons. Its product horizons are canonical; the waves below give capability horizons. The selected five-stage delivery sequence and its gates
their technical dependency order. This Core roadmap remains the technical are in the meta repository's
sequencing and module-routing companion. [Reference Journey Program](https://git.add-ideas.de/add-ideas/govoplan/src/branch/main/docs/REFERENCE_JOURNEY_PROGRAM.md).
Those product documents are canonical; this Core roadmap remains their
technical sequencing and module-routing companion.
## Product Thesis ## Product Thesis
@@ -121,7 +123,8 @@ pattern exists.
## Focus Rules ## Focus Rules
1. Build one reference journey per wave. 1. Build one selected reference journey stage at a time; a later capability
cluster is not an active program merely because it appears below.
2. Do not implement a module because the repository exists. 2. Do not implement a module because the repository exists.
3. Do not add module-to-module imports for optional behavior. 3. Do not add module-to-module imports for optional behavior.
4. Every new domain module must justify its own semantics beyond `cases`, 4. Every new domain module must justify its own semantics beyond `cases`,
@@ -197,56 +200,82 @@ an editor applies a high-impact configuration change.
## Reference Journeys ## Reference Journeys
The roadmap should be driven by three journeys. The active sequence is selected. Workflow remains deliberately deferred and is
not a dependency of these journeys.
### Journey 1: Permit To Payment ### Journey 1: Campaign Demonstration Composition
This is the primary public-administration journey. Campaign is the first complete proof of modular composition. Campaign owns
intent, recipient snapshots, personalization, execution state, and delivery
evidence. Mail owns reusable profiles, credentials, protocol policy, and
provider execution; Campaign stores only a selected profile reference. Files
owns storage, connector profiles, file policy, and provenance.
1. A person applies for a permit through the public portal. The technical gate is a pinned Campaign/Mail/Files composition with central
2. The applicant uploads required files and submits structured form data. UI, adaptive user/admin/operator/integration documentation, target SMTP/IMAP
3. Submission creates a case, a workflow instance, and an internal task. and file-provider evidence, and explicit test/send/resend/retry/reconciliation
4. Completing the task creates a postbox message, a notification, and an email semantics. Readers must not receive backend paths, worker claims, secrets, or
notification with an appointment proposal. raw provider diagnostics.
5. The applicant accepts an appointment, which updates the calendar and the
workflow state.
6. During the appointment, the case is opened and the permit is generated from
a governed template.
7. The payment is processed and linked to the case and accounting handoff.
8. The permit, payment evidence, communication history, audit trail, retention
state, and records evidence remain available according to policy.
This journey proves the platform can coordinate modules without core knowing ### Journey 2: Function-Bound Postbox Delivery
module internals.
### Journey 2: Training To Certificate Postbox accepts delivery to an addressable postbox or a function in an
organizational unit. Organizations owns units and functions, Identity owns
subjects, IDM owns identity-to-function assignments and upstream sync, and
Access resolves current roles, delegation, acting context, and permission.
This is the best university-administration and internal-administration journey. Campaign consumes a typed delivery-target capability without importing Postbox
or identity internals. Reassignment changes future access without moving the
message; vacancy or ambiguous acting context fails visibly; delivery, access,
and correction remain auditable.
1. Course or training offer is planned. ### Journey 3: Data-Backed Templates, Reports, And Deep Launch
2. Room, trainer, resource, and capacity are booked.
3. Participants register or are assigned.
4. Attendance is tracked.
5. Certificate or participation confirmation is issued.
6. Evidence remains available through records, files, audit, and docs.
This journey keeps `booking`, `resources`, `learning`, and `certificates` An authenticated user follows an opaque, short-lived launch reference from HIS
focused instead of becoming broad ERP replacements. or another specialist system. GovOPlaN re-authorizes the actor, resolves a
curated data context server-side, displays source/freshness/version, and renders
one reproducible document and report.
### Journey 3: Report To Resolution Templates owns definition/version/schema/rendering, Reporting owns source
selection/parameters/execution/export, Files owns generated bytes, and
connectors own protocol access. URLs do not carry credentials, arbitrary SQL,
or trusted raw personal data. Retries are idempotent and generation evidence
connects source, snapshot/reference, transformation, definition, parameters,
output checksum, actor, and policy.
This is the internal operations and municipal issue-reporting journey. ### Journey 4: Governed University BI Path
1. A person reports an issue. Starting from the Journey 3 source contract, one bounded university dataset is
2. The issue is triaged into helpdesk, facilities, assets, or a case. catalogued, staged by snapshot or watermark, validated, transformed through a
3. Work is assigned, tracked, and escalated. versioned lineage graph, and exposed as a policy-aware analytical data product.
4. Evidence, communication, and status updates are preserved. The result must preserve official-key mappings, organizational and reporting
5. Reports show workload, SLA, recurring problems, and completion. date semantics, quality findings, quarantine/replay, transparent calculation,
and reproducible promotion between development, test, and production.
This journey prevents `helpdesk`, `issue-reporting`, `facilities`, and `assets` Reporting consumes the product. Create `govoplan-datasources` or
from becoming disconnected ticket silos. `govoplan-dataflow` only after the concrete path proves repeated ownership that
does not belong to connectors, Reporting, or the producing domain module.
## Roadmap Waves ### Journey 5: Collaborative Document Lifecycle
An uploaded or generated artifact becomes a DMS document. Files continues to
own bytes; DMS owns identity, versions, renditions, editing sessions, locks,
comments, review, approval, comparison, and recovery; a collaboration connector
owns provider-specific protocol behavior; Records owns later classification,
hold, archive, and disposal.
The gate requires no silent lost updates, short-lived and currently authorized
editing sessions, idempotent authenticated callbacks, visible uncertain saves,
immutable accepted renditions, and a Records-ready handoff with stable content
and provenance.
## Capability Dependency Waves
The waves below remain a dependency and ownership catalogue for the wider
product vision. They are not the active delivery order. The five selected
journeys above and the meta roadmap decide what is implemented now; other
clusters remain dormant until a selected journey consumes them or they are
explicitly reprioritized.
### Wave 0: Platform Spine ### Wave 0: Platform Spine
@@ -540,19 +569,28 @@ Before a module becomes release-included, it needs:
## Technical Dependency Order Summary ## Technical Dependency Order Summary
When the meta roadmap selects one of these product programs, use this order to Use this active order while respecting the ownership and implementation gates
respect shared-spine dependencies. The list is not an active schedule or a in the capability waves:
decision to start every program horizontally.
1. Stabilize the platform spine. 1. Keep the platform/release spine green and extend connector, identity,
2. Deliver permit-to-payment MVP. external-effect, provenance, documentation, focused-view, recovery, and
3. Build booking and resource operations. version contracts only as the current journey requires.
4. Add learning and certificates. 2. Complete and package Campaign with Mail-owned profiles, Files, target
5. Add issue reporting and helpdesk. delivery/recovery, central UI, and adaptive documentation.
6. Add records, DMS, search, and transparency. 3. Implement function-bound Postbox delivery through
7. Add procurement, contracts, grants, and finance handoff. Organizations–Identity–IDM–Access and consume it from Campaign through a
8. Add committee and consultation workflows. typed capability.
9. Expand integration, dataflow, reporting, and operations. 4. Implement one data-backed Templates/Reporting path and safe HIS-style deep
launch.
5. Extend that concrete source into one governed university analytical data
product before generalizing data-source or dataflow ownership.
6. Implement Files-backed DMS versions and one provider-neutral collaborative
editing lifecycle, then connect Records handoff.
7. Maintain already integrated Calendar/Scheduling/Poll and other foundations;
activate another capability cluster only when the current journey needs it
or the product roadmap explicitly reprioritizes it.
8. Resume Workflow only by explicit product decision and constrain it with
stable actions from one demonstrated package.
## Deliberate Deferrals ## Deliberate Deferrals
@@ -560,7 +598,8 @@ Defer these until a reference journey proves the need:
- full ERP replacement - full ERP replacement
- native project management beyond connector support - native project management beyond connector support
- broad BI/dataflow platform - an unbounded general-purpose dataflow platform; the bounded governed BI
reference journey is selected
- every possible public-sector protocol adapter - every possible public-sector protocol adapter
- rich LMS behavior beyond training administration - rich LMS behavior beyond training administration
- full qualified digital signing/trust services beyond the identity-trust and - full qualified digital signing/trust services beyond the identity-trust and
@@ -657,19 +696,24 @@ Release composition and tag-only repository handling are documented in
## Next Practical Work ## Next Practical Work
The next planning step should create or update Gitea issues for Wave 0 and Wave The active cross-product story is
1 only. Later waves should stay as roadmap context until the permit-to-payment [`add-ideas/govoplan#14`](https://git.add-ideas.de/add-ideas/govoplan/issues/14).
MVP is demonstrable. Module repositories own implementation issues; do not clone their state here.
Recommended immediate issue buckets: Immediate issue buckets:
- platform spine hardening - fail-closed connector destination pinning and private-network deployment
- configuration package preflight and rollback control for every real transport
- forms-runtime MVP - Mail-profile-only Campaign authoring/build/delivery and safe legacy failure
- portal submission MVP - immediate audited secret deletion when a provider/profile is removed
- cases/workflow/tasks integration MVP - Campaign central-component and role-safe UI acceptance
- template-generated decision document - adaptive Campaign, Mail, and Files task/process/admin/operator/integration/
- postbox/notification handoff security/acceptance documentation
- appointment/booking handoff - target SMTP/IMAP, file-provider, queue/reconciliation, install/upgrade, and
- payment evidence handoff restore proof for the pinned Campaign reference composition
- configured documentation for the reference process
Once that gate is demonstrable, activate the existing Postbox model, access,
API, inbox, and Campaign integration issues. Templates/Reporting, governed BI,
and DMS collaboration remain durable selected direction, but should be
decomposed only as the preceding stage stabilizes or a bounded independent
contract can be implemented without pre-deciding target-system choices.