Raw view — RETENTION-1@v2

sha256: cab00edbf932b479269a6eb017e1af7e9ca70440f9031a6bf72b5be45551809f

Published law page — ← laws index — raw .md

# RETENTION — OBSERVED INVENTORY (PUBLISHED, v2)

Word Of Clout, LLC · PUBLISHED as an observed inventory, not a retention
promise · supersedes /laws/retention-v1.1.md and /laws/retention-v1.md
(both version's bytes are archived under ARCHIVE-1, WO-20261003-01 U0;
their identities are listed in /archive/index.json) · nothing in this
document enters any record bytes, epoch bytes, or signed manifest ·
published at /laws/retention-v2.md

**PUBLISHED (v2) sha256 (this file's bytes):** recorded in the
published-laws manifest entry RETENTION-1@v2 and in /laws/SHA256SUMS —
the manifest is the authority.

The previous retention draft proposed a "seven years / never deleted"
promise. That promise is not kept by the current operation — it would
enter signed manifests as a false statement. This document replaces it
with an observed inventory: what happens today to each category of data,
cited from the code. What is promised is decided by the operator before
it is published; nothing enters record or epoch bytes until a promise is
backed by operation.

**CRYPTO-SHRED-1 status (observed):** steps 1–3 are BUILT — the kernel
envelope module, the keyed-commitment finding schema, the pinned root
encrypt/decrypt/shred ops (in-tree proposals only, not installed), and
the six section-9 gates each green with its red vector (runner
node kernel/build/engagement_crypto_test.js, exit 0). The fixture shred
has been RUN with the fixture key. The KEK ceremony and any ledger
deletion have not occurred — they are operator actions, recorded only
when they happen. The retention law remains undrafted; nothing further
from CRYPTO-SHRED-1 enters public copy until it is live.

## 1. Submitted Roster Copy

**What happens today (OBSERVED):**
- The board roster zip is fetched, extracted, and the raw bytes are recorded
  as a `source_artifact` in the woc_kernel MongoDB (MongoDB collection
  `source_artifacts`, db `woc_kernel`). The artifact carries `id`,
  `fetched_by`, `fetched_at`, and `content_hash`.
- The artifact persists in MongoDB. No deletion path is observed in the
  kernel code (roles.ts line 1: "WOC-11: the datastore itself enforces
  append-only").
- The extracted zip file in the filesystem is not retained — the kernel
  processes and ingests from the zip and the zip file itself may be
  cleaned by the OS or by the `unlinkSync` in fetch_nppes.ts (line 311).

**Cited from:** kernel/fetch_board.ts, kernel/ingest_board.ts,
kernel/roles.ts line 1, kernel/fetch_nppes.ts line 311.

## 2. Identifiers in Signed Evidence

**What happens today (OBSERVED):**
- Practitioner identifiers (licence numbers, NPI numbers) are stored in
  woc_kernel MongoDB in three collections:
  - `propositions` — one document per subject/predicate pair, carrying
    the proposition `id`, `subject`, `predicate`, `object`
  - `verifications` — one document per proposition verification,
    carrying `id`, `proposition_id`, `observation_ids`, `verdict`
  - `observations` — one document per authority reading, carrying
    `id`, `subject_ref`, `predicate`, `value`, `observer`
- The MongoDB collections are the persistent store. The kernel roles
  grant insert and find (read), not delete (boot.cjs line 98:
  `{actions: ["insert", "find"]}`). Records are never programmatically
  deleted.
- Signed records (the published record JSON) are written to
  `published_records` in woc_kernel and also committed to the woc
  repo under `public/records/`. The repo copy is git-committed and
  never removed (git history is immutable).

**Cited from:** kernel/ingest_board.ts, kernel/verify_board.ts,
kernel/sign_board.ts, kernel/boot.cjs line 98, kernel/roles.ts.

## 3. Correspondence

**What happens today (OBSERVED):**
- Email correspondence is dispatched via SendGrid (sendgrid web API).
  The gateway holds `sendgrid_api_key` and `sendgrid_from_email` in its
  environment; the email content is generated at send time and not
  persisted server-side beyond SendGrid's own logs.
- Operator messages are logged as session transcripts by the operator
  gateway, stored host-side outside the sandbox — not accessible from
  the kernel or the site repo.
- No programmatic correspondence archive exists in the kernel.

**Cited from:** kernel/sendgrid (gateway env vars from INTERNAL_NOUNS list
in records_public_copy.ts:259), operator gateway session logs.

## 4. Audit Metadata

**What happens today (OBSERVED):**
- Audit receipts, drift reports, and review evidence are stored in the woc
  repo under `docs/reviews/astra/`, `docs/ops/audits/`, and
  `kernel/evidence/`. These are git-committed files — never removed from
  the repo history.
- Kernel dumps and restore tests use ephemeral mongod processes with
  temporary dbpaths — these are cleaned on process exit (boot.cjs line 58:
  `rmSync(DBPATH, {recursive: true, force: true})`). The ephemeral dbpath
  is a test fixture, never a production store.
- Host-side evidence and receipts are stored in a host-managed receipts
  directory outside the sandbox — not accessible from the kernel.

**Cited from:** boot.cjs lines 56-58, kernel/kernel_restore_test.ts,
kernel/kernel_dump.ts, docs/ops/audits/, docs/reviews/astra/.

## 5. Scratch and Temporary Files

**What happens today (OBSERVED):**
- The workspace carries scratch files under scratch-prefixed directories
  in both repos. These are operator-authored files, not programmatic
  artifacts. Standing dispositions authorize cleaning scratch/residue
  older than 48h.
- The build outputs in `kernel/build/` are recompiled on every commit —
  the previous build is overwritten, not archived.
- The staging host paths for deploy artifacts are host-managed
  temporary locations.

**Cited from:** AGENTS.md "Hygiene" lane — delete scratch/residue.

## Next Step

The operator reads this inventory and decides what is promised. A
retention promise would be backed by the operation before entering any
record bytes, epoch bytes, or signed manifest. Until then, this document
is an observation, not a commitment.