feat: implement institutional governance and recovery architecture
This commit is contained in:
@@ -14,6 +14,14 @@
|
||||
| Machine-readable companion | [`capability-fit-current.json`](capability-fit-current.json) |
|
||||
| Input schema | [`capability-fit.schema.json`](capability-fit.schema.json) |
|
||||
|
||||
**Snapshot notice:** this assessment remains valid only for the pinned
|
||||
2026-07-22 composition above. Workflow Engine, the optional Workflow editor,
|
||||
Datasources, Dataflow, Search, encryption contracts, and other later main-branch
|
||||
work must not be inferred into this evidence record. The current product
|
||||
direction and implemented-state reconciliation are documented separately in
|
||||
the
|
||||
[Institutional Governance Target Architecture](INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md).
|
||||
|
||||
This is a fit assessment, not a production approval or security certification.
|
||||
It deliberately does not infer implementation from a repository, issue, or
|
||||
manifest existing. A conclusion needs code plus a route/contract, test,
|
||||
@@ -468,10 +476,11 @@ which modules a running service activated, migrations, configuration, health,
|
||||
or reference-journey behavior. Runtime activation therefore remains an explicit
|
||||
unchecked boundary.
|
||||
|
||||
### Target, provider and production proof boundary
|
||||
### Reference-readiness, provider and production proof boundary
|
||||
|
||||
Installed evidence cannot approve a target environment, an external provider,
|
||||
or production use. These scopes use a separate, expiring
|
||||
Installed evidence cannot establish target acceptance, accessibility, privacy,
|
||||
security, operations, recovery, an external provider, or production use. These
|
||||
scopes use a separate, expiring
|
||||
[`capability-fit-boundary-evidence.schema.json`](capability-fit-boundary-evidence.schema.json)
|
||||
bundle. The bundle is bound to the assessment ID, assessment release and exact
|
||||
installed-evidence SHA-256 digest. It contains only opaque subject/control/result
|
||||
@@ -480,8 +489,9 @@ IDs and content hashes, not endpoints, credentials, people or raw result files.
|
||||
Boundary evidence is accepted only when at least one Ed25519 signature validates
|
||||
against a separately provisioned
|
||||
[`capability-fit-proof-authority-keyring.schema.json`](capability-fit-proof-authority-keyring.schema.json).
|
||||
Each authority key explicitly lists the scopes it may attest. Target and provider
|
||||
claims use `passed` or `failed`; production claims use `approved` or `rejected`.
|
||||
Each authority key explicitly lists the scopes it may attest. Target,
|
||||
accessibility, privacy, security, operations, recovery, and provider claims use
|
||||
`passed` or `failed`; production claims use `approved` or `rejected`.
|
||||
One claim per scope, unique control/artifact IDs, `issued_at < expires_at`, current
|
||||
validity and exact digest binding are mandatory. Any schema, binding, time,
|
||||
signature or authority blocker leaves every supplied boundary claim unchecked;
|
||||
@@ -554,6 +564,10 @@ Target-environment and production-approval claims must use the assessment's
|
||||
operator to supply a bounded opaque expected subject with
|
||||
`--expected-external-provider-subject`; without it, such a claim remains
|
||||
unchecked and blocks. Expected and observed IDs are retained in proof scope.
|
||||
Accessibility, privacy, security, operations, and recovery claims use the same
|
||||
deployment subject. The report emits a cumulative `reference_readiness` verdict
|
||||
only when all six required scopes are checked and positive. This verdict remains
|
||||
separate from production approval and from provider-specific acceptance.
|
||||
|
||||
Both authority keyrings are governance trust roots. Installer receipt keys use
|
||||
the strict
|
||||
@@ -575,9 +589,9 @@ cannot relabel it as current. Live admission must omit it and use the actual
|
||||
current time.
|
||||
|
||||
No boundary bundle or production authority has been supplied for this current
|
||||
assessment. Target environment, provider and production proof therefore remain
|
||||
explicitly unchecked rather than inferred from the local GreenMail journey,
|
||||
source tests or signed release metadata.
|
||||
assessment. Reference-readiness, provider, and production proof therefore
|
||||
remain explicitly unchecked rather than inferred from the local GreenMail
|
||||
journey, source tests, or signed release metadata.
|
||||
|
||||
## Evidence used in this slice
|
||||
|
||||
|
||||
@@ -16,6 +16,7 @@ cross-product vision that sequence serves.
|
||||
|
||||
Read it together with:
|
||||
|
||||
- the [institutional governance target architecture](INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md)
|
||||
- the [selected reference-journey program](REFERENCE_JOURNEY_PROGRAM.md)
|
||||
- the [current capability and infrastructure fit assessment](CAPABILITY_AND_INFRASTRUCTURE_FIT.md)
|
||||
- the [interface pattern language](INTERFACE_PATTERN_LANGUAGE.md)
|
||||
@@ -151,7 +152,7 @@ responsibilities, not a new dependency hierarchy.
|
||||
| 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 |
|
||||
| Institutional governance | Establish who may act, in which capacity, for which organization and tenant, under which mandate, jurisdiction, and policy. | Identity, access, IDM, tenancy, organizations, policy, identity trust, risk/compliance; candidate mandate and decision contracts |
|
||||
| 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
|
||||
@@ -1136,11 +1137,12 @@ boundary, and retain operational, security, and evidence guarantees.
|
||||
| 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 |
|
||||
| Organizations/identity/IDM/access/postbox | Normalized ownership concepts and uneven runtime slices | Function-bound delivery, reassignment/delegation, vacancy and access-evidence proof | Institutional responsibility and durable communication spine |
|
||||
| Forms/cases/tasks/approvals/search | Concepts and uneven first slices | Extend the proven responsibility path into one manual end-to-end work/evidence journey | Reusable administrative coordination layer |
|
||||
| Templates/reporting/data sources | Boundary concepts or scaffolds | One reproducible data-backed document/report and safe HIS-style launch | Governed document production, reports, dashboards, and analytical consumption |
|
||||
| Analytical data products/dataflow | Selected direction; platform contracts not yet implemented | One bounded university source-to-indicator path with staging, quality, lineage and promotion proof | Transparent institutional BI and cross-process reporting |
|
||||
| Forms/cases/tasks/approvals | Concepts and uneven first slices | Extend the proven responsibility path into one manual end-to-end work/evidence journey, with shared service, party, mandate, and decision semantics | Reusable administrative coordination layer |
|
||||
| Search | PostgreSQL-backed permission-aware provider and global/contextual UI foundation | Complete provider rollout, indexing operations, and target authorization/performance evidence | Optional cross-module discovery with OpenSearch only as an adapter |
|
||||
| Templates/reporting/data sources | Templates and governed Datasources foundations exist; Reporting remains an early semantic-model slice | One reproducible data-backed document/report and safe HIS-style launch | Governed document production, reports, dashboards, and analytical consumption |
|
||||
| Analytical data products/dataflow | Typed graph/runtime foundations, triggers, staging integration, reusable definitions, and golden-flow fixtures exist | One bounded university source-to-indicator path with quality, lineage, promotion, and target-performance proof | Transparent institutional BI and cross-process reporting |
|
||||
| DMS/collaborative editing | Boundary concept and tag-only scaffold | One Files-backed version lifecycle, then one provider-neutral editing session | Collaborative documents, review, approval and records-ready renditions |
|
||||
| Workflow/automation | Concept only; no discoverable Workflow runtime; program postponed | Stable action/effect providers and an explicitly reprioritized bounded journey | Configurable governed process coordination |
|
||||
| Workflow/automation | Headless Workflow Engine and optional editor are implemented foundations with versioned module baselines, BPMN interchange, action/effect execution, and reconciliation | Prove one resumable human/system journey with target recovery and conformance evidence | Configurable governed process coordination without becoming a second domain layer |
|
||||
| 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 |
|
||||
@@ -1216,8 +1218,9 @@ provides all applicable evidence below.
|
||||
## Near-term portfolio order
|
||||
|
||||
This order is now selected. Detailed slices and gates are in the
|
||||
[Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md). Workflow-driven
|
||||
user-story implementation remains paused.
|
||||
[Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md). Workflow Engine and
|
||||
the optional editor may support these stages, but Workflow work enters the
|
||||
portfolio only through an explicit bounded package or reference journey.
|
||||
|
||||
0. **Continuous safe foundation.** Keep the composition green and version
|
||||
aligned; close connector destination pinning, response limits, throttling,
|
||||
@@ -1250,8 +1253,9 @@ user-story implementation remains paused.
|
||||
target acceptance for calendar/scheduling/poll and other shipped foundations
|
||||
without displacing the selected reference path; implement new feature
|
||||
programs only when they are required by a stage or explicitly reprioritized.
|
||||
7. **Resume Workflow only by explicit priority decision.** When resumed, start
|
||||
with stable actions from a demonstrated package; do not turn it into a
|
||||
7. **Use Workflow only through bounded journeys.** The headless engine and
|
||||
optional editor now exist. Extend them through stable module-owned actions,
|
||||
versioned baselines, and demonstrated packages; do not turn Workflow into a
|
||||
second domain layer.
|
||||
|
||||
## Product decisions to make progressively
|
||||
@@ -1263,8 +1267,8 @@ them; they do not block the product vision today.
|
||||
reference release?
|
||||
- Which real identity, groupware, file/DMS, and deployment stack should define
|
||||
the first integration profile?
|
||||
- When should the postponed Workflow program resume, and which single package
|
||||
will constrain its first implementation?
|
||||
- Which demonstrated package should provide the first target-accepted Workflow
|
||||
execution and recovery profile?
|
||||
- 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,
|
||||
|
||||
@@ -6,8 +6,8 @@ GovOPlaN separates governed data identity from external acquisition:
|
||||
|
||||
| Layer | Owner | Responsibilities |
|
||||
| --- | --- | --- |
|
||||
| Datasource layer | `govoplan-datasources` | Catalogue, tenant visibility, live/cached/static mode, staging, immutable materializations, frozen states, schema, fingerprints, provenance, and bounded reads |
|
||||
| Connector layer | `govoplan-connectors` and protocol/provider modules | External protocols, endpoints, connection profiles, credentials, discovery, provider health, source-side filtering, and query pushdown |
|
||||
| Datasource layer | `govoplan-datasources` | Governed data/register catalogue, tenant visibility, live/cached/static mode, source authority, staging, immutable materializations, frozen states, schema, quality/freshness policy, institutional provenance, dependencies, and bounded reads |
|
||||
| Connector layer | `govoplan-connectors` and protocol/provider modules | External protocols, endpoints, connection profiles, credentials, discovery, provider maturity/authority support, health, source-side filtering, query pushdown, and effect reconciliation |
|
||||
|
||||
Connectors publish versioned datasource origins. Datasources registers those
|
||||
origins and presents one stable capability to Dataflow, Workflow, Reporting,
|
||||
@@ -43,9 +43,10 @@ Domain modules own their semantics:
|
||||
|
||||
- Dataflow provides load, combine, filter, transform, and output nodes. Its
|
||||
graph is acyclic and has one output.
|
||||
- Workflow provides trigger, activity, review, decision, wait, module-action,
|
||||
Dataflow, and outcome nodes. It permits governed loops and has exactly one
|
||||
trigger plus one or more outcomes.
|
||||
- Workflow Engine provides trigger, activity, review, decision, wait,
|
||||
module-action, Dataflow, and outcome semantics. It permits governed loops and
|
||||
has exactly one trigger plus one or more outcomes. The optional Workflow
|
||||
module supplies the editor over the same native graph/BPMN language.
|
||||
|
||||
This division permits a shared editor shell without making Workflow a special
|
||||
kind of Dataflow or leaking either module into Core.
|
||||
@@ -53,8 +54,10 @@ kind of Dataflow or leaking either module into Core.
|
||||
## Current Implementation
|
||||
|
||||
- Core graph and datasource contracts are versioned at `0.1.0`.
|
||||
- Workflow exposes a reusable graph editor, node-library discovery, validation,
|
||||
tenant-isolated definitions, immutable revisions, and activation pinning.
|
||||
- Workflow Engine owns tenant-isolated definitions, immutable revisions,
|
||||
activation pinning, module-contributed versioned baselines, runtime instances,
|
||||
governed action/effect execution, retries, waits, and reconciliation. The
|
||||
optional Workflow module exposes the reusable native BPMN graph editor.
|
||||
- Datasources exposes catalogue, origins, staging, promotion, preview,
|
||||
materialization history, refresh, freeze, retirement, and producer
|
||||
publication APIs.
|
||||
@@ -62,21 +65,26 @@ kind of Dataflow or leaking either module into Core.
|
||||
- Connectors adapts existing tabular snapshots to datasource origins.
|
||||
- Dataflow consumes only Datasources catalogue/lifecycle capabilities and can
|
||||
request current, live, or latest-frozen state.
|
||||
- Dataflow exposes a pinned run-lifecycle capability and a Run/Publish surface.
|
||||
Its first synchronous runner records lineage and terminal state, publishes
|
||||
only complete bounded results, and retains output datasource/materialization
|
||||
references.
|
||||
- Dataflow exposes typed graph/IR, registry-driven validation/execution/SQL
|
||||
compilation, expressions and reusable subflows, a pinned run-lifecycle
|
||||
capability, production worker boundary, and Run/Publish surface. Runs record
|
||||
lineage and intermediate artifacts and publish only complete bounded results.
|
||||
- The focused composition check proves Connector origin -> Datasource ->
|
||||
pinned Dataflow run -> frozen published materialization, including replay.
|
||||
|
||||
## Next Slices
|
||||
|
||||
1. Add persisted Workflow instances, resumable transitions, human activities,
|
||||
retry policy, and event subscriptions against pinned definition revisions.
|
||||
2. Add SQL database and governed REST origin providers with credential-envelope
|
||||
1. Add the provider declaration and source-authority binding used consistently
|
||||
by Connectors, Datasources, configuration packages, Ops, and Docs.
|
||||
2. Add typed datasource owner/steward, legal/purpose, quality/freshness,
|
||||
classification, correction, service/process, and downstream dependency
|
||||
metadata under
|
||||
[Datasources #6](https://git.add-ideas.de/GovOPlaN/govoplan-datasources/issues/6).
|
||||
3. Add SQL database and governed REST origin providers with credential-envelope
|
||||
references and bounded pushdown.
|
||||
3. Add managed-file and directory origins.
|
||||
4. Add datasource quality rules, schema compatibility policy, retention, and
|
||||
4. Add managed-file and directory origins.
|
||||
5. Complete datasource quality rules, schema compatibility policy, retention, and
|
||||
promotion approvals.
|
||||
5. Add asynchronous Dataflow workers and durable artifact-backed outputs for
|
||||
runs that exceed the synchronous row/time/byte limits.
|
||||
6. Complete scheduled/event/API/chained Dataflow trigger governance, reusable
|
||||
template inheritance, Reporting publication, human reconciliation transforms,
|
||||
and target resource/recovery evidence for large runs.
|
||||
|
||||
@@ -34,9 +34,15 @@ It currently supports:
|
||||
- generated secrets stored in a private `0600` file;
|
||||
- service-specific environment allowlists so infrastructure containers do not
|
||||
receive unrelated application credentials;
|
||||
- plan, render, doctor, status, and apply commands;
|
||||
- plan, render, doctor, status, apply, Kubernetes export, operation history,
|
||||
and bounded recovery commands;
|
||||
- an installation lock, migration-before-start ordering, readiness polling,
|
||||
and an applied-state receipt;
|
||||
- a durable hash-chained deployment journal captured before runtime mutation;
|
||||
- PostgreSQL advisory serialization for Core and module migrations;
|
||||
- runtime initialization that waits for exact configured migration heads
|
||||
without mutating schema;
|
||||
- runtime node registration, heartbeats, drain state, and a fenced scheduler;
|
||||
- idempotent reconfiguration that preserves generated secrets;
|
||||
- a keyed environment fingerprint that detects private binding changes without
|
||||
writing secret values to plans or receipts;
|
||||
@@ -87,6 +93,9 @@ The private installation directory contains:
|
||||
| `load-balancer.cfg` | Non-secret HAProxy WebUI/API discovery configuration |
|
||||
| `plan.json` | Latest desired-state diff and readiness findings |
|
||||
| `receipt.json` | Last successfully applied immutable identities |
|
||||
| `applied-state/` | Checksum-verified snapshot of the last healthy deployment bundle |
|
||||
| `operations/<id>/` | Private hash-chained deployment progress and recovery evidence |
|
||||
| `kubernetes.json` | Optional stateless multi-host Kubernetes export |
|
||||
| `.deployment.lock` | Same-host operation exclusion |
|
||||
|
||||
The specification contract is
|
||||
@@ -201,11 +210,13 @@ presenting a container as a complete mail service.
|
||||
installations. `garage` provisions Garage 2.3 in its supported single-node
|
||||
bootstrap mode, generates a private application key and bucket, and connects
|
||||
the Files S3 backend to the exact installer-owned internal endpoint. The
|
||||
deployment-only trust marker cannot authorize another S3 host; arbitrary
|
||||
external SDK endpoints remain fail-closed until peer pinning is implemented.
|
||||
managed trust marker cannot authorize another S3 host.
|
||||
Garage metadata and object data use separate persistent volumes. `s3` requires
|
||||
an external endpoint, region, access key, secret key, and bucket values.
|
||||
Self-hosted external S3 endpoints must use HTTPS.
|
||||
Self-hosted external S3 endpoints must be clean HTTPS origins. The generated
|
||||
runtime explicitly sets `FILE_STORAGE_S3_ENDPOINT_TRUSTED=true` for that
|
||||
operator-selected endpoint. The trust flag is not accepted for local storage
|
||||
and cannot be combined with installer-managed Garage trust.
|
||||
|
||||
Local storage must be included in backup and restore drills. Horizontal API or
|
||||
worker scale-out requires shared/object storage. The managed Garage profile is
|
||||
@@ -233,9 +244,10 @@ Replica counts are desired state:
|
||||
```
|
||||
|
||||
Workers are queue consumers, so they are scaled through Redis rather than put
|
||||
behind an HTTP load balancer. The migration runner and Celery scheduler remain
|
||||
singletons. Multiple API replicas are rejected when Redis is disabled because
|
||||
distributed throttling and queued work cannot then be shared correctly.
|
||||
behind an HTTP load balancer. Migrations are serialized with a deployment-wide
|
||||
PostgreSQL advisory lock. The Celery scheduler is run under a renewable,
|
||||
fencing-token lease. Multiple API replicas are rejected when Redis is disabled
|
||||
because distributed throttling and queued work cannot then be shared correctly.
|
||||
|
||||
This is same-host scaling. Docker Compose uses a bridge network and does not
|
||||
place containers on another machine. See
|
||||
@@ -258,13 +270,66 @@ applied state. `plan` compares their canonical hashes and service sets.
|
||||
- Managed-to-external transitions require the new endpoint in the same
|
||||
operation.
|
||||
- Migrations run as a one-shot service before API/worker replacement.
|
||||
- API, worker, and scheduler start commands wait for exact configured migration
|
||||
heads; only the migration command is permitted to change schema.
|
||||
- API and worker replicas register their software/module composition and
|
||||
heartbeat in PostgreSQL. Ops can request and cancel a node drain.
|
||||
- The first upgrade from a direct WebUI host port stops that legacy WebUI
|
||||
container immediately before HAProxy claims the same endpoint.
|
||||
- Health must recover before a new receipt is committed.
|
||||
- Health must recover before a new receipt and applied-state snapshot are
|
||||
committed.
|
||||
|
||||
This is sufficient for one-host reconciliation. Production updates additionally
|
||||
need backup/restore gates, maintenance/drain state, database compatibility
|
||||
windows, image signature verification, and rollback/forward-recovery policy.
|
||||
Every apply operation is journalled before image pulls or runtime mutation. A
|
||||
failure before migration may restore a verified previous bundle. Once migration
|
||||
starts, recovery is forward-only unless an independently verified database
|
||||
backup is restored. See
|
||||
[Recovery And Rollback Guarantees](RECOVERY_AND_ROLLBACK_GUARANTEES.md).
|
||||
|
||||
Production updates still need an operator-provided database backup/restore
|
||||
gate, database compatibility declaration, image signature verification, and
|
||||
deployment-specific drain policy. The deployment journal proves its own
|
||||
actions; it does not manufacture backup evidence.
|
||||
|
||||
## Stateless Kubernetes Runtime
|
||||
|
||||
`render-kubernetes` exports the application tier for a standard orchestrator.
|
||||
It requires external PostgreSQL, Redis, and S3 and emits no stateful service or
|
||||
secret value:
|
||||
|
||||
```sh
|
||||
python tools/deployment/govoplan-deploy.py render-kubernetes \
|
||||
--directory /srv/govoplan/default \
|
||||
--namespace govoplan \
|
||||
--secret-name govoplan-runtime
|
||||
```
|
||||
|
||||
The output includes a release-specific migration Job, database-head wait init
|
||||
containers, API readiness/liveness probes, rolling Deployments, Services, Pod
|
||||
disruption budgets, a tokenless ServiceAccount, and one fenced scheduler. Apply
|
||||
the named Secret through the cluster's secret manager and review ingress proxy
|
||||
CIDRs before deployment. Detailed rollout and scaling rules live in
|
||||
[Scaling And Multi-Host Deployment](SCALING_AND_MULTI_HOST_DEPLOYMENT.md).
|
||||
|
||||
## Recovery Commands
|
||||
|
||||
List durable deployment operations:
|
||||
|
||||
```sh
|
||||
python tools/deployment/govoplan-deploy.py operations \
|
||||
--directory /srv/govoplan/default
|
||||
```
|
||||
|
||||
Recover a selected failed operation after reviewing its stage evidence:
|
||||
|
||||
```sh
|
||||
python tools/deployment/govoplan-deploy.py recover \
|
||||
--directory /srv/govoplan/default \
|
||||
--operation-id <operation-id>
|
||||
```
|
||||
|
||||
The command reports whether it restored the pre-migration applied bundle,
|
||||
requires forward recovery, or needs manual intervention. Add `--apply` only
|
||||
after that decision has been reviewed.
|
||||
|
||||
## Web Update Boundary
|
||||
|
||||
@@ -317,5 +382,6 @@ The tests cover profile restrictions, secret persistence, external endpoint
|
||||
requirements, managed Garage bootstrap, S3 policy, replica validation, HAProxy
|
||||
discovery configuration, Compose service selection, secret non-disclosure,
|
||||
service-specific environment isolation, private file modes, external endpoint
|
||||
preflight, first-plan generation, apply ordering, and receipt-based
|
||||
idempotency.
|
||||
preflight, first-plan generation, apply ordering, receipt idempotency,
|
||||
hash-chained recovery journals, migration recovery boundaries, and stateless
|
||||
Kubernetes rendering.
|
||||
|
||||
@@ -0,0 +1,556 @@
|
||||
# Institutional Governance Target Architecture
|
||||
|
||||
## Status and sources
|
||||
|
||||
This document is the accepted architectural reconciliation of two product
|
||||
concepts prepared outside the repositories:
|
||||
|
||||
- `govoplan_concept_dev.md`
|
||||
- `software_big_picture.md`
|
||||
|
||||
The source concepts describe GovOPlaN as an operational governance platform for
|
||||
public institutions. This document merges that direction with the implemented
|
||||
platform state as of 2026-08-01. It is the canonical repository version of the
|
||||
direction. Gitea issues remain the source of truth for delivery state.
|
||||
|
||||
Read this together with:
|
||||
|
||||
- [Connected Governance Platform Roadmap](CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md)
|
||||
- [Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md)
|
||||
- [Module Contracts and Install Boundaries](MODULE_CONTRACTS_AND_INSTALLS.md)
|
||||
- [Datasource and Definition Graph Architecture](DATASOURCE_AND_DEFINITION_GRAPH_ARCHITECTURE.md)
|
||||
- [Capability and Infrastructure Fit](CAPABILITY_AND_INFRASTRUCTURE_FIT.md)
|
||||
- [Core Module Architecture](../../govoplan-core/docs/MODULE_ARCHITECTURE.md)
|
||||
- [Core External References and Integration Maturity](../../govoplan-core/docs/EXTERNAL_REFERENCES_AND_INTEGRATION_MATURITY.md)
|
||||
- [Core Action, Effect, and Automation Layer](../../govoplan-core/docs/ACTION_EFFECT_AUTOMATION_LAYER.md)
|
||||
|
||||
## Decision
|
||||
|
||||
GovOPlaN is a configurable **institutional governance and operations layer** for
|
||||
public institutions. It should model the institution, coordinate its work,
|
||||
connect its specialist systems, and preserve why and under whose authority an
|
||||
action occurred.
|
||||
|
||||
GovOPlaN is not intended to become one universal ERP, DMS, groupware suite,
|
||||
workflow editor, or specialist procedure. It should own the governance concepts
|
||||
that must remain understandable across those systems and support native,
|
||||
external, mirrored, synchronized, overlay, and link-only operation explicitly.
|
||||
|
||||
This changes product emphasis, not the modular architecture:
|
||||
|
||||
1. The current kernel and optional-module model remains.
|
||||
2. Existing domain owners keep their data and behavior.
|
||||
3. Cross-module semantics become explicit, versioned contracts.
|
||||
4. Successful compositions become product and sector packages, not forks or
|
||||
monolithic replacement applications.
|
||||
5. Repository creation follows a proof threshold; a noun in the information
|
||||
model does not automatically require a module.
|
||||
|
||||
## What recent work already supersedes
|
||||
|
||||
The source concepts predate several implemented foundations. These items are
|
||||
accepted as the current baseline and must not be reopened as greenfield work.
|
||||
|
||||
| Concept requirement | Reconciled current state |
|
||||
| --- | --- |
|
||||
| Slim kernel plus installable modules | Implemented through entry-point discovery, `ModuleManifest`, migrations, capabilities, interfaces, WebUI contributions, and permutation checks. |
|
||||
| Versioned cross-module contracts | Implemented through named interface ranges, capability protocols, static workspace graph checks, activation validation, and release checks. |
|
||||
| Separate headless workflow runtime and editor | Implemented as `govoplan-workflow-engine` and optional `govoplan-workflow`. Module-owned workflow baselines are versioned and reconciled without replacing local overrides. |
|
||||
| Provider-neutral external references | Implemented in Core with stable external identity and cumulative integration maturity from discovery through replacement. |
|
||||
| Governed asynchronous effects | Implemented foundations include the action/effect contract, transactional platform event outbox, module outboxes, idempotency, outcome-unknown states, reconciliation, and worker health. Coverage still varies by provider. |
|
||||
| Acting identity, function assignment, mandate, and ownership recovery | Implemented foundations span Identity, Organizations, IDM, Access, Mandates, generic ownership transfer/recovery, and audit provenance. Effective competence now resolves through a tenant-bound Mandate capability. |
|
||||
| Governed data foundations | Connectors, Datasources, Dataflow, Reporting, and Search now exist. Datasources already provides live/cached/static modes, staging, immutable materializations, and publication contracts. |
|
||||
| Task-focused projections and configured documentation | Views, view-surface declarations, configurable dashboards, and manifest-driven user/admin documentation exist. Rollout and content depth remain incremental. |
|
||||
| Encryption as an optional capability | `govoplan-encryption` now defines key-vault, content-protection, recovery, and disable-preflight boundaries. It is not a reason to move domain ownership into Core. |
|
||||
| Search without mandatory OpenSearch | PostgreSQL-backed, permission-aware search and module provider contracts exist; OpenSearch remains an optional adapter. |
|
||||
| Scale-out and recovery architecture | Stateless API/worker, shared database/object storage, event delivery, deployment, and recovery contracts are documented and partly exercised. Production profiles and drills remain active work. |
|
||||
|
||||
The institutional semantics, provider declaration gate, and first product
|
||||
compositions described here are now implemented. Subsequent work is
|
||||
**product depth and stronger maturity evidence**, not another runtime rewrite
|
||||
or an unimplemented architecture boundary.
|
||||
|
||||
## Implementation status (2026-08-01)
|
||||
|
||||
The architecture contract is implemented as a bounded, executable vertical
|
||||
slice. The portfolio declarations and provider governance gates apply to the
|
||||
whole workspace, while the four semantic domains whose repository thresholds
|
||||
were proven now have independent persistent owners:
|
||||
|
||||
| Area | Implemented state | Remaining rollout |
|
||||
| --- | --- | --- |
|
||||
| Module portfolio metadata | Core validates versioned architecture layer/kind, maturity evidence, known limits, ownership boundaries, authority modes, reference packages, target-tested providers, and migration/upgrade/recovery/security/operations documentation. | Complete for all 62 source manifests. Focused and release checks enforce `--require-architecture`; a new module cannot enter the workspace without truthful declaration and repository-local evidence. |
|
||||
| External providers | Core validates provider objects/field groups, operations, integration maturity, source authority, bounded reads, freshness/health, idempotency, conflicts, outcome-unknown handling, evidence, correction, reconciliation, outage, classification, purpose, retention, and secret handling. Addresses/CardDAV, Files remote storage, Mail SMTP/IMAP, Calendar CalDAV/ICS/Graph/EWS, and Connectors tabular/sanctions providers declare the contract and tenant-bounded secret-free runtime state. | Registry validation rejects any declared external provider without a sanitized state provider. Future adapters must cross the same gate before activation. |
|
||||
| Institutional context | Core provides versioned temporal, actor/representation, institution/unit/function/task/mandate/jurisdiction/service/case/party/work-item/workflow/approval/decision/record, legal-basis, evidence, information-governance, external-source, presentation, and geographic references. Events, automation actions, audit records, and the transactional Audit outbox preserve the envelope. | Owning modules must progressively require the relevant subset for consequential operations. |
|
||||
| Semantic provider contracts | Provider-neutral DTOs and protocols cover Mandate resolution, versioned Service definitions, procedure Parties/representation, and formal Decisions. `govoplan-mandates`, `govoplan-services`, `govoplan-parties`, and `govoplan-decisions` now persist immutable revisions behind those contracts with tenant isolation, bounded reads, replay safety, OCC, migrations, uninstall guards, permissions, APIs, capability documentation, and recovery documentation. | The owners are deliberately headless. Procedure-specific UI remains with consuming modules. |
|
||||
| Formal-outcome proof | Committee persists bodies, meetings, agenda items, votes, minutes, lifecycle events, and an optional protected local Decision projection. It resolves effective Mandate authority and records reconstructable formal Decisions through `decisions.registry` when installed. OCC, replay safety, tenant isolation, bounded reads, closure guards, and a full-height body/meeting/agenda/vote/minutes WebUI cover the aggregate. Provider-bound external or secret ballots use dynamic adapter capabilities; Committee validates and retains only aggregate counts, receipt/hash, and evidence, and rejects generic manual closure. | Concrete ballot-provider packages remain integration work because their protocol, custody, credentials, and operator evidence depend on the selected provider. This does not leave a Committee-owned ballot contract unspecified. |
|
||||
| Service-to-case proof | Services owns the persistent exact definitions consumed by Portal discovery and Cases intake. Forms owns immutable form schemas and Forms Runtime owns definition-aware drafts, validation, submission receipts, status/evidence history, and handoff references. Portal exposes a tenant-scoped service-directory WebUI whose audiences derive from trusted principal/function state, re-fetches the exact Service revision, and delegates URL, Case, Form, or Workflow launch to an installed owner. Cases and Forms Runtime retain exact Service and binding provenance, enforce tenant isolation, replay safety and OCC, and expose bounded owner/manager APIs and WebUI. | Anonymous intake, concrete attachment/signature adapters, conditional multi-page authoring, and automatic domain handoff execution are product depth on established contracts. Portal still fails closed and explains any absent launcher or runtime prerequisite. |
|
||||
| Procedure-party proof | Parties persists effective procedure roles, frozen contact snapshots, and representation powers. Existing powers cannot disappear or be silently rewritten; explicit OCC-guarded revocation is required. Cases resolves the provider capability and excludes expired/revoked authority from downstream delivery. | Procedure modules still decide which contextual fields and actions to present. |
|
||||
| Integrated institutional journey | The executable `product.service-to-decision` fixture uses real SQL-backed Services, Cases, Parties, Mandates, Committee, and Decisions providers. It carries one exact Service version through persisted Case intake, representation and frozen delivery authority, effective Mandate resolution, a body/meeting/agendum/vote/minute sequence, a persisted formal Decision, confirmed Postbox effect, Audit/record evidence, remedy/review, and protected reconstruction. A second executable path proves Portal to exact Form revision, persisted submission, and idempotent replay. | This is architecture and composition evidence. Signed, release-bound target accessibility, privacy, security, operator, delivery-provider, and recovery-drill evidence is still required before the package may claim `reference_ready`. |
|
||||
| Governed data catalogue | Datasources stores typed governance metadata, exposes bounded tenant-scoped filters and update APIs/UI, carries governance through staging, and snapshots it into immutable materializations. Reporting now persists immutable dataset, semantic-model, report, quality-plan, saved-view, and schedule revisions; executes typed semantic queries with quality gates, access checks, replay, pivoting, export/import assessment, and provenance; and exposes the governed analytical WebUI. | Rich dependency/impact traversal, additional expression functions, and policy-specific field visibility can grow on the established contracts without moving connector, transformation, or source ownership. |
|
||||
| Portfolio and change governance | Projects now persists tenant-safe, immutable portfolio/project/milestone revisions with OCC, replay, lifecycle rules, restricted memberships, Search ACL indexing, outcomes, benefits, dependencies, capacity assumptions, change impact, and institutional references. Its WebUI exposes the planning catalogue and core planning fields. | Advanced planning structures already accepted by the API can receive deeper specialized editors without creating a second Policy, Reporting, Resources, or Goals owner. |
|
||||
| Product/package governance | Signed configuration packages distinguish reference, product, sector, deployment, and integration classes; preserve parent/evidence provenance; prevent derived packages from loosening constraints; and preflight provider authority, maturity, exact binding, health, freshness, and recovery expectations. Executable product manifests now exist for governed communication and governed data/assurance and are checked in the module matrix. | Both artifacts deliberately remain product-class until target, accessibility, privacy, security, operations, and recovery evidence justifies reference readiness. |
|
||||
| Projection and release | Platform metadata, signed module catalogs, release synthesis, Ops, and role-aware Docs retain and display architecture/provider declarations. Module-owned state providers add bounded configured/active, authority, health, freshness, conflict, recovery, and observation state; ordinary-user Docs omits binding detail. Static checks validate evidence paths, and the WebUI build verifies consuming types. | Runtime-state adoption and broader portfolio presentation follow truthful provider declaration rollout. |
|
||||
|
||||
The implementation deliberately keeps shared reference contracts in Core and
|
||||
domain tables in their owners. It does not claim unsupported release maturity:
|
||||
the four extracted owners and package remain `vertical_slice`/`product` until
|
||||
target evidence supports a stronger claim. Gitea remains authoritative for
|
||||
feature depth beyond this architecture contract.
|
||||
|
||||
## Target capability layers
|
||||
|
||||
The layers describe ownership and dependency direction. They are not navigation
|
||||
groups and do not imply that every installation exposes every module.
|
||||
|
||||
| Layer | Responsibility | Current owners and declared directions |
|
||||
| --- | --- | --- |
|
||||
| 0. Runtime and meta | Composition, release, migrations, shared contracts, operations, deployment | Core, meta repository, Admin, Ops |
|
||||
| 1. Institutional foundation | Institution, tenant, identity, organization, function, authority, access, trust | Tenancy, Identity, Organizations, IDM, Access, Identity Trust, Encryption, Mandates |
|
||||
| 2. Governance and accountability | Policy, audit, risk, control, explainability, configured projection | Policy, Audit, Risk Compliance, Docs, Views, Search, Decisions |
|
||||
| 3. Human work and procedure | Intake, cases, tasks, approvals, process execution and editing | Services, Forms, Forms Runtime, Cases, Parties, Tasks, Approvals, Workflow Engine, Workflow, Tickets |
|
||||
| 4. Communication and participation | Delivery, participation, scheduling, channels, consultation | Portal, Postbox, Notifications, Mail, Campaign, Calendar, Scheduling, Poll, Appointments, Booking, Consultation, Committee, Addresses, Distribution Lists |
|
||||
| 5. Content, records, and evidence | Managed content, templates, records, knowledge, disclosure | Files, Templates, DMS, Records, Wiki, Transparency, Certificates |
|
||||
| 6. Data, reporting, and integration | Source access, staging, transformation, search, analytics, protocols | Connectors, Datasources, Dataflow, Reporting, Dashboard, REST, SOAP, XOE/V, XTA/OSCI, FIT-Connect, XRechnung, ERP adapters |
|
||||
| 7. Domain capabilities | Reusable public-sector subject matter | Projects, Procurement, Contracts, Grants, Resources, Assets, Facilities, Learning, Payments, Ledger, Permits, Inspections, Evaluation, Helpdesk |
|
||||
| 8. Product and sector packages | Versioned compositions, terminology, forms, processes, controls, reports, integration profiles | Signed configuration packages and reference packages; not runtime modules by default |
|
||||
|
||||
## Canonical institutional semantics
|
||||
|
||||
The connected model must keep these concepts distinct even where one UI
|
||||
combines them.
|
||||
|
||||
| Concept | Canonical answer | Owner or direction |
|
||||
| --- | --- | --- |
|
||||
| Institution and tenant | In which governed installation and tenant does work occur? | Tenancy and Organizations |
|
||||
| Organization and unit | Where is responsibility situated? | Organizations |
|
||||
| Function | Which named organizational responsibility can an incumbent hold? | Organizations |
|
||||
| Identity and account | Who is the person or machine, and through which account do they act? | Identity and Access |
|
||||
| Function assignment | Who holds or represents a function, for which interval and source? | IDM |
|
||||
| Role and permission | What application behavior may the acting principal perform? | Access, constrained by Policy |
|
||||
| Mandate and jurisdiction | Why is an institution, unit, or function competent to act on this subject, territory, population, or interval? | Mandates |
|
||||
| Service | What governed promise can an institution offer, to whom, under which prerequisites, evidence, channel, deadline, and responsibility? | Services; Portal presents it |
|
||||
| Case | Which concrete administrative matter is being handled? | Cases |
|
||||
| Party | In what procedural capacity does a person or organization participate, and who may represent or receive for it? | Parties; Identity/Organizations remain the subject owners |
|
||||
| Work item | What must a responsible actor do next? | Tasks and domain modules |
|
||||
| Workflow | How is work coordinated, including waits, human hand-offs, and governed actions? | Workflow Engine; Workflow is the optional editor |
|
||||
| Approval | Has a proposed action passed a configured review or separation-of-duties gate? | Approvals |
|
||||
| Decision | What formal institutional outcome was reached, by which competent authority, on which facts, rules, evidence, reasoning, and review path? | Decisions |
|
||||
| Evidence and record | What proves the input, state, action, effect, correction, and retained institutional memory? | Domain owner, Files/DMS/Records, and Audit |
|
||||
|
||||
### Extracted semantic modules
|
||||
|
||||
Four horizontal concepts passed the repository proof threshold. Their Core
|
||||
DTOs and provider protocols remain neutral; their persistent data, lifecycle,
|
||||
security, APIs, migrations, and recovery behavior now live in independent
|
||||
repositories.
|
||||
|
||||
#### Mandates
|
||||
|
||||
Mandates should own public or internal tasks, jurisdiction, responsibility,
|
||||
decision/signature authority, legal or organizational basis, and effective
|
||||
history. Organizations continues to own structures and functions; IDM owns
|
||||
incumbency; Access owns permissions; Policy owns constraints.
|
||||
|
||||
`govoplan-mandates` answers: *Was this function competent to act for this case
|
||||
at the relevant time, and on what basis?* Its resolver evaluates effective
|
||||
time, task, authority, unit, function, jurisdiction, subject, conflicts, legal
|
||||
basis, and evidence deterministically. Missing or ambiguous authority fails
|
||||
closed.
|
||||
|
||||
#### Services
|
||||
|
||||
Services should own versioned service definitions: audience, prerequisites,
|
||||
legal basis, evidence, fees, deadlines, channels, responsible unit/function,
|
||||
jurisdiction, forms, case/workflow/result bindings, remedies, service levels,
|
||||
and publication status. Portal presents and starts services but should not own
|
||||
their institutional definition.
|
||||
|
||||
`govoplan-services` now owns those exact versioned definitions. Portal is the
|
||||
first presentation consumer and Cases freezes the selected revision into its
|
||||
intake context. Availability is an independent capability so publication does
|
||||
not imply that all runtime prerequisites are satisfied.
|
||||
|
||||
#### Parties
|
||||
|
||||
Parties should own procedure-local roles and relationships: applicant,
|
||||
respondent, beneficiary, representative, joint applicant, delivery recipient,
|
||||
power or authority to represent, and permitted/preferred channels for the
|
||||
matter. Identity answers who the subject is; Organizations answers which
|
||||
institutional unit it is; Addresses owns contact points; Parties answers how
|
||||
the subject participates here.
|
||||
|
||||
`govoplan-parties` owns the shared effective-dated lifecycle. Cases retains a
|
||||
bounded compatibility projection only when the module is absent; that fallback
|
||||
contains no representation lifecycle and cannot silently become a second
|
||||
authority source.
|
||||
|
||||
#### Decisions
|
||||
|
||||
Decisions should own formal outcomes: subject, type, competent authority,
|
||||
facts, evidence, applicable rule versions, reasoning, operative result,
|
||||
conditions, effect, delivery/publication, remedy/review, correction, revocation,
|
||||
and links to observed effects. Approvals own review gates; Poll owns response
|
||||
collection; Committee owns deliberation, meetings, and votes; Workflow owns
|
||||
coordination.
|
||||
|
||||
`govoplan-decisions` owns the persistent lifecycle and protected reconstruction
|
||||
surface. Committee supplies deliberation context and records through the
|
||||
provider capability. Consumers retain exact Decision references without
|
||||
gaining table access.
|
||||
|
||||
## Source authority and integration maturity
|
||||
|
||||
Two independent dimensions must be recorded. They must not be collapsed into a
|
||||
single `sync` flag.
|
||||
|
||||
### Source-authority mode
|
||||
|
||||
| Mode | Meaning |
|
||||
| --- | --- |
|
||||
| `native_authoritative` | GovOPlaN owns the authoritative object and lifecycle. |
|
||||
| `external_authoritative` | The external system owns the object; GovOPlaN reads or acts through it. |
|
||||
| `external_mirror` | The external system is authoritative and GovOPlaN keeps a governed local projection or immutable snapshots. |
|
||||
| `governed_sync` | Both sides may change supported fields under explicit conflict and reconciliation rules. |
|
||||
| `governance_overlay` | GovOPlaN owns policy, responsibility, evidence, or coordination around an externally executed object. |
|
||||
| `linked_reference` | GovOPlaN keeps only a stable link and minimal display/provenance metadata. |
|
||||
|
||||
Authority may be declared per tenant, organization, service, object type,
|
||||
object, field group, or process step. A broad default must not hide a narrower
|
||||
override.
|
||||
|
||||
### Integration maturity
|
||||
|
||||
The implemented maturity ladder remains `discover`, `link`, `search`, `read`,
|
||||
`publish`, `synchronize`, `migrate`, and `replace`. Maturity says what an
|
||||
adapter can do. Source-authority mode says who owns truth in a particular
|
||||
configuration. For example, a connector may support `synchronize`, while a
|
||||
tenant deliberately configures it as `external_mirror`.
|
||||
|
||||
### Provider declaration
|
||||
|
||||
Every provider that reads or causes external effects must declare:
|
||||
|
||||
- owned object and field groups;
|
||||
- supported source-authority modes and integration maturity;
|
||||
- read, write, delete, search, preview, and dry-run operations;
|
||||
- revision/concurrency tokens, freshness, health, and bounded-read limits;
|
||||
- idempotency, retry, timeout, conflict, and outcome-unknown behavior;
|
||||
- evidence, audit, correction, rollback/compensation, and reconciliation paths;
|
||||
- degraded and outage behavior;
|
||||
- classification, purpose, retention, and secret-handling requirements.
|
||||
|
||||
The common provider declaration composes the external-reference, action/effect,
|
||||
connector-lifecycle, capability, operational-check, and documentation
|
||||
contracts. Core, release tooling, Ops, Docs, and configuration-package
|
||||
preflight validate it; Registry refuses to activate a declared external
|
||||
provider without bounded, sanitized runtime state.
|
||||
|
||||
## Cross-cutting contracts
|
||||
|
||||
The following contracts are mandatory for consequential domain objects. They
|
||||
should be shared reference DTOs and provider protocols, not shared domain
|
||||
tables in Core.
|
||||
|
||||
1. **Time and history:** valid-from/to, recorded-at, superseded-at, revision,
|
||||
change reason, and stable identity.
|
||||
2. **Actor and representation:** real account/identity, system or service
|
||||
account, represented account/function/party, delegation or power, and
|
||||
mandate reference.
|
||||
3. **Institutional context:** tenant, institution, organization unit, function,
|
||||
task/mandate, jurisdiction, service, case, and decision references.
|
||||
4. **Legal and policy basis:** typed, versioned references to rules,
|
||||
obligations, policies, exceptions, and the effective decision source.
|
||||
5. **Requested and observed effect:** intent, approval, dispatch, possible
|
||||
execution, confirmation, reconciliation, correction, and terminal evidence.
|
||||
6. **Evidence and provenance:** source, version, checksum, derivation,
|
||||
responsible actor, timestamps, and inspection links.
|
||||
7. **Information governance:** classification, purpose, legal basis, retention,
|
||||
hold, minimization, and disclosure state.
|
||||
8. **External source:** system/profile/object identity, authority mode,
|
||||
maturity, version, freshness, health, and conflict state.
|
||||
9. **Presentation:** language, accessibility, channel, explanation, and
|
||||
configured availability.
|
||||
|
||||
Existing contracts already cover substantial parts of items 1, 2, 5, 6, 8,
|
||||
and 9. New work should extend those contracts instead of creating parallel DTO
|
||||
families.
|
||||
|
||||
## Existing module direction changes
|
||||
|
||||
### Datasources becomes the governed data and register catalogue
|
||||
|
||||
The implemented live/cached/static, staging, immutable materialization, and
|
||||
publication model includes typed governance metadata for owner/steward,
|
||||
authoritative source and authority mode, legal basis and purpose, semantic
|
||||
definition, quality and freshness policy, classification, transfer agreement,
|
||||
correction process, affected services/processes, and dependent flows,
|
||||
reports, controls, and decisions. Connector credentials and protocol behavior
|
||||
remain outside Datasources.
|
||||
|
||||
### Projects grows into portfolio and change governance
|
||||
|
||||
The Projects boundary already includes portfolios and goals. Extend it through
|
||||
versioned objectives/outcomes, dependencies, capacity, benefits, change impact,
|
||||
and links to mandates, services, risks, contracts, resources, and indicators.
|
||||
Do not create a separate Goals module before more than one domain proves an
|
||||
independent goal lifecycle.
|
||||
|
||||
### Reporting becomes evidence-backed institutional measurement
|
||||
|
||||
Every report, measure, and indicator should explain the institutional question
|
||||
or obligation it serves, owner, source/materialization and flow revision,
|
||||
freshness/quality, calculation version, visibility/purpose limits, publication,
|
||||
and decisions or actions that consumed it. Reporting owns presentation and
|
||||
execution; source and transformation owners retain their domains.
|
||||
|
||||
### Risk Compliance becomes the horizontal assurance model
|
||||
|
||||
Sanctions screening remains a complete vertical slice. The broader reusable
|
||||
model is:
|
||||
|
||||
```text
|
||||
Obligation -> governed object -> risk -> control -> evidence -> finding -> measure -> effectiveness review
|
||||
```
|
||||
|
||||
Risk Compliance now persists that effective-dated, immutable-revision assurance
|
||||
graph, exposes bounded tenant-safe traversal/search/editing, and projects each
|
||||
completed sanctions run into it idempotently. Policy
|
||||
owns enforceable rules and decisions; Audit owns immutable event evidence;
|
||||
domain modules own the governed objects and corrective actions.
|
||||
|
||||
### Connectors exposes authority and effect behavior
|
||||
|
||||
Connector direction (`consume`, `publish`, `bidirectional`) remains useful but
|
||||
is not enough. Profiles and bindings need the source-authority mode and
|
||||
provider declaration above. ERP remains an integration family: finance,
|
||||
workforce, procurement, asset, or other domain modules own semantics while
|
||||
connectors own transport and source interaction.
|
||||
|
||||
### Geography starts as a reference contract
|
||||
|
||||
Before adding a `govoplan-geo` module, define a common reference shape for
|
||||
coordinates, geometry, administrative area, address/location, CRS, source,
|
||||
accuracy, validity, and external GIS identity. Create a repository only when
|
||||
GovOPlaN must own spatial datasets, topology, or independent geospatial
|
||||
lifecycles rather than link to an external GIS.
|
||||
|
||||
## Product and sector packages
|
||||
|
||||
A module says what capability can exist. A product package says how capabilities
|
||||
work together for a bounded outcome. A sector package specializes vocabulary,
|
||||
forms, rules, process baselines, controls, reports, and integration profiles
|
||||
without forking the platform.
|
||||
|
||||
The signed configuration-package mechanism distinguishes:
|
||||
|
||||
- **reference package:** tested composition proving a journey and its recovery
|
||||
behavior;
|
||||
- **product package:** reusable operating capability such as governed
|
||||
communication, service-to-decision, procurement/contracts, or governed BI;
|
||||
- **sector package:** institutional specialization such as municipality,
|
||||
university/research, ministry/program, regulator, grants authority, or
|
||||
committee/council;
|
||||
- **deployment profile:** supported infrastructure and operational topology;
|
||||
- **integration profile:** supported set of external systems, authority modes,
|
||||
bindings, and health expectations.
|
||||
|
||||
Packages may require modules and capabilities, but package definitions remain
|
||||
configuration and evidence. They do not gain access to module-owned tables.
|
||||
|
||||
## Module portfolio metadata
|
||||
|
||||
Repository category is not capability maturity. The runtime manifest, release
|
||||
catalog, Docs projection, and meta repository inventory use one
|
||||
machine-readable declaration with at least:
|
||||
|
||||
- architecture layer and module kind;
|
||||
- lifecycle/maturity claim: `concept`, `scaffold`, `vertical_slice`,
|
||||
`reference_ready`, `supported`, or `lts`;
|
||||
- evidence supporting the claim and known limits;
|
||||
- supported source-authority modes;
|
||||
- owned and explicitly non-owned concepts;
|
||||
- provided/required capabilities and interfaces;
|
||||
- reference packages and target-tested providers;
|
||||
- migration, upgrade, recovery, security, and operations documentation.
|
||||
|
||||
Maturity is a release claim and must be checked against evidence. A manifest
|
||||
must not become “supported” merely because a maintainer changes one string.
|
||||
|
||||
Create a repository only when the capability has distinct data ownership,
|
||||
independent installability, technical assets, a security/lifecycle profile, a
|
||||
release reason, more than one consumer or a proven reference process, and tests
|
||||
that justify the boundary. Otherwise use a shared DTO, provider capability,
|
||||
submodule, configuration fragment, package, or profile.
|
||||
|
||||
## Implemented migration sequence
|
||||
|
||||
### 0. Align the portfolio and contracts - complete
|
||||
|
||||
- This reconciliation is canonical in the meta repository and mirrored to the
|
||||
Gitea wiki.
|
||||
- All 62 source manifests carry validated evidence-based architecture metadata.
|
||||
- External-reference, action/effect, operational-health, ownership, policy,
|
||||
audit, and documentation primitives compose into one enforced provider
|
||||
declaration and sanitized runtime-state contract.
|
||||
- Institutional context, legal basis, evidence, presentation, external source,
|
||||
information governance, temporal revision, and geo references are shared
|
||||
Core DTOs rather than shared domain tables.
|
||||
|
||||
### 1. Prove responsibility and formal outcome - complete
|
||||
|
||||
- Mandate and Decision contracts, deterministic resolution, lifecycle
|
||||
transitions, persistence providers, APIs, permissions, migrations, recovery,
|
||||
and tests are implemented.
|
||||
- Committee and the SQL-backed institutional fixture prove effective-time
|
||||
authority, persisted meeting/agendum/vote/minute context, approval context,
|
||||
reasoning, evidence, observed effect, correction/revision rules, protected
|
||||
reconstruction, and review references.
|
||||
- The independent Mandates and Decisions repositories were created only after
|
||||
persistence and reuse passed the repository threshold.
|
||||
|
||||
### 2. Separate service and party semantics - complete
|
||||
|
||||
- Portal remains the presentation surface while Services owns reusable,
|
||||
versioned definitions and explainable availability.
|
||||
- Parties owns procedure roles, contact snapshots, and append-only
|
||||
representation/revocation authority; Cases consumes the common resolver.
|
||||
- `product.service-to-decision` proves both through a portable administrative
|
||||
service composition.
|
||||
- Forms owns immutable, versioned schemas while Forms Runtime owns drafts,
|
||||
server validation, submission receipts, status/evidence history, and exact
|
||||
Service/Form provenance. Portal delegates Form launch through the runtime
|
||||
capability and fails closed when it is unavailable.
|
||||
|
||||
### 3. Complete governed data, portfolio, and assurance - vertical slices complete
|
||||
|
||||
- Datasources carries typed governance through staging and immutable
|
||||
materializations, with bounded catalogue filters and dependency references.
|
||||
- Reporting owns immutable semantic definitions, safe execution, quality gates,
|
||||
provenance, schedules, saved views, pivoting, and export/import assessment
|
||||
without taking source or transformation ownership.
|
||||
- Risk Compliance persists the horizontal obligation/risk/control/evidence/
|
||||
finding/measure graph and projects sanctions runs idempotently.
|
||||
- Projects persists portfolio/outcome/change-governance revisions as a
|
||||
consuming domain without becoming a second policy or reporting engine.
|
||||
|
||||
### 4. Package repeatable public-sector outcomes - complete at product maturity
|
||||
|
||||
- Governed communication, governed data/assurance, and service-to-decision are
|
||||
portable product package manifests with repository-local evidence.
|
||||
- Package preflight enforces module, capability, provider authority, health,
|
||||
freshness, and recovery expectations without cross-module table access.
|
||||
- Sector and `reference_ready` claims remain gated on target-environment,
|
||||
recovery, accessibility, privacy, security, and operator evidence. This is a
|
||||
maturity gate, not missing architecture implementation.
|
||||
|
||||
## What remains after the executable architecture slice
|
||||
|
||||
The remaining work is not another Core or cross-module architecture rewrite.
|
||||
It falls into two explicitly different categories, neither of which can be
|
||||
truthfully completed by adding generic platform code:
|
||||
|
||||
1. **Concrete provider packages:** the Committee ballot adapter contract is
|
||||
complete, but a real secret/electronic ballot provider requires a selected
|
||||
protocol and product decisions for voter eligibility, custody, secrecy,
|
||||
recount, challenge, retention, and operational assurance. Equivalent future
|
||||
adapters must satisfy the declared provider and recovery gates.
|
||||
Provider selection and certification are tracked in
|
||||
[Committee #1](https://git.add-ideas.de/GovOPlaN/govoplan-committee/issues/1).
|
||||
2. **Target-produced maturity evidence:** `reference_ready`, `supported`, and
|
||||
`lts` cannot be generated from source code. An exact release and deployment
|
||||
must produce signed, expiring accessibility, privacy, security, operator,
|
||||
provider, backup/restore, rollback, and recovery-drill evidence. The verifier
|
||||
and schemas are implemented; the actual claims require those real runs.
|
||||
The pinned-release evidence run is tracked in
|
||||
[GovOPlaN #37](https://git.add-ideas.de/GovOPlaN/govoplan/issues/37).
|
||||
|
||||
Forms and Forms Runtime no longer constitute an architecture gap. Remaining
|
||||
depth includes anonymous/public identity profiles, concrete file and signature
|
||||
providers, conditional multi-page/localized authoring, and automatic handoff
|
||||
adapters. Those additions use the implemented immutable definition, runtime,
|
||||
policy, evidence, service-launch, and domain-owner boundaries rather than
|
||||
requiring another platform split. They are tracked as
|
||||
[Forms #3](https://git.add-ideas.de/GovOPlaN/govoplan-forms/issues/3) and
|
||||
Forms Runtime [#2](https://git.add-ideas.de/GovOPlaN/govoplan-forms-runtime/issues/2),
|
||||
[#3](https://git.add-ideas.de/GovOPlaN/govoplan-forms-runtime/issues/3), and
|
||||
[#4](https://git.add-ideas.de/GovOPlaN/govoplan-forms-runtime/issues/4).
|
||||
|
||||
Everything else described as architecture in this document now has a
|
||||
repository owner, versioned contract, bounded implementation, migration and
|
||||
recovery boundary where state exists, documentation, and executable evidence.
|
||||
Further work in those modules is product breadth, UX depth, provider adoption,
|
||||
and evidence renewal.
|
||||
|
||||
## Delivery tracking
|
||||
|
||||
The completed cross-repository architecture epic is
|
||||
[GovOPlaN #29](https://git.add-ideas.de/GovOPlaN/govoplan/issues/29).
|
||||
Its implementation work packages and resulting owners are:
|
||||
|
||||
- [Core #279](https://git.add-ideas.de/GovOPlaN/govoplan-core/issues/279):
|
||||
validated module architecture and provider authority declarations;
|
||||
- [Core #280](https://git.add-ideas.de/GovOPlaN/govoplan-core/issues/280):
|
||||
shared institutional-context and governed reference primitives;
|
||||
- [GovOPlaN #30](https://git.add-ideas.de/GovOPlaN/govoplan/issues/30) and
|
||||
[govoplan-mandates](https://git.add-ideas.de/GovOPlaN/govoplan-mandates):
|
||||
Mandates semantics and persistent resolver;
|
||||
- [GovOPlaN #31](https://git.add-ideas.de/GovOPlaN/govoplan/issues/31) and
|
||||
[govoplan-services](https://git.add-ideas.de/GovOPlaN/govoplan-services):
|
||||
Services semantics, catalogue, and availability;
|
||||
- [GovOPlaN #32](https://git.add-ideas.de/GovOPlaN/govoplan/issues/32) and
|
||||
[govoplan-parties](https://git.add-ideas.de/GovOPlaN/govoplan-parties):
|
||||
Parties and representation semantics and resolver;
|
||||
- [GovOPlaN #33](https://git.add-ideas.de/GovOPlaN/govoplan/issues/33) and
|
||||
[govoplan-decisions](https://git.add-ideas.de/GovOPlaN/govoplan-decisions):
|
||||
formal Decisions semantics and registry;
|
||||
- [Datasources #6](https://git.add-ideas.de/GovOPlaN/govoplan-datasources/issues/6):
|
||||
governed data/register catalogue;
|
||||
- [Risk Compliance #7](https://git.add-ideas.de/GovOPlaN/govoplan-risk-compliance/issues/7):
|
||||
horizontal assurance graph;
|
||||
- [GovOPlaN #34](https://git.add-ideas.de/GovOPlaN/govoplan/issues/34):
|
||||
product and sector package classes; and
|
||||
- [Docs #19](https://git.add-ideas.de/GovOPlaN/govoplan-docs/issues/19):
|
||||
configured architecture, maturity, and source-authority explanations;
|
||||
- [Forms #2](https://git.add-ideas.de/GovOPlaN/govoplan-forms/issues/2):
|
||||
immutable reusable definitions and the designer surface; and
|
||||
- [Forms Runtime #1](https://git.add-ideas.de/GovOPlaN/govoplan-forms-runtime/issues/1):
|
||||
definition-aware submissions and Portal service launch.
|
||||
|
||||
Existing Projects #1, Reporting #4, Portal #1, Cases #1, Datasources #1,
|
||||
Risk Compliance #2, GovOPlaN #14, and GovOPlaN #19 carry product-depth and
|
||||
reference-readiness work instead of duplicating the completed architecture
|
||||
contract.
|
||||
|
||||
## Completion evidence
|
||||
|
||||
The architecture direction is established by the following executable and
|
||||
machine-enforced evidence:
|
||||
|
||||
- the `product.service-to-decision` composition and SQL-backed golden fixture
|
||||
retain institutional context from service entry through a persisted case,
|
||||
party, authority/work context, committee deliberation, decision, observed
|
||||
communication effect, minute/record, and review references;
|
||||
- the Portal/Form journey retains the exact published Service and Form
|
||||
revisions through persisted draft state, validates on the server, and returns
|
||||
the same submission on an idempotent launch replay;
|
||||
- the system can answer who acted, for whom, in which function, under which
|
||||
mandate and jurisdiction, using which rule and evidence versions;
|
||||
- every implemented external binding declares authority mode, maturity,
|
||||
operations, health, freshness, conflict, and recovery behavior, and Registry
|
||||
rejects a declaration without sanitized runtime state;
|
||||
- every material report or decision can be reconstructed from governed source
|
||||
and transformation versions;
|
||||
- product/package manifests are portable without cross-module table access or
|
||||
code forks, while future sector packages inherit the same signed-package
|
||||
constraints; and
|
||||
- documentation and Ops explain the configured composition and its limits to
|
||||
users, administrators, operators, and auditors.
|
||||
|
||||
These criteria complete the architecture contract at `vertical_slice` and
|
||||
`product` maturity. They do not waive the separately enforced evidence needed
|
||||
for a module or package to claim `reference_ready`, `supported`, or `lts`.
|
||||
The capability-fit verifier now computes that cumulative readiness gate from
|
||||
independently signed, expiring claims bound to the exact assessed release,
|
||||
installed payload, deployment subject, controls, and artifact hashes. Actual
|
||||
target runs and recovery drills remain operator-produced evidence.
|
||||
@@ -0,0 +1,147 @@
|
||||
# Recovery And Rollback Guarantees
|
||||
|
||||
## Principle
|
||||
|
||||
GovOPlaN must prove recovery claims with durable state recorded before and
|
||||
after side effects. A failed operation is not automatically rolled back merely
|
||||
because the previous application image still exists. Database schema and
|
||||
external effects may make release rollback unsafe.
|
||||
|
||||
Core therefore distinguishes five recovery modes:
|
||||
|
||||
| Mode | Meaning |
|
||||
| --- | --- |
|
||||
| `atomic` | One database transaction either commits or rolls back. No external effect is claimed. |
|
||||
| `compensation` | Durable evidence identifies explicit inverse actions for completed effects. |
|
||||
| `snapshot_restore` | A separately verified backup reference and restore procedure exist. |
|
||||
| `forward_recovery` | Repair or resume the current version; reverting code/configuration is not claimed safe. |
|
||||
| `irreversible` | No automated recovery is claimed and an approval reference is mandatory. |
|
||||
|
||||
An operation plan must include verification steps. Compensation requires named
|
||||
compensation steps, snapshot restore requires a verified backup reference,
|
||||
forward recovery requires repair steps, and irreversible work requires explicit
|
||||
approval.
|
||||
|
||||
## Core Recovery Ledger
|
||||
|
||||
Core stores recovery operations and append-only, hash-chained checkpoints in
|
||||
PostgreSQL. The contract provides:
|
||||
|
||||
- installation/module/resource identity;
|
||||
- an idempotency key bound to a canonical request hash;
|
||||
- recovery mode, preconditions, verification steps, and references;
|
||||
- optional runtime lease holder and fencing token;
|
||||
- explicit planned, prepared, running, recovery-required, recovering,
|
||||
succeeded, recovered, failed, outcome-unknown, and manual-intervention states;
|
||||
- an evidence-chain head and sequence count;
|
||||
- rejection of plaintext secrets in metadata or evidence.
|
||||
|
||||
Preparation cannot succeed without durable precondition evidence. A non-atomic
|
||||
operation cannot hide a partial effect by transitioning directly from running
|
||||
to failed. Success and recovery require explicit verification evidence with at
|
||||
least one check. The ledger verifies its hash chain before evidence is trusted.
|
||||
|
||||
This is a platform contract, not an assertion that every existing module
|
||||
operation has adopted it. Module operations with external or multi-resource
|
||||
effects must be migrated to the ledger before claiming these guarantees.
|
||||
|
||||
## Deployment Journal
|
||||
|
||||
Every `govoplan-deploy apply` begins an operation journal before it pulls images
|
||||
or mutates runtime state. The private installation directory records:
|
||||
|
||||
```text
|
||||
operations/<operation-id>/operation.json
|
||||
operations/<operation-id>/before/
|
||||
applied-state/
|
||||
```
|
||||
|
||||
Each stage is hash-chained. The previous applied bundle is copied with per-file
|
||||
SHA-256 evidence. Applied state is replaced atomically after health verification;
|
||||
an interrupted replacement restores its previous directory.
|
||||
New journals also bind the complete desired deployment plan, snapshot
|
||||
availability, failure summary, recovery mode, and terminal status to the
|
||||
evidence chain. Recovery verifies every snapshot entry and checksum before it
|
||||
changes any live bundle file, then replaces each live file atomically. A crash
|
||||
between file replacements is recoverable by rerunning the same idempotent
|
||||
recovery command under the deployment lock.
|
||||
|
||||
Inspect operations:
|
||||
|
||||
```sh
|
||||
python tools/deployment/govoplan-deploy.py operations \
|
||||
--directory /srv/govoplan/default
|
||||
```
|
||||
|
||||
Recover the latest failed operation, or provide its identifier:
|
||||
|
||||
```sh
|
||||
python tools/deployment/govoplan-deploy.py recover \
|
||||
--directory /srv/govoplan/default \
|
||||
--operation-id 20260801T120000Z-1234abcd
|
||||
```
|
||||
|
||||
Add `--apply` only after reviewing the reported action.
|
||||
|
||||
## Migration Boundary
|
||||
|
||||
Before database migration starts, a failed deployment with a verified prior
|
||||
applied snapshot may restore its prior release/configuration bundle and
|
||||
reconcile that desired state.
|
||||
|
||||
As soon as migration starts, the journal permanently changes to
|
||||
`forward_recovery`. It will not restore old application configuration because
|
||||
old code may not understand the new schema. Recovery then means one of:
|
||||
|
||||
1. fix and re-run the current release;
|
||||
2. deploy a newer compatible repair release;
|
||||
3. restore a separately verified, coordinated database/object/key backup and
|
||||
then deploy the matching release.
|
||||
|
||||
The deployment tool does not create or validate that database backup. A
|
||||
`backup-required` annotation on the Kubernetes migration Job is an operator
|
||||
gate, not backup evidence. Production automation must provide a backup hook or
|
||||
external backup controller whose artifact, timestamp, scope, encryption key,
|
||||
and restore test can be referenced from the recovery record.
|
||||
|
||||
## Scaled Nodes
|
||||
|
||||
Recovery actions must be safe across replicas:
|
||||
|
||||
- drain affected API and worker nodes before incompatible changes;
|
||||
- use the deployment-wide PostgreSQL advisory lock for schema migration;
|
||||
- use distributed leases and fencing tokens for singleton or externally
|
||||
visible effects;
|
||||
- use idempotency keys for retried commands and jobs;
|
||||
- retain shared object keys and database references until deletion succeeds;
|
||||
- classify uncertain external outcomes instead of retrying blindly;
|
||||
- verify the exact software/module composition after replacement.
|
||||
|
||||
Campaign generated-message objects now follow this model: object writes are
|
||||
compensated when a build fails before database commit, workers verify stored
|
||||
size and digest before delivery, and retention keeps the database reference
|
||||
when storage deletion fails. A hard process loss between object creation and
|
||||
database commit can still leave an orphan object; an inventory reconciler is a
|
||||
separate operational slice and must use the build-specific object prefix.
|
||||
|
||||
## Required Drills
|
||||
|
||||
Record evidence for at least these scenarios before production acceptance:
|
||||
|
||||
1. Kill an API replica and verify traffic continues without session loss.
|
||||
2. Drain and replace a worker while work is queued and while one job is active.
|
||||
3. Start two migration jobs and verify only one mutates schema.
|
||||
4. Kill the fenced scheduler and verify one replacement acquires a higher
|
||||
fencing token.
|
||||
5. Fail deployment before migration and restore the prior applied bundle.
|
||||
6. Fail deployment after migration and verify old configuration is not
|
||||
restored.
|
||||
7. Restore PostgreSQL, object storage, and encryption keys to one coordinated
|
||||
recovery point and verify representative object hashes.
|
||||
8. Interrupt object storage during Campaign build and retention and verify
|
||||
compensation/reference-preservation behavior.
|
||||
9. Tamper with a deployment or Core recovery checkpoint and verify chain
|
||||
validation rejects it.
|
||||
|
||||
No runbook, status badge, or green health endpoint substitutes for a dated,
|
||||
repeatable restore drill against the actual deployment topology.
|
||||
@@ -2,9 +2,16 @@
|
||||
|
||||
## Status
|
||||
|
||||
This is the selected product-development sequence as of 2026-07-21. It turns
|
||||
the long-term connected-platform roadmap into five demonstrable journeys while
|
||||
the Workflow program remains deliberately deferred.
|
||||
This is the selected product-development sequence, originally chosen on
|
||||
2026-07-21 and reconciled with the implemented platform on 2026-07-31. It turns
|
||||
the long-term connected-platform roadmap into five demonstrable journeys.
|
||||
Workflow Engine and the optional Workflow editor now exist, but they are used
|
||||
by a stage only when its package explicitly composes and proves them; Workflow
|
||||
is not an automatic dependency of every journey.
|
||||
|
||||
The institutional semantics and source-authority model applied to these stages
|
||||
are defined in the
|
||||
[Institutional Governance Target Architecture](INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md).
|
||||
|
||||
The stages are ordered, but they are not monolithic releases. Each stage is
|
||||
delivered as small, reviewable, green increments and is complete only when its
|
||||
|
||||
@@ -31,6 +31,7 @@ Generated from `repositories.json`. Use that JSON file as the machine-readable s
|
||||
| `govoplan-dashboard` | `platform` | `../govoplan-dashboard` | [govoplan-dashboard](https://git.add-ideas.de/GovOPlaN/govoplan-dashboard) |
|
||||
| `govoplan-dataflow` | `platform` | `../govoplan-dataflow` | [govoplan-dataflow](https://git.add-ideas.de/GovOPlaN/govoplan-dataflow) |
|
||||
| `govoplan-datasources` | `platform` | `../govoplan-datasources` | [govoplan-datasources](https://git.add-ideas.de/GovOPlaN/govoplan-datasources) |
|
||||
| `govoplan-decisions` | `domain` | `../govoplan-decisions` | [govoplan-decisions](https://git.add-ideas.de/GovOPlaN/govoplan-decisions) |
|
||||
| `govoplan-dms` | `domain` | `../govoplan-dms` | [govoplan-dms](https://git.add-ideas.de/GovOPlaN/govoplan-dms) |
|
||||
| `govoplan-dist-lists` | `domain` | `../govoplan-dist-lists` | [govoplan-dist-lists](https://git.add-ideas.de/GovOPlaN/govoplan-dist-lists) |
|
||||
| `govoplan-docs` | `platform` | `../govoplan-docs` | [govoplan-docs](https://git.add-ideas.de/GovOPlaN/govoplan-docs) |
|
||||
@@ -50,10 +51,12 @@ Generated from `repositories.json`. Use that JSON file as the machine-readable s
|
||||
| `govoplan-learning` | `domain` | `../govoplan-learning` | [govoplan-learning](https://git.add-ideas.de/GovOPlaN/govoplan-learning) |
|
||||
| `govoplan-ledger` | `domain` | `../govoplan-ledger` | [govoplan-ledger](https://git.add-ideas.de/GovOPlaN/govoplan-ledger) |
|
||||
| `govoplan-mail` | `domain` | `../govoplan-mail` | [govoplan-mail](https://git.add-ideas.de/GovOPlaN/govoplan-mail) |
|
||||
| `govoplan-mandates` | `domain` | `../govoplan-mandates` | [govoplan-mandates](https://git.add-ideas.de/GovOPlaN/govoplan-mandates) |
|
||||
| `govoplan-notifications` | `platform` | `../govoplan-notifications` | [govoplan-notifications](https://git.add-ideas.de/GovOPlaN/govoplan-notifications) |
|
||||
| `govoplan-ops` | `platform` | `../govoplan-ops` | [govoplan-ops](https://git.add-ideas.de/GovOPlaN/govoplan-ops) |
|
||||
| `govoplan-organizations` | `platform` | `../govoplan-organizations` | [govoplan-organizations](https://git.add-ideas.de/GovOPlaN/govoplan-organizations) |
|
||||
| `govoplan-payments` | `domain` | `../govoplan-payments` | [govoplan-payments](https://git.add-ideas.de/GovOPlaN/govoplan-payments) |
|
||||
| `govoplan-parties` | `domain` | `../govoplan-parties` | [govoplan-parties](https://git.add-ideas.de/GovOPlaN/govoplan-parties) |
|
||||
| `govoplan-permits` | `domain` | `../govoplan-permits` | [govoplan-permits](https://git.add-ideas.de/GovOPlaN/govoplan-permits) |
|
||||
| `govoplan-policy` | `platform` | `../govoplan-policy` | [govoplan-policy](https://git.add-ideas.de/GovOPlaN/govoplan-policy) |
|
||||
| `govoplan-poll` | `domain` | `../govoplan-poll` | [govoplan-poll](https://git.add-ideas.de/GovOPlaN/govoplan-poll) |
|
||||
@@ -67,6 +70,7 @@ Generated from `repositories.json`. Use that JSON file as the machine-readable s
|
||||
| `govoplan-risk-compliance` | `domain` | `../govoplan-risk-compliance` | [govoplan-risk-compliance](https://git.add-ideas.de/GovOPlaN/govoplan-risk-compliance) |
|
||||
| `govoplan-scheduling` | `domain` | `../govoplan-scheduling` | [govoplan-scheduling](https://git.add-ideas.de/GovOPlaN/govoplan-scheduling) |
|
||||
| `govoplan-search` | `platform` | `../govoplan-search` | [govoplan-search](https://git.add-ideas.de/GovOPlaN/govoplan-search) |
|
||||
| `govoplan-services` | `domain` | `../govoplan-services` | [govoplan-services](https://git.add-ideas.de/GovOPlaN/govoplan-services) |
|
||||
| `govoplan-tasks` | `domain` | `../govoplan-tasks` | [govoplan-tasks](https://git.add-ideas.de/GovOPlaN/govoplan-tasks) |
|
||||
| `govoplan-templates` | `domain` | `../govoplan-templates` | [govoplan-templates](https://git.add-ideas.de/GovOPlaN/govoplan-templates) |
|
||||
| `govoplan-tenancy` | `platform` | `../govoplan-tenancy` | [govoplan-tenancy](https://git.add-ideas.de/GovOPlaN/govoplan-tenancy) |
|
||||
|
||||
@@ -1,156 +1,183 @@
|
||||
# Scaling And Multi-Host Deployment
|
||||
|
||||
## What Is Implemented
|
||||
## Implemented Contract
|
||||
|
||||
The default installer now supports explicit same-host horizontal scaling:
|
||||
GovOPlaN now supports a stateless application tier backed by logically shared
|
||||
state services. The runtime roles are independently replaceable API, WebUI,
|
||||
worker, and scheduler processes. Every replica in one installation must use the
|
||||
same immutable release composition and the same:
|
||||
|
||||
- one HAProxy container accepts the published HTTP endpoint;
|
||||
- one or more WebUI containers serve assets and proxy API requests;
|
||||
- one or more API containers serve normal domain traffic;
|
||||
- one or more Celery workers consume shared Redis queues;
|
||||
- one migration job runs before replacement;
|
||||
- exactly one Celery scheduler runs;
|
||||
- PostgreSQL, Redis, and file storage are shared by every runtime replica.
|
||||
- `GOVOPLAN_INSTALLATION_ID`;
|
||||
- PostgreSQL database;
|
||||
- Redis broker and coordination service;
|
||||
- `MASTER_KEY_B64` and deployment secret references;
|
||||
- enabled-module graph;
|
||||
- S3-compatible object-storage namespace.
|
||||
|
||||
HAProxy discovers Compose replicas through Docker's internal DNS and performs
|
||||
health-checked round-robin WebUI balancing and least-connection API balancing.
|
||||
It does not mount the Docker socket. Replica counts live in
|
||||
`installation.json`, so `configure`, `plan`, `apply`, and the receipt agree on
|
||||
the desired topology.
|
||||
The application tier must not use node-local durable business data in a
|
||||
multi-host deployment. Files owns managed file metadata while Core provides the
|
||||
storage-backend contract. Campaign build artifacts are stored under opaque
|
||||
object keys and workers read those objects from the shared backend. Temporary
|
||||
build and materialization directories may remain node-local because they are
|
||||
discardable.
|
||||
|
||||
This is not multi-host scheduling. Docker Compose's bridge network belongs to
|
||||
one Docker Engine. Adding a second machine requires an orchestrator or
|
||||
deployment manager that can place equivalent role definitions on multiple
|
||||
hosts.
|
||||
Core validates three explicit state profiles:
|
||||
|
||||
## Recommended Topologies
|
||||
| Profile | Supported shape | Storage rule |
|
||||
| --- | --- | --- |
|
||||
| `local` | One API and one worker process for development | Local filesystem permitted. |
|
||||
| `host-shared` | Multiple processes on one Docker host | A shared host volume is permitted; PostgreSQL and Redis are required. |
|
||||
| `shared` | Multiple independent hosts | PostgreSQL, Redis, and S3-compatible object storage are required. |
|
||||
|
||||
### One Host
|
||||
`shared` also requires a stable installation identifier. Module package
|
||||
mutation is blocked in this profile: build and verify a new immutable release,
|
||||
then roll the complete cluster to it.
|
||||
|
||||
Use the generated Compose bundle:
|
||||
## Same-Host Compose
|
||||
|
||||
The generated Compose bundle provides:
|
||||
|
||||
```text
|
||||
client
|
||||
-> external TLS proxy, when required
|
||||
-> managed HAProxy
|
||||
-> WebUI replica(s)
|
||||
-> managed HAProxy API listener
|
||||
-> API replica(s)
|
||||
client -> TLS proxy -> HAProxy -> WebUI replicas -> HAProxy -> API replicas
|
||||
|
||||
API/worker/scheduler
|
||||
-> PostgreSQL
|
||||
-> Redis
|
||||
-> local volume, managed Garage, or external S3
|
||||
API/worker/scheduler -> PostgreSQL
|
||||
-> Redis
|
||||
-> local volume, managed Garage, or external S3
|
||||
```
|
||||
|
||||
This improves concurrency and permits rolling process replacement, but the host
|
||||
and every managed stateful component remain single failure domains. Two API
|
||||
containers on one failed host do not provide host-level availability.
|
||||
HAProxy discovers Compose replicas through Docker DNS and performs health-aware
|
||||
balancing without mounting the Docker socket. This improves concurrency and
|
||||
permits process replacement, but the Docker host and installer-managed stateful
|
||||
services remain single failure domains. Generated Compose therefore declares
|
||||
the `host-shared` state profile even when its shared storage happens to be an
|
||||
external S3 service. Its API backend checks `/health/ready`, so drain or
|
||||
coordination loss removes a replica from rotation. Container, load-balancer,
|
||||
and Kubernetes probes send the configured public host explicitly, keeping
|
||||
readiness compatible with strict trusted-host validation.
|
||||
|
||||
### Multiple Hosts
|
||||
Managed Garage is a convenient single-node S3-compatible service. It is not a
|
||||
multi-host storage cluster. Use an independently operated Garage cluster or
|
||||
another S3-compatible service for the `shared` profile.
|
||||
|
||||
Use Kubernetes, Nomad, Docker Swarm, or another reviewed orchestrator. Do not
|
||||
extend the Compose installer into a proprietary scheduler. The target topology
|
||||
is:
|
||||
## Kubernetes Export
|
||||
|
||||
```text
|
||||
public TLS ingress/load balancer
|
||||
-> WebUI replicas on at least two nodes
|
||||
-> internal API service/load balancer
|
||||
-> API replicas on at least two nodes
|
||||
The deployment compiler exports a stateless Kubernetes runtime when PostgreSQL,
|
||||
Redis, and S3 are all external:
|
||||
|
||||
queue-specific worker pools on worker nodes
|
||||
one fenced scheduler
|
||||
one fenced migration/deployment job
|
||||
|
||||
shared PostgreSQL
|
||||
shared Redis
|
||||
multi-node Garage or external S3
|
||||
shared secret/config provider
|
||||
central logs, metrics, and health alerts
|
||||
```sh
|
||||
python tools/deployment/govoplan-deploy.py render-kubernetes \
|
||||
--directory /srv/govoplan/default \
|
||||
--namespace govoplan \
|
||||
--secret-name govoplan-runtime \
|
||||
--tls-secret-name govoplan-tls \
|
||||
--ingress-class-name nginx \
|
||||
--output /srv/govoplan/default/kubernetes.json
|
||||
```
|
||||
|
||||
All API and worker nodes must receive the same immutable software composition,
|
||||
`MASTER_KEY_B64`, database URL, Redis URL, enabled-module graph, and object
|
||||
storage binding. Node-local file storage is not valid in this topology.
|
||||
The export contains a Namespace, tokenless ServiceAccount, non-secret
|
||||
ConfigMap, API/WebUI/worker/scheduler Deployments, Services, Pod disruption
|
||||
budgets, Ingress, and a release-specific migration Job. It deliberately emits
|
||||
no Secret values, persistent volume, PostgreSQL, Redis, or object-store
|
||||
deployment. Export is rejected unless both release images use immutable
|
||||
`image@sha256:...` references.
|
||||
|
||||
## Adding Capacity
|
||||
Create the named Secret through the cluster's secret-management path. The
|
||||
command prints the exact required key contract. Review the generated
|
||||
`FORWARDED_ALLOW_IPS` value and replace it with the exact ingress-proxy network
|
||||
before production use.
|
||||
|
||||
### API And WebUI
|
||||
The generated containers run as non-root with a read-only root filesystem and
|
||||
an ephemeral `/tmp`. Runtime Deployments wait for the exact configured database
|
||||
migration heads before starting. The API exposes `/health/ready`, which fails
|
||||
while that API node is draining or cannot prove its runtime-coordination
|
||||
heartbeat.
|
||||
|
||||
Increase API replicas for measured request concurrency, CPU saturation, or
|
||||
latency after checking database load. Increase WebUI replicas for static asset
|
||||
and proxy capacity. No sticky session should be required because durable
|
||||
sessions and throttling use shared services, but this must remain covered by
|
||||
multi-replica integration tests.
|
||||
## Runtime Coordination
|
||||
|
||||
Every added API process also adds database connections. Set the application
|
||||
pool size and the total replica ceiling against PostgreSQL's connection budget;
|
||||
adding replicas can otherwise reduce throughput.
|
||||
Each API and worker incarnation registers in PostgreSQL with its role, software
|
||||
version, module-composition hash, queue set, and heartbeat. Ops shows active,
|
||||
draining, stopped, and stale nodes and compares active counts with configured
|
||||
replica expectations.
|
||||
|
||||
### Workers
|
||||
An operator may request or cancel drain from Ops:
|
||||
|
||||
Workers are not placed behind a load balancer. They compete for jobs on shared
|
||||
Redis queues. Add workers by queue and cap each pool according to the external
|
||||
system it calls. SMTP, IMAP, directory, and connector jobs often reach provider
|
||||
rate limits before CPU limits.
|
||||
- API readiness becomes unavailable on the next heartbeat so the load balancer
|
||||
stops assigning new requests.
|
||||
- A worker stops consuming its configured queues and may finish work already
|
||||
claimed by that process.
|
||||
- A stale process incarnation cannot overwrite a replacement incarnation's
|
||||
heartbeat.
|
||||
- A coordination outage removes API readiness and cancels worker consumers;
|
||||
the existing incarnation must heartbeat successfully before either resumes.
|
||||
|
||||
Use distinct pools when load warrants it:
|
||||
Singleton work uses PostgreSQL-backed leases with monotonically increasing
|
||||
fencing tokens. The generated scheduler runs Celery beat through
|
||||
`govoplan_core.commands.fenced_run`; loss of its lease terminates the child and
|
||||
returns a distinct failure code. A fenced business operation must validate the
|
||||
same lease token immediately before committing its effect.
|
||||
|
||||
- mail send and Sent-folder append;
|
||||
- notifications;
|
||||
- calendar and connector synchronization;
|
||||
- dataflow/workflow execution;
|
||||
- reporting and export;
|
||||
- platform events and default work.
|
||||
## Release Ordering
|
||||
|
||||
Before stopping a worker, mark it draining, stop new claims, and let or safely
|
||||
requeue active jobs. Worker registration and drain control remain part of the
|
||||
larger platform scale-out story.
|
||||
Use this order for every multi-replica rollout:
|
||||
|
||||
### Stateful Services
|
||||
1. Verify immutable image identities, module composition, external state
|
||||
reachability, backup evidence, and the generated plan.
|
||||
2. Drain application replicas when the migration compatibility declaration
|
||||
requires it.
|
||||
3. Run the release-specific migration Job exactly once. PostgreSQL advisory
|
||||
locking serializes all Core and module migration tasks across competing
|
||||
deployment jobs.
|
||||
4. Let runtime init containers run `wait_for_database`. They wait for exact
|
||||
configured Alembic heads and never mutate schema.
|
||||
5. Roll API, workers, scheduler, and WebUI using health-aware replacement.
|
||||
6. Verify runtime composition, expected replica counts, queue consumers,
|
||||
object-storage round trips, and recovery status in Ops.
|
||||
|
||||
- PostgreSQL needs backups, restore drills, connection limits, and an HA/failover
|
||||
design appropriate to the service level.
|
||||
- Redis needs persistence and, for high availability, a supported failover
|
||||
topology. Queue loss is not equivalent to a harmless cache loss.
|
||||
- Managed Garage from the Compose installer is single-node. For redundant
|
||||
storage, deploy a multi-node Garage cluster separately and select external
|
||||
`s3`, or use another compatible object store.
|
||||
- The scheduler stays at one replica until distributed leader election or a
|
||||
fenced lease is implemented.
|
||||
- Migrations and module lifecycle mutations remain one-at-a-time operations.
|
||||
Applying the complete generated manifest is fail-closed: runtime pods remain in
|
||||
their init phase until the migration Job reaches the expected heads. A second
|
||||
release may be submitted concurrently, but advisory locking prevents concurrent
|
||||
schema mutation and each release has a distinct migration Job name.
|
||||
|
||||
## Promotion Path
|
||||
## Storage Trust Boundary
|
||||
|
||||
1. Measure concurrent users, request latency, database query time, connection
|
||||
use, queue age, worker saturation, storage latency, and external throttling.
|
||||
2. Move files to managed Garage or external S3 before introducing independent
|
||||
runtime hosts.
|
||||
3. Keep PostgreSQL and Redis external to stateless runtime nodes, or deploy
|
||||
their reviewed HA operators.
|
||||
4. Publish immutable API/WebUI images and one versioned configuration/secret
|
||||
contract.
|
||||
5. Translate the generated role commands, environment allowlists, health
|
||||
checks, and singleton constraints into the chosen orchestrator.
|
||||
6. Put API and WebUI replicas behind health-aware services and a TLS ingress.
|
||||
7. Add queue-specific workers with fixed upper bounds.
|
||||
8. Prove replica loss, rolling replacement, job redelivery, session continuity,
|
||||
migration exclusion, backup restore, and storage-node loss before claiming
|
||||
high availability.
|
||||
Installer-managed Garage uses its exact generated endpoint. An arbitrary
|
||||
external S3 endpoint is accepted only when the deployment explicitly sets
|
||||
`FILE_STORAGE_S3_ENDPOINT_TRUSTED=true`; that endpoint must be a clean HTTPS
|
||||
origin without embedded credentials, query, fragment, or path. This is an
|
||||
operator trust declaration, not a user-controlled connector bypass. Operators
|
||||
remain responsible for DNS, certificate, network-egress, bucket-policy,
|
||||
versioning, and lifecycle controls.
|
||||
|
||||
## Remaining Platform Work
|
||||
## Capacity
|
||||
|
||||
The one-host installer does not yet provide:
|
||||
- Scale API replicas only within the PostgreSQL connection budget.
|
||||
- Scale workers by queue, with upper bounds based on external provider limits.
|
||||
- Keep one fenced scheduler rather than load-balancing schedulers.
|
||||
- Increase WebUI replicas for asset/proxy capacity.
|
||||
- Measure request latency, database query time and locks, active connections,
|
||||
queue age, retry rate, storage latency, and provider throttling before adding
|
||||
replicas.
|
||||
|
||||
- a Kubernetes, Nomad, or Swarm deployment export/profile;
|
||||
- distributed deployment locks and fenced scheduler leadership;
|
||||
- worker registration, composition-skew reporting, and drain controls;
|
||||
- managed PostgreSQL, Redis, or multi-node Garage high availability;
|
||||
Workers compete for Redis-backed work and are not placed behind a load balancer.
|
||||
SMTP, IMAP, directory, connector, workflow, dataflow, and reporting queues often
|
||||
hit external-system limits before host CPU is exhausted.
|
||||
|
||||
## What This Does Not Claim
|
||||
|
||||
The implemented contract provides stateless runtime placement, shared artifact
|
||||
access, node visibility, drain controls, migration serialization, and scheduler
|
||||
fencing. It does not by itself provide:
|
||||
|
||||
- a highly available PostgreSQL, Redis, or object-store deployment;
|
||||
- automatic PostgreSQL backup, point-in-time recovery, or restore verification;
|
||||
- autoscaling policy;
|
||||
- managed TLS certificate issuance and renewal;
|
||||
- measured multi-replica and failover integration evidence.
|
||||
- central logs, metrics, traces, or alert routing;
|
||||
- managed ingress certificates;
|
||||
- automatic reconciliation of every possible module side effect;
|
||||
- a service-level availability guarantee.
|
||||
|
||||
These are separate production capabilities. The local load balancer and
|
||||
replica model provide the contract they should implement, but they do not by
|
||||
themselves make a cluster highly available.
|
||||
Those are deployment and module-adoption requirements. Before claiming high
|
||||
availability, drill replica loss, rolling replacement, session continuity, job
|
||||
redelivery, scheduler failover, migration exclusion, object-store outage, and a
|
||||
coordinated database/object/key restore. Recovery rules and evidence are
|
||||
defined in [Recovery And Rollback Guarantees](RECOVERY_AND_ROLLBACK_GUARANTEES.md).
|
||||
|
||||
@@ -139,6 +139,17 @@ The canonical backlog item is
|
||||
|
||||
## Implementation slices
|
||||
|
||||
Implementation status as of the current source tree:
|
||||
|
||||
- Slice 6 has a working application-tier foundation: state profiles, shared
|
||||
object storage, runtime node registration/heartbeats/drain, fenced scheduler,
|
||||
migration serialization, exact-head startup waiting, Ops visibility, and a
|
||||
Kubernetes export. Production acceptance still requires topology-specific
|
||||
failover and restore drills.
|
||||
- The recovery foundation for slices 4 and 5 is implemented as a Core recovery
|
||||
ledger and deployment operation journal. Automatic database backup and broad
|
||||
adoption by module-owned external effects remain open work.
|
||||
|
||||
1. **Reproducible Core-only distribution.** Publish pinned multi-architecture
|
||||
images, signed distribution manifest, Core-only Compose profile, bootstrap
|
||||
preflight, generated secrets, readiness, and idempotent rerun/repair.
|
||||
@@ -155,9 +166,11 @@ The canonical backlog item is
|
||||
5. **Safe module update.** Add drain/maintenance coordination, backup gate,
|
||||
migration compatibility window, reconnectable progress, health verification,
|
||||
retry/recovery, and update notification.
|
||||
6. **Stateless replica profile.** Remove remaining local-runtime assumptions,
|
||||
expose role-specific commands/images, implement worker registration/drain,
|
||||
and prove multiple API and worker replicas against shared dependencies.
|
||||
6. **Stateless replica profile.** Continue module adoption and operational
|
||||
proof for the implemented role commands, shared-state validation, runtime
|
||||
registration/drain, fenced scheduler, and Kubernetes application-tier
|
||||
export. Prove multiple API and worker replicas against the target shared
|
||||
dependencies.
|
||||
7. **Configuration revision model.** Define provider export/import schemas,
|
||||
canonical serialization, secret references, validation/diff, immutable
|
||||
revision storage, audit, apply, and undo-as-new-revision.
|
||||
|
||||
@@ -50,7 +50,7 @@
|
||||
"claims": {
|
||||
"type": "array",
|
||||
"minItems": 1,
|
||||
"maxItems": 3,
|
||||
"maxItems": 8,
|
||||
"items": {
|
||||
"$ref": "#/$defs/claim"
|
||||
}
|
||||
@@ -80,6 +80,11 @@
|
||||
"enum": [
|
||||
"target_environment",
|
||||
"external_providers",
|
||||
"accessibility",
|
||||
"privacy",
|
||||
"security",
|
||||
"operations",
|
||||
"recovery",
|
||||
"production_approval"
|
||||
]
|
||||
},
|
||||
|
||||
@@ -51,12 +51,17 @@
|
||||
"allowed_scopes": {
|
||||
"type": "array",
|
||||
"minItems": 1,
|
||||
"maxItems": 3,
|
||||
"maxItems": 8,
|
||||
"uniqueItems": true,
|
||||
"items": {
|
||||
"enum": [
|
||||
"target_environment",
|
||||
"external_providers",
|
||||
"accessibility",
|
||||
"privacy",
|
||||
"security",
|
||||
"operations",
|
||||
"recovery",
|
||||
"production_approval"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -113,6 +113,12 @@
|
||||
"description": "GovOPlaN Appointments module behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/approvals",
|
||||
"color": "d93f0b",
|
||||
"description": "GovOPlaN Approvals module behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/audit",
|
||||
"color": "0e8a16",
|
||||
@@ -143,6 +149,12 @@
|
||||
"description": "GovOPlaN Connectors module behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/committee",
|
||||
"color": "5319e7",
|
||||
"description": "GovOPlaN Committee module behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/core",
|
||||
"color": "0052cc",
|
||||
@@ -185,6 +197,12 @@
|
||||
"description": "GovOPlaN Distribution Lists module behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/decisions",
|
||||
"color": "d93f0b",
|
||||
"description": "GovOPlaN formal Decisions module behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/erp",
|
||||
"color": "fef2c0",
|
||||
@@ -221,6 +239,12 @@
|
||||
"description": "GovOPlaN Forms module behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/forms-runtime",
|
||||
"color": "f9d0c4",
|
||||
"description": "GovOPlaN Forms Runtime module behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/helpdesk",
|
||||
"color": "c2e0c6",
|
||||
@@ -257,6 +281,12 @@
|
||||
"description": "GovOPlaN mail module behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/mandates",
|
||||
"color": "006b75",
|
||||
"description": "GovOPlaN Mandates, jurisdiction, responsibility, and authority behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/notifications",
|
||||
"color": "d876e3",
|
||||
@@ -281,6 +311,12 @@
|
||||
"description": "GovOPlaN Payments module behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/parties",
|
||||
"color": "bfd4f2",
|
||||
"description": "GovOPlaN procedure Parties, representation, and delivery-authority behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/permits",
|
||||
"color": "fbca04",
|
||||
@@ -341,6 +377,12 @@
|
||||
"description": "GovOPlaN Scheduling module behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/services",
|
||||
"color": "1d76db",
|
||||
"description": "GovOPlaN versioned institutional Services behavior or integration.",
|
||||
"exclusive": false
|
||||
},
|
||||
{
|
||||
"name": "module/tasks",
|
||||
"color": "c5def5",
|
||||
|
||||
Reference in New Issue
Block a user