docs(roadmap): refine postbox and university BI paths

docs/REFERENCE_JOURNEY_PROGRAM.md

@@ -183,6 +183,15 @@ repeatable.
 - Campaign consumes a generic delivery-target capability. It may target an
   email recipient or a function-bound Postbox without importing either
   module's internals.
+- A Postbox exists independently of its current holders. Vacancy, one
+  incumbent, several incumbents, and time-bounded delegation are valid states;
+  none turns the Postbox into a personal account.
+- The E2EE target uses per-content keys and function/postbox key epochs.
+  Assignment grants device-bound access to policy-selected history, while
+  hand-over, revocation, and delegation expiry rotate or withdraw future key
+  access without claiming to erase plaintext already obtained.
+- Content and signed manifests are immutable. Correction or replacement is a
+  linked new object/version, never silent substitution.
 
 ### Implementation slices
 
@@ -195,18 +204,23 @@ repeatable.
 3. Complete the Organizations–Identity–IDM–Access function-assignment and
    delegation path, including provenance and compatibility migration from
    legacy projections.
-4. Add Campaign delivery to a function-bound Postbox, file attachment
+4. Define the E2EE key-grant/epoch profile for vacancy, multiple incumbents,
+   hand-over, history access, time-bounded delegation, recovery, and audit.
+5. Add Campaign delivery to a function-bound Postbox, file attachment
    references, optional external-mail bridge, and notification attention
    signals through capabilities.
-5. Document reassignment, delegation, vacancy, expired assignment, unavailable
+6. Document reassignment, delegation, vacancy, expired assignment, unavailable
    optional module, retention, and future E2EE limitations honestly.
 
 ### Gate
 
 A campaign message can be delivered once to a function-bound Postbox; an
 authorized holder can act in an explicit context; a reassignment changes future
-access without moving or rewriting the message; vacancy and ambiguous context
-fail visibly; delivery, access, and later corrections remain auditable.
+access without moving or rewriting the message. A vacant Postbox remains
+addressable, retains the delivery, and visibly reports that no holder can
+decrypt or act until assignment; multiple incumbents and delegates receive
+independent key/access evidence. Delivery, key access, and later corrections
+remain auditable.
 
 ## Stage 3: Templates, reports, data sources, and deep launches
 
@@ -314,26 +328,51 @@ evidence, policy, and correction across independently installable modules.
    cost/resource limits, retention, backup/restore, promotion between systems,
    and reproducible release recipes.
 
+### Selected first subject-area direction
+
+- Start with read-only HIS and CampusOnline source profiles and produce the
+  institution's internal student-statistics data product plus reports derived
+  from it.
+- Model reference/effective date separately from extraction, validation, and
+  freeze dates. For example, a semester state may describe `1 September`, be
+  accepted and frozen on `12 December`, and remain the reproducible source for
+  that semester's official statistics. Later corrections create a superseding
+  version; they never rewrite the frozen state silently.
+- Make a graphical, typed data-flow editor the primary analyst surface. Nodes
+  represent governed sources/snapshots, validation, mapping, transformation,
+  aggregation, a list report/data product, template rendering, and publication.
+  The graph is versioned, testable, previewable, acyclic, and shows schema,
+  lineage, quality findings, policy, and pinned upstream versions.
+- A list report may become a governed source for another flow. This enables
+  `source + transformations/aggregation -> list report/data product -> template
+  -> publishable report` without copying the calculation or losing lineage.
+
 ### Implementation slices
 
-1. Select one bounded, read-only university dataset and one decision-relevant
-   report; define its legal/policy basis, source owner, official keys, time
-   semantics, and acceptance calculation.
+1. Bound the first HIS/CampusOnline student-statistics dataset and internal
+   report; define its legal/policy basis, source owners, official keys,
+   reference/freeze semantics, privacy level, and acceptance calculation.
 2. Generalize the Stage 3 source profile into catalog, ingestion-run, staged
    dataset, validation, transformation, lineage, and data-product contracts.
-3. Implement one scheduled incremental load with quarantine/replay and a fully
-   transparent transformation into an aggregate product.
-4. Serve the product through Reporting with policy-aware aggregate and
+3. Implement one scheduled load and explicit frozen-state lifecycle with
+   quarantine/replay and a fully transparent transformation into the internal
+   student-statistics product.
+4. Implement the first graphical typed flow editor over those proven nodes,
+   including version/diff, validation, preview, cycle prevention, and pinned
+   upstream product versions.
+5. Serve the product through Reporting with policy-aware aggregate and
    drill-down behavior; export reproducible evidence and calculation metadata.
-5. Package mappings, transformations, validations, reports, documentation, and
+6. Chain one list report as a source into a template-backed publishable report.
+7. Package mappings, transformations, validations, reports, documentation, and
    tests so they can be promoted from development to test to production.
 
 ### Gate
 
-One university data product can be rebuilt from a declared source snapshot or
-watermark, passes explicit quality tests, explains every measure and mapping,
-enforces disclosure policy, survives schema/freshness failures visibly, and
-produces the same accepted report across promoted environments.
+One internal student-statistics product can be rebuilt from declared HIS and/or
+CampusOnline snapshots, preserves its reference and freeze dates, passes
+explicit quality tests, explains every measure and mapping, enforces disclosure
+policy, survives schema/freshness failures visibly, and produces the same
+accepted list and template-backed report across promoted environments.
 
 ## Stage 5: Collaborative document editing
 
@@ -400,9 +439,11 @@ that first needs them:
 
 - first target SMTP/IMAP, file/directory, identity, and deployment profile;
 - first external IDM source and identity conflict/disable policy;
-- first trusted Postbox assurance/E2EE profile and external-mail bridge;
+- first trusted Postbox assurance/recovery/history-access profile and
+  external-mail bridge;
 - first HIS or other launch producer and callback/reference contract;
-- first university dataset, report, reporting date semantics, and permitted
+- exact HIS/CampusOnline source endpoints, student-statistics keys and accepted
+  calculation, freeze/correction policy, privacy profile, and permitted
   drill-down level;
 - whether repeated data-source and dataflow contracts justify separate
   `govoplan-datasources` and `govoplan-dataflow` modules after the Stage 3 proof;