[HackTuah]

IETF RFC 9943 (SCITT) standardises the class of object Trinity's receipts belong to. This slice says exactly where Trinity sits relative to it, including the part that does not fit, and deliberately does not do the rename the slice was written to do.

The slice reversed itself, and that is the result

It was specified as: rename signed_payload's fields to their RFC 9943, COSE and CWT names, emit under a new scheme, teach the verifier both. Writing AC1's mapping table is what killed it, because building the table meant reading what RFC 9943 actually defines:

SCITT	Issued by	What it asserts
Signed Statement	the Issuer	an identifiable, non-repudiable statement about an artifact
Receipt	a Transparency Service	proof that a Signed Statement is included in a Verifiable Data Structure

A SCITT Receipt MUST carry inclusion proofs. Trinity runs no Transparency Service and issues none. So what Trinity calls a receipt is a Signed Statement, and never a SCITT Receipt.

Renaming the fields to iss, sub, kid and iat would tell every reader who knows those names that this is a SCITT object, and they would then reasonably expect a transparency service, a verifiable data structure and inclusion proofs behind it. That is a conformance claim made by appearance rather than by a row in docs/09-standards-register.md, which is the precise failure that register exists to prevent. The slice's own Scope section had already refused the word "receipt" for exactly that reason, while its acceptance criteria asked for the same claim in field names. The Scope section was right.

Amendment 1 replaced ACs 2, 3 and 4 before any code was written, and the replacements prove the inverse property: that nothing was renamed and no receipt byte changed.

What landed

• docs/receipt-scheme-mapping.md: the terminology collision, the envelope Trinity signs with today (DSSE pre-authentication encoding of trinity/receipt/<scheme>, not COSE), the field by field mapping to COSE, CWT and in-toto, and the three fields with no equivalent (seq, prev_hash, chain_scope) because they are the hash chain SCITT delegates to a service Trinity does not run. The one construct the standard requires and Trinity lacks, CWT iss, gets its own row: that is the more useful half of the answer.
• An RFC 9943 row in the standards register at not claimed.
• A README paragraph saying Trinity issues Signed Statements and never SCITT Receipts, so nobody infers conformance from the house name.
• Five checks that pin the bytes and stop the document rotting.

Nothing under lib/ changed. git diff --stat lib/ is empty.

Two drafting errors, caught against the tree rather than against memory

1. The draft mapped subject_ref to CWT sub and called it the closer match. subject_ref is not signed at all: ChainWriter's body carries subject only, and subject_ref and meta are row columns outside the signature. A mapping document that maps an unsigned column to a signed claim is the exact error it exists to prevent.
2. The draft never said which envelope Trinity signs with, while its own closing argument turns on replacing that envelope with COSE_Sign1.

The census was proved by planting, not by agreeing with today's tree

Plant	Reported as
Table row renamed key_id to issuer_hint	missing key_id, extra issuer_hint
An eleventh signed field policy_id added to ChainWriter, document untouched	caught independently by three checks: key set changed, policy_id unmapped, "document says ten keys, the payload has 11"
Table reformatted by one space, so the parser matches nothing	"a check that silently matches nothing is worse than no check"

The gate was run three times and only the third counted

trinity.names, trinity.reuse and trinity.secrets.scan enumerate tracked files. The first two runs both said 642, the count from before this slice: the new document and test were untracked, so every census passed without looking at them. Staging first took it to 644.

mix gate ; echo "EXIT=$?"
prod_check: PASS
3599 mods/funs, found no issues.
trinity.names: OK over 644 tracked files
trinity.reuse: OK. Every commentable tracked file carries an SPDX header
Result: 821 passed (14 properties, 807 tests), 18 excluded
trinity.coverage: 042 80.31% vs 005 80.31%: OK
EXIT=0

Carried with this slice: a security defect found by accident, opened as slice 125 and not fixed here

Driving the running app to capture README screenshots, the receipts page returned 500 and the log carried:

Logger - error: {removed_failing_filter,trinity_redaction}

That is OTP reporting that the slice 090 credential-masking Logger filter raised and was permanently removed from the handler. Everything logged afterwards is unredacted and nothing says so. The event that did it:

msg: {:string, ["Exqlite.Connection", 32, 40, "#PID<0.815.0> (\"db_conn_1\")",
                ") disconnected: " | "** (DBConnection.ConnectionError) owner ... timed out ..."]}

Note the | before the last element: an improper list, an iolist whose tail is a binary. OTP chardata is routinely improper, and Enum.map/2 raises FunctionClauseError on one. redact_msg({format, args}) when is_list(args) catches {:string, iolist} because an iolist is a list, then walks off the end into the tail.

Three things make it worse than a crash: the trigger is a db_connection disconnect, which is what an ordinary connection blip logs; OTP's removal is permanent and silent; and the module's @moduledoc promises the filter never returns :stop, which is true and beside the point, because a filter that raises is discarded outright. In a long-running deployment the credential mask dies on the first connection wobble and stays dead for the life of the node while every test passes, because the suite only ever feeds it proper lists.

For the reviewer

1. The refusal to rename is the substance of this slice and it reverses the spec. That is the call to confirm.
2. AC5, no date: whether to adopt a COSE_Sign1 envelope with CWT claims in the protected header. That is the change that would be real rather than cosmetic, and it is a scheme bump with a dual-reading verifier behind it.
3. Slice 125's spec is written and ready.