diff --git a/Repo-docs-INSTITUTIONAL-GOVERNANCE-TARGET-ARCHITECTURE.-.md b/Repo-docs-INSTITUTIONAL-GOVERNANCE-TARGET-ARCHITECTURE.-.md new file mode 100644 index 0000000..9b88dbc --- /dev/null +++ b/Repo-docs-INSTITUTIONAL-GOVERNANCE-TARGET-ARCHITECTURE.-.md @@ -0,0 +1,478 @@ + + +> Mirrored from `/mnt/DATA/git/govoplan/docs/INSTITUTIONAL_GOVERNANCE_TARGET_ARCHITECTURE.md`. +> Origin: `repository`. +> Active tasks and changing state belong in Gitea issues; this wiki page is durable project context. + +--- +# 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-07-31. 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, and ownership recovery | Implemented foundations span Identity, Organizations, IDM, Access, generic ownership transfer/recovery, and audit provenance. Mandate and jurisdiction context remain missing. | +| 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. + +## Implementation status (2026-08-01) + +The first implementation tranche establishes the cross-module contracts and a +bounded proof without prematurely creating new semantic repositories: + +| 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. | +| 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. | +| 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. + +## 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 | +| --- | --- | --- | +| 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 | +| 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? | 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 | +| 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 | +| 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 | +| 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 + +Four horizontal concepts are not cleanly owned today. They are repository +candidates, not immediate repository mandates. + +#### 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. + +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. + +#### 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. + +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. + +#### 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. + +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. + +#### 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. + +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. + +## 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 should eventually 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. + +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. + +## 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 + +Keep the implemented live/cached/static, staging, immutable materialization, +and publication model. Add 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 existing signed configuration-package mechanism is the implementation +base. It should distinguish: + +- **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 should converge on a +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. + +## Migration sequence + +### 0. Align the portfolio and contracts + +- 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. + +### 1. Prove responsibility and formal outcome + +- 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. + +### 2. Separate service and party semantics + +- 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. + +### 3. Complete governed data and assurance + +- 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. + +### 4. Package repeatable public-sector outcomes + +- 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. + +## Delivery tracking + +The cross-repository epic is +[GovOPlaN #29](https://git.add-ideas.de/GovOPlaN/govoplan/issues/29). +Its new work packages 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; +- [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. + +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. + +## Completion criteria + +The direction is established when: + +- a user can move from service entry through case, party, work, decision, + effect, communication, record, and review without losing institutional + context; +- 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 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 +- documentation and Ops explain the configured composition and its limits to + users, administrators, operators, and auditors.