docs(roadmap): refine postbox and university BI paths
Some checks failed
Dependency Audit / dependency-audit (push) Failing after 15s
Security Audit / security-audit (push) Failing after 12s

This commit is contained in:
2026-07-21 20:48:55 +02:00
parent 097f9ca2f4
commit a8abb85676
2 changed files with 102 additions and 43 deletions

View File

@@ -870,11 +870,17 @@ can be tested.
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.
4. The Postbox remains addressable with zero, one, or several incumbents. During
vacancy it retains the delivery and visibly waits for a holder rather than
falling back to a personal account.
5. An authorized function holder or time-bounded delegate receives a
device-bound grant for the policy-selected key epochs and handles the
message in an explicit represented-function context.
6. Hand-over, revocation, or delegation expiry rotates/withdraws future key
access without claiming to erase plaintext already obtained. Content is
corrected or superseded by a linked version, never silently substituted.
7. Delivery, vacancy, assignment, key access, delegation, action, and correction
evidence remains connected and distinguishes multiple incumbents.
### Story J: from specialist-system context to reproducible document
@@ -892,17 +898,25 @@ can be tested.
### 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.
1. A governed catalog declares read-only HIS and CampusOnline source owners,
purpose, classification, schema, extraction mode, freshness, and credentials
for the internal student-statistics subject area.
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
3. The product records reference date separately from extraction, acceptance,
and freeze dates: for example, a `1 September` state accepted on
`12 December` becomes the pinned semester snapshot. Corrections supersede it
visibly rather than rewriting it.
4. In a graphical typed data-flow editor, versioned source, validation, mapping,
transformation, aggregation, and data-product nodes map official keys,
organizational hierarchies, time dimensions, and measures. The graph is
acyclic, previewable, testable, and carries lineage and pinned versions.
5. Reporting serves the internal student-statistics product with policy-aware
aggregates and permitted drill-down. A list report can become a governed
source for a downstream template-backed publishable report.
6. 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
7. Package promotion reproduces the accepted reports in development, test, and
production; corrections create new evidence rather than rewriting history.
### Story L: from generated artifact to approved collaborative record
@@ -1216,16 +1230,19 @@ user-story implementation remains paused.
examples as the first pinned reference product.
2. **Function-bound Postbox.** Implement Postbox and the
OrganizationsIdentityIDMAccess responsibility path; add Campaign delivery
to a function in an organizational unit and prove reassignment, delegation,
vacancy, retention, and audit behavior.
to a function in an organizational unit and prove vacancy, multiple
incumbents, reassignment, time-bounded delegation, key-epoch access,
retention, and audit behavior without personal ownership fallback.
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.
4. **Governed university BI path.** Start with read-only HIS/CampusOnline data
and an internal student-statistics product. Add scheduled staging, explicit
reference/freeze states, quality, a graphical typed transformation and
aggregation flow, semantic-product lineage, list-report chaining, and a
template-backed publishable report. Package it for repeatable promotion
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.
@@ -1252,15 +1269,16 @@ them; they do not block the product vision today.
system, and which conflict/failure behavior is acceptable?
- 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?
- Which external IDM source and conflict, disable, delegation, and vacancy
policy should prove delivery to organizational responsibility?
- Which history window, device assurance, organizational recovery/quorum,
rotation strength, signature, and federation profile is required for the
first trusted E2EE Postbox deployment?
- Which external IDM source and conflict/disable policy should prove function
assignment and time-bounded delegation for 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?
- Which exact HIS/CampusOnline interfaces, student-statistics fields and
official keys, accepted calculation, freeze/correction policy, 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

View File

@@ -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 OrganizationsIdentityIDMAccess 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;