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 08:55:46 +02:00
parent a85b57d9e3
commit 844cf430f6
1 changed files with 478 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Repo-docs-INSTITUTIONAL-GOVERNANCE-TARGET-ARCHITECTURE.-.md
+478
@@ -0,0 +1,478 @@
<!-- codex-wiki-sync:c77a5cc3bd33ec0ad256741f -->
> 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.