7.6 KiB
GovOPlaN Documentation
This directory contains cross-repository product, architecture, delivery, and project documentation. Start here instead of browsing every file.
Read First
| Need | Source |
|---|---|
| Understand the platform in ten minutes | Platform Core Ideas |
| See the intended product sequence | Roadmap |
| Check the reconciled state and material gaps | Strategy Status |
| Find active work, priority, or ownership | Gitea issue workflow and Gitea issues |
| Understand the selected end-to-end proofs | Reference Journey Program |
The first three documents are the normal entry points. Detailed architecture, runbooks, evidence, and historical assessments support them; they are not parallel roadmaps.
Strategy
| Document | Role |
|---|---|
| Platform Core Ideas | Stable purpose, principles, planes, distinctions, and non-goals |
| Roadmap | Concise product outcomes, horizons, and current sequence |
| Strategy Status | Only prose source for current cross-product status |
| Reference Journey Program | Acceptance journeys and their gates |
| Product Input Register | Normalized ideas and user-story source material |
| System Administrator Lifecycle | Installation and lifecycle outcome story |
| Detailed Connected-Platform Vision | Long-form stakeholder, configuration, and outcome catalogue |
Architecture
| Topic | Canonical source |
|---|---|
| Institutional model and ownership | Institutional Governance Target Architecture |
| Product experience and technical boundaries | Product Experience and Module Boundaries |
| Shared interface and layout rules | Interface Pattern Language |
| Focused task views | Views Architecture |
| Product areas and task-local tools | Quick Access and Product Areas |
| Platform self-description and configuration | Platform Control Plane |
| Data sources, definitions, and graph execution | Datasource and Definition Graph Architecture |
| Federation between autonomous installations | Federated GovOPlaN Architecture |
| Institutional digital twin | Institutional Digital Twin |
| Assisted and non-digital participation | Assisted and Non-Digital Channels |
Module-specific architecture remains in the owning repository. In particular,
information-governance adoption is in
govoplan-core/docs/INFORMATION_GOVERNANCE_ADOPTION.md, and the eAkte model is
in govoplan-records/docs/EAKTE_ARCHITECTURE.md.
Operations
| Need | Source |
|---|---|
| Installation model and managed components | Installation and Deployment Architecture |
| Supported operating modes | Deployment Profiles |
| Horizontal scaling and multi-host topology | Scaling and Multi-Host Deployment |
| Local Kubernetes evidence target | Kubernetes VM Test Lab |
| Recovery guarantees and state machine | Recovery and Rollback Guarantees |
| Recovery-ledger rollout | Recovery Ledger Adoption |
| Backup evidence contract | Backup and Restore Evidence |
| Target handoff and independent evidence | Production Target Handoff |
| Evidence collection and promotion | Target Maturity Evidence Runbook |
| Package publication and consumption | Package Registry Releases |
| Release-console operation | Release Console |
| Module compatibility and install behavior | Module Contracts and Installs |
| Security-audit toolchain | Security Audit |
Project Reference
- Repository Index is the human-readable module
and repository directory;
../repositories.jsonis authoritative for tools. - Repository Structure defines ownership of meta, module, deployment, and website content.
- Gitea Issues defines labels, templates, import, and state-update conventions.
Evidence And Archive
Pinned evidence is retained under evidence/; completed reviews and migration
inventories are under archive/. They explain or prove a dated state and must
not be read as current product status.
- Generated Campaign capability and infrastructure fit, 2026-07-22
- Supporting narrative for the 2026-07-22 assessment
- Interface surface inventory, 2026-08-03
- Strategic review, 2026-08-05
- Meta repository scan, 2026-07-13
- Meta repository migration audit
The JSON files at the root of this directory are machine-readable schemas, evidence inputs, and project configuration. Their paths are intentionally stable because tools and published schema identifiers consume them; they are not additional reading-list entries.
Regenerate and verify the human fit report from its JSON input with:
./.venv/bin/python tools/assessments/generate-capability-fit-report.py
./.venv/bin/python tools/assessments/generate-capability-fit-report.py --check
Maintenance Rules
- Gitea issues are the only live source for work state, priority, and owner.
strategy/STRATEGY_STATUS.mdis the only prose reconciliation of current portfolio state. Do not copy its volatile counts into durable documents.- Durable documents state decisions, invariants, ownership, and acceptance gates. They link to Gitea for implementation detail.
- Dated evidence and archive documents retain their original composition and conclusion. Add a snapshot notice instead of silently modernizing them.
- Module-specific behavior and user/admin documentation stay in the owning repository. Meta documentation covers cross-module outcomes and contracts.
- Do not add another top-level Markdown file. Place new content in the appropriate directory and add it to this map only when it has a distinct canonical purpose.
- A new strategy document must replace, narrow, or become a reference for an existing source; it must not introduce a parallel roadmap.
- The Product Input Register preserves source ideas. Only a named journey, package, or Gitea issue turns an idea into implementation work.
After moving or adding documentation, run:
./.venv/bin/python -m unittest tests.test_documentation_structure