govoplan/docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md

# 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.

The complete installation and lifecycle journey is specified in the
[System Administrator Lifecycle User Story](SYSTEM_ADMINISTRATOR_LIFECYCLE_USER_STORY.md):
one-command Core-only bootstrap, signed online module installation and updates,
stateless scale-out, versioned configuration transfer, undo, and reproducible
environment-promotion recipes.

### Integration owner and enterprise architect

> As an integration owner, I can inventory external systems, declare direction
> and source-of-truth rules, test credentials and schemas, observe lag and
> conflicts, and retire a connection safely so that the organization can evolve
> its IT landscape without opaque point-to-point coupling.

### External supplier, grantee, or institutional partner

> As an external organization, I can submit an offer, invoice, milestone,
> evidence item, or formal response through a narrowly scoped portal, postbox,
> or API and follow only my own relationship so that cooperation does not
> require broad internal access.

The configured relationship determines identity assurance, representation,
signing, deadlines, corrections, communication, and which internal or external
system remains authoritative.

### Auditor, oversight body, or authorized public reviewer

> As an authorized reviewer, I can follow a consequential outcome from source
> through policy, human or system action, observed external effects,
> reconciliation, corrections, and retention so that accountability does not
> depend on informal institutional memory.

## Configuration dimensions

Every packaged journey should make the following choices explicit. They are
configuration dimensions, not forks of the product.

| Dimension | Typical choices | Required clarity |
| --- | --- | --- |
| Operational ownership | GovOPlaN-native; external source of truth; GovOPlaN record with external effect; read-only link/import; governed synchronization | Which system may create or change which state, and how conflicts are resolved |
| Identity | Local accounts; OIDC/SAML; LDAP/AD or SCIM provisioning; hybrid; service and system actors | Account correlation, deprovisioning, MFA/assurance, group mapping, delegation and break-glass behavior |
| Organization | Single office; multi-department tenant; shared-service tenant; multiple isolated tenants; cross-institution cooperation | Data boundary, role/function scope, shared objects, administration and reporting scope |
| Participant channel | Portal; postbox; email; assisted entry; API/webhook; physical/offline handoff | Receipt, identity assurance, accessibility, privacy, legal effect and fallback path |
| Decision model | Informational; advisory; one-person; four-eyes; committee; threshold escalation; policy-assisted automation | Authority, reason, review, contestability, override and correction |
| Automation | Fully manual; suggested next action; approved batch; event-driven; scheduled; automatic with exception queue | Preview, idempotency, observed effects, failure state, retry, reconciliation and responsible system actor |
| Evidence | Operational history; formal record; archive handoff; legal hold; public disclosure | Classification, retention, version, integrity, access, redaction and disposal authority |
| Privacy | Own data only; aggregates; named participants; role-limited details; purpose-specific disclosure | The minimum data shown at each surface and the policy source for broader access |
| Experience | Full module; user or role default view; manually selected view; task-suggested view; future workflow-step suggestion | Why the view is active, unsaved-work behavior, deterministic composition and full-interface escape |
| Hosting | Single-node pilot; supervised small production; horizontally scalable services; sovereign/private cloud; restricted or disconnected network | Availability, storage, secrets, observability, patching, RPO/RTO, recovery and egress constraints |
| Integration failure | Stop and block; queue and continue; permit manual fallback; accept locally then reconcile; compensate/correct | What users see, who is alerted, whether the action may proceed and how uncertainty is closed |
| Localization and policy | One language/policy set; multilingual; tenant variants; jurisdiction-specific package | Source and version of texts, forms, rules, templates, accessibility and policy interpretations |

A package must not hide these choices behind defaults when they materially
change rights, disclosure, money, records, external effects, or responsibility.

## Configurable platform visions

The following configurations are deliberately overlapping. An institution may
start with one and add capabilities without replacing the platform.
They describe coherent service and operating configurations and their choices;
the later connected outcome stories describe end-to-end acceptance journeys
that one or more configurations must be able to pass.

### 1. Controlled communications and outreach office

**Vision.** A communications team creates a governed campaign, imports or
selects approved recipients, validates personalized content and attachments,
tests one message without consuming send state, approves the send, and follows
every recipient to a known, uncertain, reconciled, or manually resolved
outcome.

**Perspectives.**

- As an author, I can prepare and preview the exact communication each person
  will receive.
- As a reviewer, I can distinguish test, send, resend, and recovery actions and
  see their consequences before approval.
- As an operator, I can recover worker/provider uncertainty without silently
  duplicating delivery.
- As a data steward, I can prove the recipient source, purpose, retention, and
  disclosure path.

**Composition.** Campaign, files, mail, addresses/distribution lists, policy,
access, audit, docs, notifications, and ops; calendar or scheduling is optional.

**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. Deliver the first slices of the
   [System Administrator Lifecycle User Story](SYSTEM_ADMINISTRATOR_LIFECYCLE_USER_STORY.md):
   a verified Core-only distribution, first-run control plane, read-only online
   module directory, and durable plan/confirm/install progress.
2. Pin and publish a compatible Core/WebUI/module composition and first
   reference configuration package.
3. Complete database, files, configuration, secrets, and audit backup/restore
   drills with measured recovery objectives.
4. Prove the providers required by the selected reference configurations,
   beginning with SMTP/IMAP, CalDAV, and the relevant broker/worker and file or
   directory adapters, including reconciliation behavior.
5. Add external monitoring, alerting, audit export/retention, deployment
   hardening, and incident/runbook evidence.
6. Apply the interface pattern language first to Campaign, scheduling, and
   admin/configuration. Existing central components are mandatory; any custom
   control needs prior product-owner authorization and a narrow recorded scope.
   Extend central contracts only after a repeated need is demonstrated.
7. Align executable WebUI contributions with manifest/configured-system
   metadata and make focused views manually/default selectable without waiting
   for Workflow.
8. Refresh the capability/infrastructure assessment and distinguish code-tested,
   target-tested, package-integrated, pilot-approved, and production-approved
   evidence.

**Gate.** A clean release candidate can be installed and restored; the
Campaign reference journey 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.