docs(roadmap): refine postbox and university BI paths
This commit is contained in:
@@ -870,11 +870,17 @@ can be tested.
|
|||||||
acting context through their owned contracts.
|
acting context through their owned contracts.
|
||||||
3. Postbox accepts one durable message and attachment references and returns a
|
3. Postbox accepts one durable message and attachment references and returns a
|
||||||
delivery receipt; Campaign or another sender retains only typed references.
|
delivery receipt; Campaign or another sender retains only typed references.
|
||||||
4. An authorized function holder or delegate discovers and handles the message.
|
4. The Postbox remains addressable with zero, one, or several incumbents. During
|
||||||
5. Vacancy, ambiguity, expiry, or unavailable dependencies create visible safe
|
vacancy it retains the delivery and visibly waits for a holder rather than
|
||||||
states rather than an implicit personal fallback.
|
falling back to a personal account.
|
||||||
6. Reassignment changes future access without moving or rewriting the message;
|
5. An authorized function holder or time-bounded delegate receives a
|
||||||
delivery, access, and correction evidence remains connected.
|
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
|
### 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
|
### Story K: from operational sources to trusted institutional indicator
|
||||||
|
|
||||||
1. A governed catalog declares source owner, purpose, classification, schema,
|
1. A governed catalog declares read-only HIS and CampusOnline source owners,
|
||||||
extraction mode, reporting-date semantics, freshness, and credentials.
|
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,
|
2. An ingestion run stages a snapshot or watermark and records schema drift,
|
||||||
validation findings, quarantine, and replay evidence.
|
validation findings, quarantine, and replay evidence.
|
||||||
3. Versioned transformations map official keys, organizational hierarchies,
|
3. The product records reference date separately from extraction, acceptance,
|
||||||
time dimensions, and measures into a documented analytical data product.
|
and freeze dates: for example, a `1 September` state accepted on
|
||||||
4. Reporting serves policy-aware aggregates and permitted drill-down with the
|
`12 December` becomes the pinned semester snapshot. Corrections supersede it
|
||||||
calculation and lineage visible.
|
visibly rather than rewriting it.
|
||||||
5. Scheduled outputs, APIs, templates, or open-data handoffs use the same
|
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.
|
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.
|
production; corrections create new evidence rather than rewriting history.
|
||||||
|
|
||||||
### Story L: from generated artifact to approved collaborative record
|
### 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.
|
examples as the first pinned reference product.
|
||||||
2. **Function-bound Postbox.** Implement Postbox and the
|
2. **Function-bound Postbox.** Implement Postbox and the
|
||||||
Organizations–Identity–IDM–Access responsibility path; add Campaign delivery
|
Organizations–Identity–IDM–Access responsibility path; add Campaign delivery
|
||||||
to a function in an organizational unit and prove reassignment, delegation,
|
to a function in an organizational unit and prove vacancy, multiple
|
||||||
vacancy, retention, and audit behavior.
|
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
|
3. **Templates, Reports, and deep launch.** Build one data-backed document and
|
||||||
one report through curated source contracts; open the task safely from a
|
one report through curated source contracts; open the task safely from a
|
||||||
mock and then target HIS-style producer; preserve reproducible input,
|
mock and then target HIS-style producer; preserve reproducible input,
|
||||||
definition, output, and return-reference evidence.
|
definition, output, and return-reference evidence.
|
||||||
4. **Governed university BI path.** Starting from that concrete source, add one
|
4. **Governed university BI path.** Start with read-only HIS/CampusOnline data
|
||||||
scheduled staging, quality, transformation, semantic-product, lineage, and
|
and an internal student-statistics product. Add scheduled staging, explicit
|
||||||
policy-aware reporting path. Package it for repeatable promotion between
|
reference/freeze states, quality, a graphical typed transformation and
|
||||||
development, test, and production before generalizing dataflow.
|
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,
|
5. **Collaborative document lifecycle.** Add DMS versions, review/approval,
|
||||||
provider-neutral editing sessions, one collaborative editor, conflict and
|
provider-neutral editing sessions, one collaborative editor, conflict and
|
||||||
recovery behavior, and Records handoff over Files-backed content.
|
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?
|
system, and which conflict/failure behavior is acceptable?
|
||||||
- Which default participant privacy profiles should ship for scheduling,
|
- Which default participant privacy profiles should ship for scheduling,
|
||||||
consultation, committee, and public participation?
|
consultation, committee, and public participation?
|
||||||
- What assurance, signature, federation, and E2EE levels are required for the
|
- Which history window, device assurance, organizational recovery/quorum,
|
||||||
first trusted postbox deployment?
|
rotation strength, signature, and federation profile is required for the
|
||||||
- Which external IDM source and conflict, disable, delegation, and vacancy
|
first trusted E2EE Postbox deployment?
|
||||||
policy should prove delivery to organizational responsibility?
|
- 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
|
- Which HIS or other specialist system should be the first deep-launch
|
||||||
producer, and which callback/reference behavior can it support?
|
producer, and which callback/reference behavior can it support?
|
||||||
- Which bounded university dataset, reporting date semantics, official keys,
|
- Which exact HIS/CampusOnline interfaces, student-statistics fields and
|
||||||
accepted calculation, privacy profile, and drill-down level should define the
|
official keys, accepted calculation, freeze/correction policy, privacy
|
||||||
first analytical data product?
|
profile, and drill-down level should define the first analytical data product?
|
||||||
- After the first source-to-report proof, do repeated source/dataflow contracts
|
- After the first source-to-report proof, do repeated source/dataflow contracts
|
||||||
justify separate `govoplan-datasources` and `govoplan-dataflow` modules?
|
justify separate `govoplan-datasources` and `govoplan-dataflow` modules?
|
||||||
- Which collaborative editor should be the first target, and should its first
|
- Which collaborative editor should be the first target, and should its first
|
||||||
|
|||||||
@@ -183,6 +183,15 @@ repeatable.
|
|||||||
- Campaign consumes a generic delivery-target capability. It may target an
|
- Campaign consumes a generic delivery-target capability. It may target an
|
||||||
email recipient or a function-bound Postbox without importing either
|
email recipient or a function-bound Postbox without importing either
|
||||||
module's internals.
|
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
|
### Implementation slices
|
||||||
|
|
||||||
@@ -195,18 +204,23 @@ repeatable.
|
|||||||
3. Complete the Organizations–Identity–IDM–Access function-assignment and
|
3. Complete the Organizations–Identity–IDM–Access function-assignment and
|
||||||
delegation path, including provenance and compatibility migration from
|
delegation path, including provenance and compatibility migration from
|
||||||
legacy projections.
|
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
|
references, optional external-mail bridge, and notification attention
|
||||||
signals through capabilities.
|
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.
|
optional module, retention, and future E2EE limitations honestly.
|
||||||
|
|
||||||
### Gate
|
### Gate
|
||||||
|
|
||||||
A campaign message can be delivered once to a function-bound Postbox; an
|
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
|
authorized holder can act in an explicit context; a reassignment changes future
|
||||||
access without moving or rewriting the message; vacancy and ambiguous context
|
access without moving or rewriting the message. A vacant Postbox remains
|
||||||
fail visibly; delivery, access, and later corrections remain auditable.
|
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
|
## 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,
|
cost/resource limits, retention, backup/restore, promotion between systems,
|
||||||
and reproducible release recipes.
|
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
|
### Implementation slices
|
||||||
|
|
||||||
1. Select one bounded, read-only university dataset and one decision-relevant
|
1. Bound the first HIS/CampusOnline student-statistics dataset and internal
|
||||||
report; define its legal/policy basis, source owner, official keys, time
|
report; define its legal/policy basis, source owners, official keys,
|
||||||
semantics, and acceptance calculation.
|
reference/freeze semantics, privacy level, and acceptance calculation.
|
||||||
2. Generalize the Stage 3 source profile into catalog, ingestion-run, staged
|
2. Generalize the Stage 3 source profile into catalog, ingestion-run, staged
|
||||||
dataset, validation, transformation, lineage, and data-product contracts.
|
dataset, validation, transformation, lineage, and data-product contracts.
|
||||||
3. Implement one scheduled incremental load with quarantine/replay and a fully
|
3. Implement one scheduled load and explicit frozen-state lifecycle with
|
||||||
transparent transformation into an aggregate product.
|
quarantine/replay and a fully transparent transformation into the internal
|
||||||
4. Serve the product through Reporting with policy-aware aggregate and
|
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.
|
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.
|
tests so they can be promoted from development to test to production.
|
||||||
|
|
||||||
### Gate
|
### Gate
|
||||||
|
|
||||||
One university data product can be rebuilt from a declared source snapshot or
|
One internal student-statistics product can be rebuilt from declared HIS and/or
|
||||||
watermark, passes explicit quality tests, explains every measure and mapping,
|
CampusOnline snapshots, preserves its reference and freeze dates, passes
|
||||||
enforces disclosure policy, survives schema/freshness failures visibly, and
|
explicit quality tests, explains every measure and mapping, enforces disclosure
|
||||||
produces the same accepted report across promoted environments.
|
policy, survives schema/freshness failures visibly, and produces the same
|
||||||
|
accepted list and template-backed report across promoted environments.
|
||||||
|
|
||||||
## Stage 5: Collaborative document editing
|
## Stage 5: Collaborative document editing
|
||||||
|
|
||||||
@@ -400,9 +439,11 @@ that first needs them:
|
|||||||
|
|
||||||
- first target SMTP/IMAP, file/directory, identity, and deployment profile;
|
- first target SMTP/IMAP, file/directory, identity, and deployment profile;
|
||||||
- first external IDM source and identity conflict/disable policy;
|
- 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 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;
|
drill-down level;
|
||||||
- whether repeated data-source and dataflow contracts justify separate
|
- whether repeated data-source and dataflow contracts justify separate
|
||||||
`govoplan-datasources` and `govoplan-dataflow` modules after the Stage 3 proof;
|
`govoplan-datasources` and `govoplan-dataflow` modules after the Stage 3 proof;
|
||||||
|
|||||||
Reference in New Issue
Block a user