From 5d87768c10ed12af54dc86708480e03c70aaad7b Mon Sep 17 00:00:00 2001 From: Albrecht Degering Date: Sat, 1 Aug 2026 12:39:46 +0200 Subject: [PATCH] Sync wiki from project files --- ...TUTIONAL-GOVERNANCE-TARGET-ARCHITECTURE.md | 260 +++++++++++------- 1 file changed, 160 insertions(+), 100 deletions(-) diff --git a/Repo-docs-INSTITUTIONAL-GOVERNANCE-TARGET-ARCHITECTURE.md b/Repo-docs-INSTITUTIONAL-GOVERNANCE-TARGET-ARCHITECTURE.md index 6fa7f1c..09f22a0 100644 --- a/Repo-docs-INSTITUTIONAL-GOVERNANCE-TARGET-ARCHITECTURE.md +++ b/Repo-docs-INSTITUTIONAL-GOVERNANCE-TARGET-ARCHITECTURE.md @@ -1,4 +1,4 @@ - + > Mirrored from `/mnt/DATA/git/govoplan/docs/INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md`. > Origin: `repository`. @@ -65,27 +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 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 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 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, and closure guards cover the aggregate. | Committee remains API-first and does not yet provide its later deliberation WebUI or specialized secret/external ballot adapters. | +| Service-to-case proof | Services owns the persistent exact definitions consumed by Portal discovery and Cases intake. Portal exposes a tenant-scoped API and compact service-directory WebUI whose audiences are derived from trusted principal/function state. Cases persists catalogs, immutable revisions, parties, assignments, evidence/decision/record references, deadlines, lifecycle events, exact Service versions, OCC, replay safety, tenant isolation, API permissions, ACL filtering, uninstall guards, tenant summary state, and list/detail/history/timeline WebUI. | Specialized form/case/workflow launchers and procedure panels remain with their owners. Cases still needs finer case-sharing policy. Neither gap changes 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, 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. | 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. | 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 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 | @@ -105,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 @@ -127,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 @@ -141,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 @@ -155,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 @@ -169,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 @@ -204,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; @@ -215,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 @@ -255,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, @@ -288,7 +319,9 @@ model is: Obligation -> governed object -> risk -> control -> evidence -> finding -> measure -> effectiveness review ``` -Risk Compliance should own that assurance graph and review lifecycle. Policy +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. @@ -315,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; @@ -335,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; @@ -357,70 +389,85 @@ 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, 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 +### 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): @@ -431,23 +478,36 @@ 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 a persisted case, + party, authority/work context, committee deliberation, decision, observed + communication effect, minute/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`. +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.