Release v0.1.16

docs/REFERENCE_JOURNEY_PROGRAM.md

@@ -18,6 +18,27 @@ delivered as small, reviewable, green increments and is complete only when its
 user journey, failure behavior, documentation, and operator evidence work in a
 pinned composition.
 
+## 2026 outcome reset
+
+Repository completion is not product completion. From 2026-08-05 onward, work
+is accepted primarily through three maintained real-life journeys:
+
+1. **Governed communication:** select accountable recipients, prepare content
+   and attachments, approve, deliver through Mail and/or a function-bound
+   Postbox, reconcile uncertain outcomes, and file the evidence.
+2. **Inclusive service-to-decision:** accept a request through a digital or
+   assisted channel, establish identity and purpose, guide the case through
+   human and automatic work, decide, notify, and file the resulting eAkte.
+3. **Monthly data and sanctions:** acquire immutable source snapshots, validate
+   and reconcile them interactively, preserve decisions and lineage, produce
+   reports and files, and deliver the accepted result through Campaign.
+
+The staged program below remains the architectural build order. These journeys
+are the acceptance lens across those stages. Every significant feature should
+identify the journey it improves, or provide security, operability, recovery,
+accessibility, or usability evidence that those journeys require. Work that
+does neither stays in the backlog until a concrete consumer exists.
+
 ## Why this sequence
 
 The sequence grows one connected product rather than advancing repositories in
@@ -86,6 +107,12 @@ journey needs and supplies contracts shared by all five stages.
    execution. Database, broker, cache, and worker channels are constrained by
    deployment network policy and authenticated transport rather than treated as
    tenant connector profiles.
+10. **Information governance.** Temporal browsing, purpose-aware access,
+    retention/legal-hold behavior, and institutional acting context are applied
+    to every owned object type. Historical reads use current authorization.
+    Module manifests state `contract_only`, `partial`, `enforced`, or
+    `not_applicable` adoption with evidence; supported maturity is blocked until
+    every applicable dimension is enforced.
 
 ## Documentation contract for every reference stage
 
@@ -108,6 +135,9 @@ Every demonstrated journey provides:
   provenance, evidence, retention, and destructive actions.
 - **Acceptance view:** runnable examples, expected results, failure injection,
   and release gates.
+- **Channel and records view:** assisted/non-digital intake and output,
+  representation, provenance, filing, retention, legal hold, and archive
+  consequences where the journey creates evidence or a record.
 
 The Docs module selects and links these views according to installed
 capabilities and actor context. Feature repositories remain the source of
@@ -436,6 +466,9 @@ or the external editor the document-lifecycle owner.
   link, callback, webhook, file, identity, or data row.
 - Do not claim a stage complete from local unit tests. Use pinned composition,
   target integration, failure drills, adaptive docs, and operator evidence.
+- Do not claim a module complete while its relevant information-governance
+  dimensions remain `contract_only` or while the reference journey lacks an
+  assisted-channel and records outcome where those are applicable.
 - A later stage may prototype contracts while the preceding gate is being
   proven, but it may not redefine an owning module's boundary by convenience.