Governed Data Platform · replayable demos
Profile-driven governance for data in motion.
A data plane, not a catalog. A profile declares what a dataset must contain, which controls apply to it and under what condition. The platform enforces that as the data passes through, then publishes what it enforced. Lineage is applied to every run and cannot be switched off; a machine may propose a profile, but only a named person approves one.
Everything below replays captured engine runs over synthetic data. Each page is one self-contained file: no server, no login, no model call, nothing leaves your browser. Open them in a desktop browser.
Start here: one source, three releases
The same governed corpus rarely has one audience. The platform decides what each recipient receives; it does not hand over a file and trust the recipient to redact it. This scene replays two real runs as records in space, with the chain they pass through as structure, recipient authority as the split, and time as the scrubber.
Governed Data, in Four Dimensions 3D + time · two acts
Act 1. 2,000 telecom call detail records enter, pass the quality gate, go through the ordered controls and split into three releases: an internal analyst, a carrier under §222, and an agency holding a warrant. Follow one record and watch its subscriber number and cell identifier change by recipient.
Act 2. 2,000 counter-UAS detections, each tied to where its operator is standing. An uncleared desk sees identities minimised and every aircraft intact; a cleared partner with a recorded retention basis sees identity in full; and detections with no basis are withheld from the cleared partner entirely.
| release | served_msisdn | cell_identifier |
|---|---|---|
| Unauthorised | *******0180 | [COARSENED] |
| CPNI authorised (§222) | 18135550180 | [COARSENED] |
| Warrant on file | 18135550180 | 15942 |
Measured on the shipped seed. §222 authority unlocks the subscriber number and does not uncoarsen cell-site location, because those are separate authorities under §222 and Carpenter.
IEF walkthroughs: a use case established, then files flowing through it
Three use cases, each in two phases. Phase 1 establishes the use case: a model proposes the dataset kind and a concept per column, the composer maps those proposals to structure suggestions, and a reviewer commits the Wrapper, Transactional and Semantic definitions and their controls. Phase 2 processes files through those definitions: quality checks, quarantine branches, the controls that apply, and the output. Each includes a clean file, a file with record-level defects, and a file missing a required column.
Every walkthrough has a flat version and a 3D + time version with the same 122 steps and the same captured evidence. Select Play both phases. Click a field to follow its value from physical source to semantic declaration; click a layer to inspect it.
Telecom records disclosure §222 · Carpenter
Synthetic call detail records. Subscriber masking and reduced cell-site precision, every control on its own line. The 4D version adds two recipient chapters: the same 2,000 governed records released to three recipients, and a manifest of what each authority unlocked.
Federal records transfer retention · E.O. 13526 · §2.3
Electronic records with retention, personal-data handling, classification marking and a NARA-mapped target. The 4D version adds §2.3 by recipient: the uncleared desk receives every record with creators minimised; the cleared partner receives fewer and has the rest withheld entirely, because clearance without a recorded retention basis is not entitlement.
Applicant vetting exchange declared PII · typed redaction
Applicant records with declared field meanings. Typed redaction of personal fields while the employer field is preserved, which is the point: a declaration says what a column is, so the control knows what to leave alone.
Runbooks for the live platform
These two documents script demos against the running platform, which reads real uploads: a MISB ST 0601 KLV stream, an ASTM F3411 Remote ID capture, a SAPIENT (BSI Flex 335) capture. They are not playable here, but every figure in them came off the deployed container rather than being estimated, including the ones that make the platform look less clever than it is.
SAPIENT demo runbook BSI Flex 335 · three acts
A sensor capture read through the standard's own schema and governed; the enriched record governed three ways by recipient; and the governed corpus written back out as SAPIENT per recipient, then fed straight back in through the front door.
Counter-UAS demo runbook ASTM F3411 · two acts
The raw radio capture the platform reads and then refuses to govern, naming each missing element; then the enriched record it governs three ways. The finding: governance obligations attach at enrichment, not at the sensor.
What these replays are, and are not
Model responses and setup decisions in the walkthroughs are illustrated, not fetched: nothing here calls a model or changes a profile's approval state. Runtime counts and field changes replay captured engine runs over the platform's shipped samples and controlled defect variants; they say what the engine did, not how fast it did it. Every count is held to the repository by a test, so a replay that drifts from the shipped seeds fails the build.