GovOPlaN/govoplan
2
0
Fork 0
Code Issues 18 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

Sync Repo-docs-INSTITUTIONAL-GOVERNANCE-TARGET-ARCHITECTURE from project files

zemion
2026-08-01 10:30:36 +02:00
parent 844cf430f6
commit 1eb36f9028
1 changed files with 141 additions and 111 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Repo-docs-INSTITUTIONAL-GOVERNANCE-TARGET-ARCHITECTURE.-.md
+141 -111
@@ -1,4 +1,4 @@
<!-- codex-wiki-sync:c77a5cc3bd33ec0ad256741f -->
<!-- codex-wiki-sync:b69ec174cdf58e1ed7d06d7f -->
> Mirrored from `/mnt/DATA/git/govoplan/docs/INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md`.
> Origin: `repository`.
@@ -65,50 +65,56 @@ accepted as the current baseline and must not be reopened as greenfield work.
| 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, and ownership recovery | Implemented foundations span Identity, Organizations, IDM, Access, generic ownership transfer/recovery, and audit provenance. Mandate and jurisdiction context remain missing. |
| 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 important remaining work is primarily **institutional semantics, consistent
provider declarations, and product packaging**, not another runtime rewrite.
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 first implementation tranche establishes the cross-module contracts and a
bounded proof without prematurely creating new semantic repositories:
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. | Adoption is staged. The workspace check reports coverage and can enforce complete adoption with `--require-architecture` after every module has truthful 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. Connectors proves read-only external mirrors; Calendar proves writable governed synchronization and supplies tenant-aware CalDAV binding state. | Remaining providers must declare the contract and sanitized runtime state when their behavior and evidence can be stated accurately. |
| 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 60 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 now cover Mandate resolution, versioned Service definitions, procedure Parties/representation, and formal Decisions. Mandate resolution is deterministic across effective time, unit, function, jurisdiction, task, authority, subject, and conflicts; immutable Mandate and Decision lifecycle helpers enforce OCC and allowed transitions. | Persistent provider lifecycles remain subject to issues #30-#33 and their repository thresholds. |
| Formal-outcome proof | Committee has a capability-based decision path that resolves effective mandate authority, jurisdiction, approval, legal basis, evidence, reasoning, responsible human/service actor, automation assurance, and operative result into a reconstructable formal Decision without importing optional module tables. Decision corrections, revocations, supersession, and stale updates now have a shared immutable revision rule. | A second consuming domain and persistent provider are still required before extracting a Decisions module. |
| Service-to-case proof | Portal projects optional provider-owned Service definitions into available, explainably unavailable, or undiscoverable entries. Cases consumes the same exact Service version into a governed intake plan retaining case/form/workflow/result, responsibility, Mandate, jurisdiction, legal basis, evidence, and deadline references. A meta composition test proves both consumers without cross-module table access. Restrictive derivation preserves parent provenance and prevents tenant/package specializations from widening effective time, audience, channels, publication, prerequisites, evidence, legal bases, or bindings. | A persistent definition provider remains threshold-based; Portal is still a headless projection without a service-directory WebUI. |
| Procedure-party proof | Cases resolves effective procedure parties from the optional `parties.resolver` capability and falls back to a bounded local projection containing no representation lifecycle. Downstream delivery receives only permitted channels and immutable contact-snapshot/evidence references; expired or revoked representation authority is excluded. | Provider-side access/correction depth and a second procedure consumer remain before a Parties repository crosses its threshold. |
| Integrated institutional journey | An executable meta fixture carries one exact Service version through Portal discovery, Case intake, procedure-party representation and frozen delivery authority, effective Mandate resolution, approval, formal Committee Decision, confirmed Postbox effect, Audit record, remedy/review, and protected evidence reconstruction. | The fixture is a contract proof, not a claim that all corresponding persistence and WebUI surfaces are reference-ready. |
| 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 resolves effective Mandate authority and records a reconstructable formal Decision through `decisions.registry` when installed, while retaining an optional local projection when it is absent. Decision corrections, revocations, supersession, protected reads, and stale updates use the shared immutable revision rules. | Committee meeting/agendum/vote persistence remains Committee product depth, not a missing Decisions architecture primitive. |
| Service-to-case proof | Services owns the persistent exact definitions consumed by Portal discovery and Cases intake. Publication and availability remain separate, restrictive derivation cannot widen parent constraints, and the provider hides draft/retired definitions from general discovery. | Portal and Cases remain headless vertical slices; their later WebUI/persistence depth does not alter Service ownership. |
| 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, Parties, Mandates, and Decisions providers. It carries one exact Service version through Portal discovery, Case intake, representation and frozen delivery authority, effective Mandate resolution, approval context, a persisted formal Committee Decision, confirmed Postbox effect, Audit/record evidence, remedy/review, and protected reconstruction. | This is architecture and composition evidence. Target accessibility, privacy, 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. | Rich dependency/impact traversal and policy-specific field visibility can grow on the catalogue contract without moving connector or transformation ownership. |
| 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 tranche deliberately does not create shared institutional tables in Core,
claim unsupported maturity, or turn candidate module issues into empty
repositories. Gitea remains authoritative for the incomplete lifecycles.
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 and candidate owners |
| 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; candidate Mandates |
| 2. Governance and accountability | Policy, audit, risk, control, explainability, configured projection | Policy, Audit, Risk Compliance, Docs, Views, Search; candidate Decisions |
| 3. Human work and procedure | Intake, cases, tasks, approvals, process execution and editing | Forms, Forms Runtime, Cases, Tasks, Approvals, Workflow Engine, Workflow, Tickets; candidates Services and Parties |
| 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 |
@@ -128,20 +134,22 @@ combines them.
| 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? | Candidate Mandates capability |
| Service | What governed promise can an institution offer, to whom, under which prerequisites, evidence, channel, deadline, and responsibility? | Candidate Services capability; Portal presents it |
| 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? | Candidate Parties capability; Identity/Organizations remain the subject owners |
| 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? | Candidate Decisions capability |
| 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 |
### Candidate semantic modules
### Extracted semantic modules
Four horizontal concepts are not cleanly owned today. They are repository
candidates, not immediate repository mandates.
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
@@ -150,11 +158,11 @@ 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.
The first proof should answer: *Was this function competent to act for this
case at the relevant time, and on what basis?* Start with a Core-neutral DTO and
provider contract used by one Case/Decision journey. Create
`govoplan-mandates` when the model has independent persistence, lifecycle,
security, and more than one consumer.
`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
@@ -164,10 +172,10 @@ jurisdiction, forms, case/workflow/result bindings, remedies, service levels,
and publication status. Portal presents and starts services but should not own
their institutional definition.
The existing Portal service-directory concept remains the first presentation
surface. Extract `govoplan-services` when service definitions are consumed by
Portal plus at least one of Cases, Forms, Workflow, Reporting, or external
publication independently of Portal.
`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
@@ -178,10 +186,10 @@ 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.
Cases currently sketches local party rows. That is a compatibility seed, not a
reason to copy representation semantics into every domain. Define a shared
reference contract first and extract `govoplan-parties` when a second procedure
needs the same effective-dated representation lifecycle.
`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
@@ -192,10 +200,10 @@ and links to observed effects. Approvals own review gates; Poll owns response
collection; Committee owns deliberation, meetings, and votes; Workflow owns
coordination.
Committee and Cases may retain temporary decision references, but the first
regulated journey should use one shared Decision DTO and evidence contract.
Create `govoplan-decisions` when the lifecycle is persisted and reused outside
one domain.
`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
@@ -227,7 +235,7 @@ tenant deliberately configures it as `external_mirror`.
### Provider declaration
Every provider that reads or causes external effects should eventually declare:
Every provider that reads or causes external effects must declare:
- owned object and field groups;
- supported source-authority modes and integration maturity;
@@ -238,11 +246,11 @@ Every provider that reads or causes external effects should eventually declare:
- degraded and outage behavior;
- classification, purpose, retention, and secret-handling requirements.
Current external-reference, action/effect, connector lifecycle, capability,
operational-check, and documentation contracts provide most of the primitives.
The required change is a common declaration that composes them and can be
validated by Core, release tooling, Ops, Docs, and configuration-package
preflight.
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
@@ -278,8 +286,8 @@ families.
### Datasources becomes the governed data and register catalogue
Keep the implemented live/cached/static, staging, immutable materialization,
and publication model. Add typed governance metadata for owner/steward,
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,
@@ -340,8 +348,7 @@ 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 existing signed configuration-package mechanism is the implementation
base. It should distinguish:
The signed configuration-package mechanism distinguishes:
- **reference package:** tested composition proving a journey and its recovery
behavior;
@@ -360,7 +367,7 @@ 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 should converge on a
catalog, Docs projection, and meta repository inventory use one
machine-readable declaration with at least:
- architecture layer and module kind;
@@ -382,70 +389,84 @@ 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.
## Migration sequence
## Implemented migration sequence
### 0. Align the portfolio and contracts
### 0. Align the portfolio and contracts - complete
- Publish this reconciliation and correct stale roadmap/module statements.
- Add machine-readable portfolio/source-authority metadata with validation and
evidence-based maturity claims.
- Compose the existing external-reference, action/effect, operational-health,
ownership, policy, audit, and documentation primitives into one provider
declaration.
- Add common institutional-context, legal-basis, evidence, and geo reference
DTOs only where current contracts do not already cover them.
- This reconciliation is canonical in the meta repository and mirrored to the
Gitea wiki.
- All 60 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
### 1. Prove responsibility and formal outcome - complete
- Define Mandate and Decision contracts.
- Use them in one bounded Case or Committee path with effective-time authority,
approval, reasoning, evidence, observed effect, correction, and review.
- Create separate repositories only when persistence and reuse pass the
repository threshold.
- 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, 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
### 2. Separate service and party semantics - complete
- Keep Portal as the service presentation surface while extracting a reusable,
versioned service-definition contract.
- Replace duplicated case/procedure participant fields with a common Party
reference and representation contract.
- Prove both through one general administrative service package.
- 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.
### 3. Complete governed data and assurance
### 3. Complete governed data and assurance - architecture complete
- Extend the Datasources catalogue with typed governance and dependency links.
- Complete Reporting semantic models and institutional indicator provenance.
- Generalize the Risk Compliance assurance graph after the sanctions vertical
is accepted.
- Extend Projects from execution tracking into portfolio/outcome governance as
a consuming domain, not as a second policy or reporting engine.
- Datasources carries typed governance through staging and immutable
materializations, with bounded catalogue filters and dependency references.
- Reporting owns semantic presentation/provenance contracts without taking
source or transformation ownership; feature depth remains on its module
backlog.
- Risk Compliance persists the horizontal obligation/risk/control/evidence/
finding/measure graph and projects sanctions runs idempotently.
- Projects declares portfolio/outcome ownership as a consuming domain without
becoming a second policy or reporting engine.
### 4. Package repeatable public-sector outcomes
### 4. Package repeatable public-sector outcomes - complete at product maturity
- Finish the active Campaign/Postbox/data/BI/document reference program.
- Package governance foundation, governed communication, function-bound
collaboration, service-to-decision, procurement/contracts, and governed BI.
- Add sector packages only after a reference package has target-environment,
recovery, accessibility, privacy, and operator evidence.
- 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.
## Delivery tracking
The cross-repository epic is
The completed cross-repository architecture epic is
[GovOPlaN #29](https://git.add-ideas.de/GovOPlaN/govoplan/issues/29).
Its new work packages are:
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):
Mandates semantics;
- [GovOPlaN #31](https://git.add-ideas.de/GovOPlaN/govoplan/issues/31):
Services semantics;
- [GovOPlaN #32](https://git.add-ideas.de/GovOPlaN/govoplan/issues/32):
Parties and representation semantics;
- [GovOPlaN #33](https://git.add-ideas.de/GovOPlaN/govoplan/issues/33):
formal Decisions semantics;
- [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):
@@ -456,23 +477,32 @@ Its new work packages are:
configured architecture, maturity, and source-authority explanations.
Existing Projects #1, Reporting #4, Portal #1, Cases #1, Datasources #1,
Risk Compliance #2, GovOPlaN #14, and GovOPlaN #19 carry reconciliation notes
instead of duplicate issues.
Risk Compliance #2, GovOPlaN #14, and GovOPlaN #19 carry product-depth and
reference-readiness work instead of duplicating the completed architecture
contract.
## Completion criteria
## Completion evidence
The direction is established when:
The architecture direction is established by the following executable and
machine-enforced evidence:
- a user can move from service entry through case, party, work, decision,
effect, communication, record, and review without losing institutional
context;
- the `product.service-to-decision` composition and SQL-backed golden fixture
retain institutional context from service entry through case, party,
authority/work context, decision, observed communication effect, record, and
review references;
- the system can answer who acted, for whom, in which function, under which
mandate and jurisdiction, using which rule and evidence versions;
- every external binding states authority mode, maturity, health, freshness,
conflict, and recovery behavior;
- 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 and sector packages are portable without cross-module table access or
code forks; and
- 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`.