Skip to content

RECEIVED COPY — authored cross-fence (RTOpacks side), relayed by Tim 2026-07-01. Original of record lives in the RTOpacks repo. Per FENCE-PROTOCOL-01 §4 this copy is never edited and never promoted into home canon; local force comes from UCCA-ACK-CORRECTION-01.

title: RTOPACKS-CORRECTION — D-3's mechanism, corrected from bytes doc_id: RTOPACKS-CORRECTION-01 status: READY to cross (no open slots). Corrects one factual claim in the crossed record; per FENCE-PROTOCOL-01 §3, correction is by new crossing content — no crossed original is edited. layer: crossing artefact (original of record filed RTOpacks side, crossings/sent/) canonical: false authored: 2026-07-01 NYC — from CORPUS-INGESTION-RECON-01 (Alex, read-only, byte-confirmed) relates_to: RTOPACKS-ENGINE-BRIEF-01 D-3; RTOPACKS-RESPONSE-TO-ASSESSMENT-01 Q-D3, Q-R1a, Q-R2a (normalise-at-ingest ruling); UCCA-ASSESSMENT-RTOPACKS-BRIEF-01 §4 (D-3 flag)

Correction: the corpus ingest mechanism

One claim in the crossed record is false and is corrected here from a byte-level walk of our infrastructure. The correction narrows nothing the engine is building — your own §4 drift-flag already kept the false detail out of your contract vocabulary, which is the fence working. But the record must be true, and the hash chain re-anchors onto something better than what the fiction offered.

C-1. The false claim and its provenance

"Power BI Excel exports into rtopacks-db" is a fiction. Zero artefact exists — no export path, no Excel ingest, nothing. It entered the record via the withdrawn engine-side draft (UCCA-RTOPACKS-NEEDS-01 §4, dead unfiled), was carried into our brief's D-3 unverified, and propagated through the crossings. A substrate-verification failure on the client side, caught by the client, corrected here. Recorded plainly so neither side builds on it.

C-2. The true mechanism (byte-confirmed)

Corpus ingestion is a TGA REST-API sync: a Cloudflare Worker on a weekend cron calls https://training.gov.au/api, upserts structured rows into our regulated store, and archives the full raw TGA JSON response to R2 — both a current object per component (training/{code}/raw.json) and a dated snapshot per sync (versions/training/{code}/{date}.json).

What stands in D-3, unchanged and load-bearing: - The engine never touches training.gov.au. The supersession of the March design's cache-miss network acquisition stands — acquisition is world-side, scheduled, ours. - The adapter receives corpus from the client's ingestion output. Only the named mechanism changes.

D-3's corrected sentence: "the adapter receives corpus from the client's TGA-API ingestion path (structured store + R2 raw-JSON archive)," not an Excel export. Candidly: this is closer to the March design's spirit than the false "delta" suggested — we do acquire from TGA by API; the correction is that it is a scheduled world-side sync into our store, never an engine-side fetch.

C-3. Q-D3 re-anchored — and strengthened

The hash chain's first link anchored to a file that doesn't exist. The true anchor is better than the fiction:

  1. raw_document_hash = hash over the R2 raw TGA JSON — specifically the dated snapshot (versions/training/{code}/{date}.json) the job drew from. Dated, immutable once written, reproducible: a per-sync raw history the Excel fiction never offered.
  2. normalised_document_hash = hash over the structured extract (the unit's parsed content row plus its qualification packaging context) as at job time.
  3. triumvirate_hash = over the conformed, signed job — unchanged; still the only hash whose preimage crosses the gate.

One honest disclosure your provenance design should absorb: our structured layer is current-state-only (destructive upsert; no dated versioning — that exists only at the raw layer). Therefore the normalised_document_hash recorded in a job's provenance is the durable record of the normalised state at job time — it is not reconstructable from our store later. The dated raw snapshot is reconstructable; the normalised form is attested by its hash. Design the envelope's citations accordingly: cite the dated raw snapshot key + hash, and treat the normalised hash as an attestation, not a pointer. (World-side: dated versioning of the normalised layer is now on our backlog; not a promise the contract should depend on.)

C-4. Two ingest surfaces — do not conflate

The recon confirmed our corpus path already embodies the raw→normalised split our normalise-at-ingest ruling (response Q-R2a) describes — but these are two different ingest surfaces with the same two-hash architecture:

  • Surface 1 — regulator-authored corpus: TGA → API sync → raw R2 + structured store. Feeds generation (R-1). Already built, already two-layered.
  • Surface 2 — client/RTO human-authored material: normalised at the RTOpacks door to the canonical text+images form. Feeds diagnosis (R-2). The canonical-form spec is the future contract surface already reserved.

Same raw_hash → normalised_hash discipline on both; different doors, different directions. Stated so no schema on your side merges them.

C-5. Q-R1a re-scoped (samples follow shortly)

The three samples will be real PITH extracts, not Excel files: per unit, the structured content row + qualification packaging context (including the packaging parse's retained raw input and its confidence flag) + the R2 raw JSON (current and one dated snapshot). Three units: one clean, one middling, one genuinely ugly (HTML table debris in content fields, NULL release numbers, supersession weirdness — the authentic mess). Filenames + hashes follow as the attachments supplement to the response crossing.

Correction complete: one fiction retired from the record, the mechanism stated from bytes, the hash chain re-anchored onto a dated raw archive that is stronger than what the fiction described, one durable-attestation disclosure your provenance design should absorb, and two ingest surfaces named so they never merge. Nothing you are building changes shape; the record is now true.