1

Repo docs INFORMATION GOVERNANCE ADOPTION

Albrecht Degering edited this page 2026-08-05 16:49:06 +02:00

Table of Contents

• Information Governance Adoption
• Platform Rule
• Manifest Declaration
• Read Contract
• Purpose-Aware Access Contract
• Retention Contract
• Institutional Context Contract
• Adoption Order
• Definition Of Enforced

Mirrored from /mnt/DATA/git/govoplan-core/docs/INFORMATION_GOVERNANCE_ADOPTION.md. Origin: repository. Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.

---

Information Governance Adoption

Platform Rule

Temporal browsing, purpose-aware access, retention, and institutional context are platform-wide information-governance dimensions. Every module receives the same contract by default. A module may claim partial or enforced only with repository-owned object scope, evidence, and limitations; it may claim not_applicable only when the dimension genuinely does not apply.

Historical business data is always authorized under the current security state. No module may use a historical permission, membership, role, function assignment, or policy projection to weaken present-day access.

Platform-wide adoption is tracked in GovOPlaN #40, with temporal reads detailed in GovOPlaN #39.

Manifest Declaration

ModuleManifest.information_governance publishes four dimensions:

• temporal_browsing;
• purpose_aware_access;
• retention;
• institutional_context.

Each dimension declares:

• adoption: not_applicable, contract_only, partial, or enforced;
• object types covered;
• repository-local test/documentation evidence;
• the remaining limitation for contract_only or partial.

The default is intentionally contract_only. It applies the platform rule without pretending that existing domain queries and effects already enforce it. reference_ready, supported, and lts modules cannot retain an applicable dimension below enforced.

Read Contract

For every persistent domain object, the owner classifies the read:

1. Current-only: historical semantics do not exist and the API says so.
2. Valid-time: select facts effective now or at the requested instant.
3. Bitemporal: additionally select only revisions known by recorded_at.
4. All-validity: return effective revisions in a bounded history view.

The Core temporal middleware supplies the request context. Owners apply it in repositories or query helpers, include it in cache keys, return evaluated context, and test current/at/all plus recorded-time boundaries. Search, reporting, exports, selectors, counts, and drill-through must use the same projection as the owning list/detail API.

Purpose-Aware Access Contract

Permission establishes a technical action ceiling. Purpose-aware access asks whether this actor, represented capacity, case/work item, legal basis, and declared use may access this object now.

• A client-supplied purpose is an assertion, never authority by itself.
• The owner or Policy capability validates the purpose and returns explainable provenance.
• Sensitive access can require case assignment, mandate, reason capture, approval, or break-glass evidence.
• Search, selectors, reporting, exports, background jobs, and connectors apply the same decision.
• Audit records the validated purpose identifier and decision reference, not unnecessary content.

Retention Contract

Every persistent object declares an owner, retention class or policy reference, trigger, start instant, hold behavior, review/disposition action, and evidence. Retention is not a generic timestamp deletion job.

• Domain owners enumerate and execute their own effects through a typed retention provider.
• Policy resolves inherited ceilings and simulation.
• Records owns record disposition; Files owns byte/object effects; Audit owns audit-detail behavior; external providers declare their own effect and recovery semantics.
• Dry-run, legal hold, exact revision, idempotency, outcome unknown, reconciliation, correction, and destruction evidence are mandatory for consequential removal.

Institutional Context Contract

Consequential objects and effects carry the relevant tenant, institution, organization unit, function, mandate/jurisdiction, service/case/work item, party/representation, decision, and record references. Context is minimized to what the operation needs. Organizational membership is not itself permission or mandate.

Events, automation intents, audit evidence, records, and external effects retain the same governed context envelope or an exact reference to it. Consumers must not reconstruct authority later from mutable current structures.

Adoption Order

1. Inventory every domain list/detail/search/export/effect and classify all four dimensions.
2. Migrate institutional owners first: Access, IDM, Organizations, Mandates, Services, Parties, Cases, Approvals, Committee, Decisions, Voting, and Records.
3. Migrate communication and content: Addresses, Distribution Lists, Campaign, Postbox, Mail, Calendar, Files, Templates, and Forms Runtime.
4. Migrate data projections: Connectors, Datasources, Dataflow, Reporting, Search, Risk Compliance, and Dashboard.
5. Migrate workflow/task/background/provider operations and prove that no asynchronous path drops context.
6. Advance manifest claims only after owner tests and browser/reference-journey evidence pass.

The generated platform inventory reports adoption counts and module details. Gitea tracks individual migrations; the declaration is evidence and a maturity gate, not a substitute for implementation.

Definition Of Enforced

A dimension is enforced only when:

• all declared object types and public reads/effects use it;
• list/detail/count/search/export/worker behavior is consistent;
• cache and pagination semantics cannot cross contexts;
• absence, invalid values, and inaccessible referenced context fail safely;
• tests cover current, historical, unauthorized, replay, and module-absence combinations appropriate to the dimension;
• user/admin documentation explains behavior and limitations;
• the manifest cites those tests and docs.