Registry D · order of construction

What gets built first,
and what it must never do.

8 steps in dependency order, 3 classes of thing that must not leak, and the primary sources every claim is allowed to rest on. The kernel is step one because everything after it inherits whatever the kernel got wrong.

← The spineThe migration waves
8steps, in dependency order
9classes of sensitive material
7named failure modes
12primary authorities of record
This is the order Kristen wrote, not a re-planning of it. Its one structural claim is worth stating plainly: steps one and two are not products. They are the kernel and the intelligence layer that every profession in the portfolio inherits — which is the same argument the migration waves make from the commercial side.

The roadmap

8 steps, and the order is the argument.

  1. Shared kernel

    identity, permissions, Case Room, evidence/claim model, provenance, ingestion, search, audit logging.

  2. PROOFCORE intelligence

    claim-to-source, contradictions, missing evidence, skeptic, timelines, entity resolution.

  3. TRUTHLINE flagship

    field capture, Proof Button, source vault, records, correction/version ledger, Citizen Mode.

  4. Profession SDK

    configurable schemas, agents, workflows, dashboards, simulations and guardrails.

  5. First profession portfolio

    executive, legal/forensics/IP, markets, teacher/health, entertainment, writer/publisher.

  6. Organization OS

    newsroom, publishing company, nonprofit, startup and more.

  7. Academy

    Teach Me / Test Me / simulation / competency pathways.

  8. Marketplace

    third-party expert packs and templates.

Security, privacy and the threat model

What must not leak, what holds it, and how it fails anyway.

A threat model that lists only controls is a brochure. This one names the failure modes as well — including the two that are specific to putting a language model near an evidence store.

Sensitive classes

  • confidential source identities
  • precise locations
  • unpublished allegations
  • privileged legal material
  • health/therapy data
  • material nonpublic financial/deal data
  • minors/vulnerable people
  • credentials/secrets
  • biometric/media originals

Controls

  • least privilege
  • separate source vault
  • encryption
  • retention/deletion policies
  • metadata scrubbing
  • immutable audit events
  • version provenance
  • restricted model/tool access
  • secret manager
  • public/private derivative separation

Major failure modes

  • source deanonymization
  • false identity merges
  • guilt by graph
  • hallucinated evidence
  • silent editing
  • accidental leakage
  • unreviewed high-stakes recommendations

Hallucinated evidence and guilt by graph are the two this architecture exists to make structurally hard rather than merely discouraged — the first by refusing to store a claim without a source, the second by giving a Finding no field that can hold a conclusion.

Packaging and verification

5 steps, and this site ran all of them.

This v2 release preserves the prior ZIP unchanged and adds expanded documentation.

A ZIP is a transport container, not a substitute for proper encryption of confidential operational data.

  1. 1. Test ZIP structure.
  2. 2. Compute whole-ZIP SHA-256.
  3. 3. Extract cleanly.
  4. 4. Verify internal file hashes against CHECKSUMS_SHA256.txt.
  5. 5. Confirm original legacy files remain present.
Every one of these was executed against the archive this material came from, and the result — including the one file the archive's own registries do not cover — is published rather than summarised. The verification →

Finalization

Priorities, and who has to be in the room.

Priorities

  • P0: provenance preservation, secret/PII scan, source protection, checksums, regulated-domain review.
  • P1: profession coverage, permissions, Proof/evidence UX, field mode, accessibility.
  • P2: naming/glossary polish, visual design, export formats.

Roles

  • Writer/editor
  • Engineer
  • Legal/IP counsel
  • Security/privacy reviewer
  • Product/UX designer
  • Accessibility reviewer
  • Domain SMEs

Four of these seven are review roles rather than build roles. On a system that makes legal, financial and health claims, that ratio is the design.

Where the facts are allowed to come from

9 prioritised source classes.

Official and primary first, in every domain. A system whose whole claim is that it can show its work cannot rest that work on aggregators.

  • Public accountability: official government award, procurement, audit and filing systems.
  • Markets: company filings and regulator databases.
  • Nonprofits: official tax-exempt and Form 990 records.
  • IP: USPTO and U.S. Copyright Office.
  • Legal: primary law, opinions, official court/jurisdiction sources and ethics guidance.
  • Health: HHS/FDA and authoritative health agencies.
  • Forensics/psychology: professional specialty guidelines and validated methods.
  • Security/AI governance: NIST.
  • Accessibility: W3C WCAG and government design-system guidance.

12 authorities of record

  • NIST
  • W3C WCAG
  • USAspending
  • SEC EDGAR
  • FEC/OpenFEC
  • IRS TEOS/Form 990
  • USPTO
  • U.S. Copyright Office
  • HHS
  • FDA
  • APA
  • ABA
Naming an authority is not a claim of endorsement by it. These are the bodies whose published material the system is designed to read and cite; none of them has reviewed, approved or been consulted about anything on this site.