docs: select connected reference journey program

docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md

@@ -16,6 +16,7 @@ cross-product vision that sequence serves.
 
 Read it together with:
 
+- the [selected reference-journey program](REFERENCE_JOURNEY_PROGRAM.md)
 - the [current capability and infrastructure fit assessment](CAPABILITY_AND_INFRASTRUCTURE_FIT.md)
 - the [interface pattern language](INTERFACE_PATTERN_LANGUAGE.md)
 - the [interface surface inventory](INTERFACE_SURFACE_INVENTORY.md)
@@ -93,6 +94,7 @@ composed.
 | Horizon | Product outcome |
 | --- | --- |
 | Current baseline | One credible Campaign-centric pilot cluster and one emerging scheduling/calendar/poll cluster on a substantial modular/governance foundation |
+| Selected reference program | Campaign demonstration -> function-bound Postbox -> data-backed templates/reports -> governed BI -> collaborative documents |
 | 1. Trustworthy baseline | A pinned, installable, recoverable, target-tested release with a coherent interface and explainable composition |
 | 2. Human-work spine | Intake becomes owned, reviewable work with shared context, evidence, communication, and explicit external effects |
 | 3. Service packages | Complete public service, internal operations, learning, meeting, and communications outcomes can be imported and adapted |
@@ -105,6 +107,14 @@ The central progression is:
 safe modules -> connected work -> reusable services -> institutional assurance -> ecosystem
 ```
 
+The active implementation path is the
+[Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md), selected on
+2026-07-21. Its five stages do not replace these product horizons: they are the
+ordered demonstrations through which the shared platform contracts and horizon
+gates are to be proved. Connector safety, identity/function semantics,
+provenance, external-effect handling, adaptive documentation, focused UI, and
+release evidence form one continuous foundation lane across all five stages.
+
 Each horizon retains the same design promise: configuration packages describe
 the procedure that exists here; focused views describe what this actor needs
 now; policy constrains what may happen; evidence explains what actually
@@ -336,16 +346,21 @@ outcome.
 
 **Composition.** Campaign, files, mail, addresses/distribution lists, policy,
 access, audit, docs, notifications, and ops; calendar or scheduling is optional.
+Mail owns profiles, credentials, protocol policy, and provider execution.
+Campaign stores only the selected Mail profile reference plus its own delivery
+intent and evidence; SMTP/IMAP material is never part of Campaign JSON.
 
 **Configuration choices.** Local lists versus CardDAV or another directory;
 local files versus managed external providers; synchronous versus queued
 delivery; single author versus reviewed send; visible recipient detail versus
 minimized operational views; SMTP/IMAP or another future provider.
 
-**Roadmap role.** This is the strongest current product slice and the proving
-ground for shared UI patterns, durable external effects, audit evidence, and
-operator recovery. It should become the first pinned, target-tested reference
-configuration rather than expanding indefinitely into a marketing suite.
+**Roadmap role.** This is the strongest current product slice and Stage 1 of the
+selected reference-journey program. It is the proving ground for shared UI
+patterns, adaptive multi-perspective documentation, durable external effects,
+module-owned profiles and data, audit evidence, and operator recovery. It should
+become the first pinned, target-tested reference configuration rather than
+expanding indefinitely into a marketing suite.
 
 ### 2. Scheduling, meeting, and institutional decision office
 
@@ -847,6 +862,64 @@ can be tested.
 8. Minutes, responses, decision, publication, corrections, and records remain
    connected for participants and oversight under their respective access.
 
+### Story I: from sender to current institutional responsibility
+
+1. A sender selects a governed delivery target: a Postbox or a function in an
+   organizational unit, not the name or email address of its current holder.
+2. Organizations, Identity, IDM, and Access resolve the target and current
+   acting context through their owned contracts.
+3. Postbox accepts one durable message and attachment references and returns a
+   delivery receipt; Campaign or another sender retains only typed references.
+4. An authorized function holder or delegate discovers and handles the message.
+5. Vacancy, ambiguity, expiry, or unavailable dependencies create visible safe
+   states rather than an implicit personal fallback.
+6. Reassignment changes future access without moving or rewriting the message;
+   delivery, access, and correction evidence remains connected.
+
+### Story J: from specialist-system context to reproducible document
+
+1. An authenticated user follows an opaque, short-lived launch reference from
+   HIS or another source system to a GovOPlaN report/document task.
+2. GovOPlaN re-authorizes the actor and resolves a curated, versioned source
+   context server-side; URLs contain neither credentials nor trusted raw data.
+3. The user sees source, freshness, parameters, template/report version, and
+   blockers before generation.
+4. Templates renders or Reporting executes from a validated input snapshot;
+   Files stores the immutable output and checksum.
+5. The result is linked or returned through an explicit idempotent contract.
+6. Provenance explains exactly which source, data version, transformation,
+   definition, actor, and policy produced the artifact.
+
+### Story K: from operational sources to trusted institutional indicator
+
+1. A governed catalog declares source owner, purpose, classification, schema,
+   extraction mode, reporting-date semantics, freshness, and credentials.
+2. An ingestion run stages a snapshot or watermark and records schema drift,
+   validation findings, quarantine, and replay evidence.
+3. Versioned transformations map official keys, organizational hierarchies,
+   time dimensions, and measures into a documented analytical data product.
+4. Reporting serves policy-aware aggregates and permitted drill-down with the
+   calculation and lineage visible.
+5. Scheduled outputs, APIs, templates, or open-data handoffs use the same
+   product version rather than reimplementing the calculation.
+6. Package promotion reproduces the accepted report in development, test, and
+   production; corrections create new evidence rather than rewriting history.
+
+### Story L: from generated artifact to approved collaborative record
+
+1. An uploaded file or generated template/report becomes a DMS document with a
+   stable identity and first version.
+2. Authorized actors receive an editing session or controlled check-out under
+   current permission and document policy.
+3. Concurrent or stale saves cannot silently overwrite accepted work; comments,
+   comparison, locks, and recovery make conflicts understandable.
+4. Review and approval freeze an immutable rendition with actor, version,
+   content checksum, and decision evidence.
+5. Postbox, Campaign, Cases, or another module links the document through a
+   typed reference rather than copying its lifecycle.
+6. Records classifies and retains the accepted rendition while Files remains
+   the storage owner and an external editor remains only a connector.
+
 ## Roadmap horizons
 
 Horizons are ordered by dependency and product confidence, not calendar dates.
@@ -854,6 +927,15 @@ Work may proceed in parallel when it does not bypass a gate. A horizon is
 complete when its user and operator outcome is demonstrated in a pinned
 composition, not when all named repositories contain scaffolding.
 
+Reference-program stage numbers are delivery order, not alternative maturity
+horizons. Campaign primarily proves Horizon 1; function-bound Postbox and the
+manual responsibility spine prove Horizon 2; templates/report launches and the
+first analytical product prove Horizons 2 and 3; governed BI adds assurance and
+ecosystem capabilities across Horizons 3–5; collaborative documents combine
+the evidence spine, service packages, and records assurance across Horizons
+2–4. The detailed mapping and gates are in the
+[Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md).
+
 ### Current baseline: modular pilot foundations
 
 The current product has credible foundations in module discovery and
@@ -886,14 +968,17 @@ Priorities:
 3. Complete database, files, configuration, secrets, and audit backup/restore
    drills with measured recovery objectives.
 4. Prove the providers required by the selected reference configurations,
-   beginning with SMTP/IMAP, CalDAV, and the relevant broker/worker and file or
-   directory adapters, including reconciliation behavior.
+   beginning with Campaign's Mail-owned SMTP/IMAP profile, CalDAV, and the
+   relevant broker/worker and file or directory adapters, including fail-closed
+   destination pinning and reconciliation behavior.
 5. Add external monitoring, alerting, audit export/retention, deployment
    hardening, and incident/runbook evidence.
 6. Apply the interface pattern language first to Campaign, scheduling, and
    admin/configuration. Existing central components are mandatory; any custom
    control needs prior product-owner authorization and a narrow recorded scope.
-   Extend central contracts only after a repeated need is demonstrated.
+   Extend central contracts only after a repeated need is demonstrated. Make
+   Campaign, Mail, and Files the first complete adaptive, multi-perspective
+   documentation set.
 7. Align executable WebUI contributions with manifest/configured-system
    metadata and make focused views manually/default selectable without waiting
    for Workflow.
@@ -902,9 +987,10 @@ Priorities:
    evidence.
 
 **Gate.** A clean release candidate can be installed and restored; the
-Campaign reference journey and one external calendar operation survive
-provider/worker failure without duplicate or unexplained effects; the UI and
-operator evidence are reproducible.
+Campaign reference journey uses only Mail-owned profiles and it and one
+external calendar operation survive provider/worker failure without duplicate
+or unexplained effects; the UI, adaptive documentation, and operator evidence
+are reproducible.
 
 ### Horizon 2: shared human-work and evidence spine
 
@@ -914,10 +1000,11 @@ cross-module automation is enabled.
 
 Priorities:
 
-1. Deliver the smallest connected path from a forms/runtime input through a
-   case or domain record into assigned work. Add approval, template, postbox,
-   notification, search, and record-reference capabilities only as the selected
-   journey requires them.
+1. Deliver the selected function-bound Postbox path from a Campaign delivery
+   target through Organizations, Identity, IDM, and Access into visible,
+   assigned responsibility. Extend from that proven path to forms/runtime,
+   cases, approval, notification, search, and record references only as a
+   selected journey requires them.
 2. Stabilize actor/function/delegation, tenant/organization, permission, policy,
    privacy, and audit contracts across those modules.
 3. Establish generic external-reference, action/effect, command, outbox,
@@ -935,9 +1022,11 @@ workflow-driven stories is deliberately deferred until reprioritized. This
 horizon should make manual work, views, contracts, and evidence strong enough
 that Workflow later coordinates stable actions rather than inventing them.
 
-**Gate.** One incoming submission can create or link a case, appear as assigned
-work, be reviewed through a focused view, produce a governed communication and
-document, and remain traceable with and without optional modules installed.
+**Gate.** One Campaign message can reach a function-bound Postbox and follow
+current assignment/delegation without personal mailbox ownership; one incoming
+submission can create or link a case, appear as assigned work, be reviewed
+through a focused view, produce a governed communication and document, and
+remain traceable with and without optional modules installed.
 
 ### Horizon 3: reusable end-to-end service packages
 
@@ -948,9 +1037,12 @@ Priorities:
 
 - Consolidate controlled communications as the first hardened reusable
   package.
-- Select one next package by explicit product decision from these unordered
-  candidates: permit-to-payment, report-to-resolution,
-  training-to-certificate, or meeting-to-decision.
+- Deliver data-backed template/report generation with a safe HIS-style deep
+  launch as the next selected package proof.
+- Grow that source contract into one bounded, governed university analytical
+  data product before opening a general-purpose BI/dataflow program.
+- Follow with the collaborative document journey once generation, storage,
+  provenance, and DMS lifecycle boundaries are stable.
 - Add further candidates only after the selected package proves the shared
   spine rather than advancing all domain repositories horizontally.
 - Add Workflow transition/action execution only where a stable package proves
@@ -1021,12 +1113,16 @@ boundary, and retain operational, security, and evidence guarantees.
 | --- | --- | --- | --- |
 | Module/runtime composition | Implemented foundation with contract checks | Pinned release and package compatibility proof | Safe platform and ecosystem runtime |
 | Tenancy, identity, access, policy, audit | Useful local foundation | Actor/function/delegation, audit retention/export and target security proof | Institutional authority and accountability plane; federation later |
-| Campaign/files/mail | Strongest connected slice; target provider proof remains | Reference package, UI acceptance, real delivery/recovery drill | Governed communications capability |
+| Campaign/files/mail | Strongest connected slice; Mail-profile-only boundary and target provider proof remain | Reference package, adaptive docs, UI acceptance, real delivery/recovery drill | Governed communications capability and demonstration composition |
 | Calendar/scheduling/poll | Integrated domain foundations; target calendar and broader product acceptance remain | Accept implemented picker, participant privacy/policy hooks, lifecycle, response editing and CalDAV recovery; decide management ownership | Shared time, participation, and decision primitives |
 | Notifications | Inbox and dispatch/recovery foundation; external Mail handoff is not integrated | Mail provider proof, unified-inbox contribution and delivery-state UX | Cross-channel attention and delivery coordination |
 | Addresses and directories | Implemented adapters exist but configuration/target proof varies | Directory source, privacy, conflict and lifecycle package | Reusable people/contact source capability |
 | Docs/admin/ops/dashboard | Useful cross-product surfaces with incomplete rollout | Configured-system inventory, guided config, monitoring/recovery evidence | Explainability and operation of the configured product |
-| Forms/cases/tasks/approvals/postbox/search/templates | Concepts and uneven first slices | One manual end-to-end work/evidence spine | Reusable administrative coordination layer |
+| Organizations/identity/IDM/access/postbox | Normalized ownership concepts and uneven runtime slices | Function-bound delivery, reassignment/delegation, vacancy and access-evidence proof | Institutional responsibility and durable communication spine |
+| Forms/cases/tasks/approvals/search | Concepts and uneven first slices | Extend the proven responsibility path into one manual end-to-end work/evidence journey | Reusable administrative coordination layer |
+| Templates/reporting/data sources | Boundary concepts or scaffolds | One reproducible data-backed document/report and safe HIS-style launch | Governed document production, reports, dashboards, and analytical consumption |
+| Analytical data products/dataflow | Selected direction; platform contracts not yet implemented | One bounded university source-to-indicator path with staging, quality, lineage and promotion proof | Transparent institutional BI and cross-process reporting |
+| DMS/collaborative editing | Boundary concept and tag-only scaffold | One Files-backed version lifecycle, then one provider-neutral editing session | Collaborative documents, review, approval and records-ready renditions |
 | Workflow/automation | Concept only; no discoverable Workflow runtime; program postponed | Stable action/effect providers and an explicitly reprioritized bounded journey | Configurable governed process coordination |
 | Domain modules | Mostly boundary concepts or seeds | Only the modules required by a reference package | Reusable semantics above the shared spine |
 | Connectors and protocols | Catalogue/strategy plus several module-specific adapters | Profile/runtime, source-of-truth, health and one real landscape | Coexistence with institutional IT |
@@ -1102,39 +1198,41 @@ provides all applicable evidence below.
 
 ## Near-term portfolio order
 
-This order keeps the larger destination in view while honoring the deliberate
-pause on workflow-driven user-story implementation.
+This order is now selected. Detailed slices and gates are in the
+[Reference Journey Program](REFERENCE_JOURNEY_PROGRAM.md). Workflow-driven
+user-story implementation remains paused.
 
-1. **Release and recovery baseline.** Turn the recently harmonized repositories
-   into a clean pinned candidate; close backup/restore, target-provider,
-   monitoring, security, and capability-assessment evidence gaps.
-2. **Campaign reference acceptance.** Complete the campaign UI/state/audit
-   program as the reference for central components, consequence language,
-   durable delivery, report filtering, and operator intervention.
-3. **Calendar/scheduling/poll acceptance.** Run product and target-provider
-   acceptance over the implemented calendar selection, durable CalDAV effects,
-   participant privacy, response editing, transition/audit semantics, and
-   shared scheduling UI. Decide and then prove the organizer/admin management
-   policy; organizer-only management with an administrator override is not yet
-   the implemented mutation model.
-4. **Focused experience and configured-system metadata.** Align routes and
-   manifests; implement manual/user/role/task-suggested views, active-source
-   explanation, and the full-system escape independently of Workflow.
-5. **Connector and infrastructure profile.** Select one real identity/groupware/
-   file landscape, implement profile/source-of-truth/health contracts, and
-   exercise degraded and recovery behavior.
-6. **Manual human-work spine.** Build the smallest forms-runtime, case, task/
-   inbox, approval, template, postbox/notification, search, and evidence path
-   without requiring workflow automation.
-7. **First service configuration package.** Package one bounded journey with
-   role defaults, focused views, connectors, policies, configured docs,
-   preflight, acceptance tests, and upgrade/recovery evidence.
-8. **Resume Workflow only by explicit priority decision.** When resumed, start
-   with the already stable actions and one package; do not turn it into a
+0. **Continuous safe foundation.** Keep the composition green and version
+   aligned; close connector destination pinning, response limits, throttling,
+   profile/secret ownership and audited deletion, release/recovery, central UI,
+   focused-view, provenance, and configured-documentation gaps only as far as
+   the active reference stage requires.
+1. **Campaign demonstration composition.** Enforce Mail-profile-only transport,
+   finish Campaign/UI/state/audit and target delivery/recovery acceptance,
+   complete adaptive Campaign/Mail/Files documentation, and package runnable
+   examples as the first pinned reference product.
+2. **Function-bound Postbox.** Implement Postbox and the
+   Organizations–Identity–IDM–Access responsibility path; add Campaign delivery
+   to a function in an organizational unit and prove reassignment, delegation,
+   vacancy, retention, and audit behavior.
+3. **Templates, Reports, and deep launch.** Build one data-backed document and
+   one report through curated source contracts; open the task safely from a
+   mock and then target HIS-style producer; preserve reproducible input,
+   definition, output, and return-reference evidence.
+4. **Governed university BI path.** Starting from that concrete source, add one
+   scheduled staging, quality, transformation, semantic-product, lineage, and
+   policy-aware reporting path. Package it for repeatable promotion between
+   development, test, and production before generalizing dataflow.
+5. **Collaborative document lifecycle.** Add DMS versions, review/approval,
+   provider-neutral editing sessions, one collaborative editor, conflict and
+   recovery behavior, and Records handoff over Files-backed content.
+6. **Maintain already integrated product slices.** Complete regression and
+   target acceptance for calendar/scheduling/poll and other shipped foundations
+   without displacing the selected reference path; implement new feature
+   programs only when they are required by a stage or explicitly reprioritized.
+7. **Resume Workflow only by explicit priority decision.** When resumed, start
+   with stable actions from a demonstrated package; do not turn it into a
    second domain layer.
-9. **Advance records/compliance and later domain configurations** only when the
-   shared spine and a concrete regulated or institutional journey are ready to
-   consume them.
 
 ## Product decisions to make progressively
 
@@ -1145,8 +1243,6 @@ them; they do not block the product vision today.
   reference release?
 - Which real identity, groupware, file/DMS, and deployment stack should define
   the first integration profile?
-- Which service package should follow controlled communications: public
-  service, internal report-to-resolution, training, or institutional meetings?
 - When should the postponed Workflow program resume, and which single package
   will constrain its first implementation?
 - Which objects and fields remain authoritative in GovOPlaN versus each target
@@ -1154,7 +1250,21 @@ them; they do not block the product vision today.
 - Which default participant privacy profiles should ship for scheduling,
   consultation, committee, and public participation?
 - What assurance, signature, federation, and E2EE levels are required for the
-  first trusted postbox deployment?
+   first trusted postbox deployment?
+- Which external IDM source and conflict, disable, delegation, and vacancy
+  policy should prove delivery to organizational responsibility?
+- Which HIS or other specialist system should be the first deep-launch
+  producer, and which callback/reference behavior can it support?
+- Which bounded university dataset, reporting date semantics, official keys,
+  accepted calculation, privacy profile, and drill-down level should define the
+  first analytical data product?
+- After the first source-to-report proof, do repeated source/dataflow contracts
+  justify separate `govoplan-datasources` and `govoplan-dataflow` modules?
+- Which collaborative editor should be the first target, and should its first
+  accepted experience emphasize concurrent editing, controlled check-out, or
+  both?
+- Which archive/records target and signature or approval assurance level should
+  receive the first accepted collaborative rendition?
 - Which sanctions/embargo data source or provider, matching policy, legal basis,
   review roles, evidence period, and rescreen triggers should define the first
   export-control package?
@@ -1180,6 +1290,12 @@ when it accumulates modules. Useful measures include:
   package;
 - successful restore and disaster-recovery drills within declared objectives;
 - connector health, freshness, conflict, and manual-intervention backlog;
+- percentage of generated artifacts and reported measures reproducible from
+  versioned source, transformation, definition, parameter, and output evidence;
+- analytical freshness, validation/quarantine resolution, schema-drift, and
+  permitted drill-down outcomes for each published data product;
+- collaborative save-conflict, recovery, review, approval, and accepted-version
+  integrity outcomes;
 - privacy and records-policy conformance with documented exceptions;
 - reuse of the same package across institutions without code forks; and
 - reduction in special-case module coupling and deployment-local patches.
@@ -1196,8 +1312,11 @@ when it accumulates modules. Useful measures include:
 - Describing corrective actions as if they erase already observed effects.
 - Making raw JSON, deployment files, or direct database edits the normal
   configuration experience.
-- Building a broad BI/dataflow, native project-management, mobile, or embedded
-  AI program before reference journeys prove the shared need.
+- Building an unbounded general-purpose dataflow platform before the selected
+  source-to-document and university source-to-indicator journeys prove the
+  contracts; BI itself is now an explicit reference-program stage.
+- Building native project-management, mobile, or embedded AI programs before a
+  reference journey proves the shared need.
 - Claiming production readiness from unit tests, local source checkouts, or
   connector scaffolds alone.