Select a Stream
What do you want to see governed?
Pick a module to walk through directly, or a sector to see where dark data actually accumulates.
The Four Streams
Or Browse by Sector
S0
Setup — what BBAT governs
Four governed outputs from one sealed vault. Nothing leaves as raw data — only mathematically normalised bands, receipted at every step.
101
Dark Data Vault102
Trusted Execution Env.107
0→1 Normalization108
ACR Governance LayerArchive Triage
Retain, refer, or delete — every outcome receipted.
Monetisation
Hardware-disabled transmission until deletion attested.
Training Signals
Population bands only — no individual record training.
S1
The Dark Data Vault
Every archive record enters here first. Nothing computed inside ever leaves as raw content — only a normalised band does, and only after every governance gate clears.
Trusted Execution Environment (102)
A hardware-isolated compute boundary. The In-Vault Derivation Engine (106) and the 0→1 Normalization Engine (107) both run entirely inside it — no external process, including an administrator's own tooling, can read raw content out of this boundary.
S2 · BBAT · Fig 2
BBAT — Band-Based Archive Triage, live
Adjust an archive record's retention parameters. The Retention Band Classifier decides automatically — a human is only pulled in when the case is genuinely borderline.
Composite Retention Index vs. Threshold
A composite retention index is computed from normalized metadata parameters and compared against the applicable governance rule set — the archive's own basis for retention, not a comparison against another archive.
Adjust the bands and test overlap.
S3
Three outcomes, jurisdiction, and legal hold
Every archive resolves to exactly one of three states. Jurisdiction conflicts resolve to the strictest applicable rule. A legal hold overrides all of it.
RETAIN
Lawful basis exists. No action.
PURGE
No lawful basis. Deletion Workflow triggered.
PROMOTE
High value band. Routed to approved downstream-use pathway — an ACR-PROMOTE receipt is sealed.
Jurisdiction Hierarchy Protocol (¶[00055])
Legal Hold Override
S4 · DDME
DDME — Dark Data Monetisation Without Exposure
The commercial partner pays for band access, not data access. Pricing is band-overlap-based — tighter overlap means higher product-market fit, means a higher fee. The underlying data never moves.
B_dark vs. Partner Band — Overlap-Priced
Adjust and compute.
Delete-Before-Share — Hardware Enforcement Underneath
Level 1 — Procedural
Software-verified deletion; audit log entry.
Level 2 — Cryptographic
SHA-3-256 pre/post deletion hash commitment.
Level 3 — Hardware-Attested
TEE-signed Hardware Attestation Certificate.
◆ BDTS
BDTS — Band-Derived Training Signals
This is where dark data becomes AI training input — never as raw records, only as population-level bands, with structural resistance to model collapse built into intake itself.
125
Band Intake126
Population Aggregator127
Signal Extractor128
Privacy Validator131
AI Training InterfaceLive Population Signal — Band-Derived Training Stream
Idle — press Start to run a live signal test
Execution Provenance Check
Attests which execution environment processed each contributing band, and excludes any unattested contribution. Does not attest authorship or human origin of the underlying data.
Batch Triage — 25 Records at Once
S5 · CAAD · Fig 5A
CAAD — Cross-Agent Aggregation Detector
Five agents, each individually compliant. The detector looks for patterns visible only in aggregate — without ever de-anonymising a single agent.
Live Multi-Agent Activity — Five Sealed Receipt Streams
Idle — press Start to run a live agent-activity test
Composite retention index — weighted blend of time, cost, and risk factors (weights not disclosed here).
Fixed governance bands: P < 0.35 no action · 0.35 ≤ P < 0.60 advisory · P ≥ 0.60 receipt issued
"The pattern is real even when no single agent is. That is not a limitation of this detector — it is the specific thing it was built to see."
S6 · Fig 7
Single-Agent Trajectory Detector
Six sealed receipts, each individually band-compliant. The index looks for cumulative drift toward a boundary that no single receipt reveals.
S9 · Fig 12
SIGHT & SPAR — Supervisory Tier
Two watchers, neither one allowed to touch anything. SIGHT looks backward at one agent's own history; SPAR looks across many agents at once. Both can only raise a flag.
SIGHT (150) — Signal-based Insight Generated from Historical Trajectory
SPAR (151) — Systemic Pattern Analysis from Receipts
"Neither module modifies underlying tokens, source records, or governing rules absent a separately authorised operation."
◆ MODEL LAB
Governed vs. Ungoverned Claude
The same frontier model, the same question — once free, once checked by the sealed ACR receipt from this session. The difference is the invention.
Governed Claude vs Ungoverned Claude — Live AI Demonstration
The same model, asked the same question — once with no governance, once checked against the BBAT-derived band from this session.
● DEMO MODE — mock responses · no API key required
Demo mode is illustrative. Live mode makes real API calls billed to your own key — nothing is sent to or stored by this page.
S7 · Fig 8
Measurement Provenance Attestation
Not just "was this checked" but "did this measurement actually come from where it claims." An unattested parameter never reaches normalization.
S8
Everything, receipted
Every stage above issues its own sealed Actuation Compliance Receipt. None of them expose raw content. All of them are auditable after the fact.
Receipt types issued across this walkthrough
ACR-BBAT (109) · ACR-DDME (110) · ACR-BDTS (111) · ACR-PROMOTE · ACR-CAAD (138) · ACR-Trajectory (140)
RESULTS
Session governance summary
Every decision made in this walkthrough, sealed to a receipt.
GOVERNANCE OUTCOME
Walk through S1–ACR to populate this session's outcome
Visit each stage → return here for the summary
3
OUTCOMES
POSSIBLE
POSSIBLE
retain / purge / promote
0
RAW RECORDS
EXPOSED
EXPOSED
metadata-only triage
100%
DECISIONS
RECEIPTED
RECEIPTED
sealed · ACR
Zero raw content transmitted · Metadata-only triage confirmed · Sealed receipt per decision
"Every archive an institution is afraid to delete and afraid to keep now has a governed middle path — checked, receipted, and never exposed raw, regardless of which decision it resolves to."
Live: www.0to1doctrine.com
This can be tested live via API, comparing governed and ungoverned flows side by side.
Selected References
Family: PCT/IN2025/051943 · BBAT: India App. No. 202611113867, filed 23 September 2026
Core components: BBAT (103) · DDME (104) · BDTS (105) · CAAD (132) · SIGHT (150) · SPAR (151) · 20 claims · India App. No. 202611113867, filed 23 September 2026
Informational only. This demonstration describes a draft specification and its intended design goals; it is not an offer, warranty, or guarantee of performance, security, or results. Statements about capabilities are forward-looking and illustrative, have not been independently verified or certified, and actual outcomes may vary. Independent legal, patent, and technical review is required before any filing, funding, or deployment decision. Values shown throughout are illustrative examples only. Not for public distribution. Vatsal Soin © 2026. All Rights Reserved.
WITHOUT BBAT
What the same archive looks like ungoverned
No receipted deletion
A deletion request logged in a spreadsheet, not sealed to hardware attestation. If challenged later, there is no cryptographic proof it happened at all — only someone's word.
No cross-agent visibility
Five compliant-looking individual actions. No system watching for the pattern across all five. The systemic risk is invisible until it's already caused harm.
No provenance check
A sensor value enters the model with no verification it came from where it claims. Nothing catches this before it's already shaping a governed decision.
Worked Examples
Three complete scenarios, start to finish
Each one traces a single archive through every governance gate it actually passes through, with the receipt it produces.
Scenario 1 — A bank's ten-year-old KYC file
Age 10y against a 7y regulatory requirement, zero access in 18 months. The Retention Band Classifier routes it to the Deletion Workflow Module automatically. Delete-Before-Share runs all three assurance levels — procedural, cryptographic, then hardware-attested — before the Band Transmission Interface is enabled. An ACR-BBAT Receipt (109) is sealed, referencing the Hardware Attestation Certificate (124). No raw KYC data ever left the vault; only the sealed receipt exists downstream.
Scenario 2 — A hospital's population health signal
Ten years of de-identified patient outcome records enter the Band Intake Interface. The Population Band Aggregator combines them; the Privacy Preservation Validator confirms non-reconstructibility; the BDTS Package Component packages a training signal for a genuine research model. The ACR-BDTS Receipt (111) attests every contributing record traced to attested human-origin data — no synthetic substitution anywhere in the chain.
Scenario 3 — Five trading agents, one hidden pattern
Five independently-governed trading agents each clear their own risk band individually. The Cross-Agent Aggregation Detector computes P = 0.41 across all five — above the advisory threshold. A systemic advisory reaches the sector governance authority. No individual agent is named in the advisory; the pattern itself, not any single actor, is what triggered it.
Batch Governance Matrix
Many records, one governance pass
The Batch Assessment with Traceable, Controlled Handling (BATCH) module runs up to 10 archived records against 5 triage rule sets in one pass — a distinct outcome and receipt per record, no aggregate result substituted for any individual decision.
Click a cell to see that record's individual triage outcome. Green = RETAIN, red = PURGE, gold = PROMOTE.
Cross-Domain Scope
The same triage, across 44 governed sectors
Dark data does not stay inside one industry. BBAT's retention bands, DDME's hardware-enforced deletion, and BDTS's training-signal pipeline apply identically wherever an archive exists — the same 0→1 scale the core Doctrine already uses across its full domain library.
Governance Vision 2050
A law that does not go out of date
Ten domains not yet born, and forty-four that already are, governed by the same normalised scale — from a paper archive to whatever computing looks like decades from now.
"Dark data does not stop accumulating because governance hasn't caught up to it yet. Every archive created between now and 2050 — on hardware that doesn't exist yet, in formats not yet invented — resolves to the same 0-to-1 scale this architecture already uses today. The law was built to outlast the substrate it runs on."
This BBAT-specific vision sits alongside the core 0→1 Doctrine's own Governance Vision 2050 — see www.0to1doctrine.com for the full-architecture version of this same argument.
Real Regulatory Text, Live Links
What each standard actually requires — and where BBAT answers it
Tap a framework. Every link below goes to the actual published regulatory text, not a summary.
◆ Extended from the Governance Filing
When a deletion can never be undone
A validated deletion request can still be factually wrong. This checkpoint asks one more question before anything executes: can this be undone if it turns out to be a mistake?
The Parameter Trichotomy
Autonomous
Routine retention math the system may resolve on its own — no lawful basis, standard age check.
Compulsory Human
Borderline bands, or any action classified as non-recoverable — a named human must sign off.
Absolute Gate
A legal hold flag. Can never be crossed by any computation, no matter how confident.
Test It — Is This Deletion Recoverable?
◆ Post-Quantum Cryptography
Receipts that hold up after quantum computers arrive
Illustrative extension — confirm PCT support. The specification's quantum-resilience language is scope-limited to cryptographic integrity engineering; the specific algorithms below are a proposed embodiment, not yet claimed.
ML-DSA (Dilithium3)
NIST FIPS 204. Proposed for token signing — illustrative, not yet in the claims.
SPHINCS+
Proposed for ACR receipts — an archival-grade scheme, illustrative only.
Kyber-1024
Proposed lattice-based key exchange — illustrative, not yet in the claims.
Honest status: these algorithms are real, NIST-standardised, and correctly named here. Their use in this demonstration is illustrative and simulated — a certified cryptographic implementation library is required before any production deployment. This is stated plainly, not buried.
◆ Actuation Compliance Receipt
The sealed proof, shown directly
Every governed decision on every page you've run produces one of these — not a log entry, a sealed, tamper-evident record. Run a check anywhere in this demo, then generate a live receipt here.
What Makes This a Receipt, Not Just a Log Line
A log entry can be edited or deleted after the fact. This receipt binds the timestamp, band values checked, and outcome together with a simulated seal — illustrative of a tamper-evident record, not a certified cryptographic implementation. Production deployment requires a validated cryptographic library.