TR-ANC-002 can earn Level 2 without binding receipt root/count to the transparency-named entry

[solloek369-arch]

Lineage: #70 → #79 → caller root/count ↔ transparency-named entry binding

What TR-ANC-002 checks today

At the exact unreleased main snapshots below, TR-ANC-002
replays an inclusion proof against merkle_root and leaf_count supplied in
the caller receipt.

It does not establish that those values belong to the registry entry named by
the transparency URI in the signed record. A receipt can therefore be
internally consistent and still earn Level 2 without that authority relation
having been established.

What the Anchor Format says

The Anchor Format
identifies the registry entry through the record's transparency URI. The
question here is whether a Level-2 verdict must also establish that the caller
receipt's root and count describe that identified entry.

Decisive controls

World	Suite result	Independent paired-entry check
Matching sealed paired entry	✅ Level 2	✅ established
Wrong caller root	❌ refused	—
Only paired-entry root changed	✅ Level 2	❌ not established
Only paired-entry count changed	✅ Level 2	❌ not established

The Merkle check is load-bearing: a wrong caller root is refused. The narrower
gap is that changing only the separately retained paired entry's root or count
leaves the suite at Level 2 while the independent check reports the binding not
established.

Decision requested

Is binding of the caller receipt's merkle_root and leaf_count to the
registry entry named by transparency part of what a Level-2 verdict must
establish?

No upstream API or network-resolution design is proposed here.

Currentness and scope

Currentness checked: 2026-09-02T10:31:53Z — the trace-tests and
trace-spec default branches matched these exact unreleased pins at that time:

• trace-tests: 98c34c7b62f55886ba170609f268645994ba8c1f
• trace-spec: 98aae176aa9ae4053d944624dad7629c76789ff7

Replay if TR-ANC-002 or the Anchor Format entry-binding relation changes.

This does not claim released impact, registry compromise, remote
exploitability, severity, production prevalence, downstream authorization, or
a prescribed upstream API.

Evidence

An unsigned self-verifying local packet, including paired worlds and replay
receipts, is available on request:

d32607ee1f272c8c16f39e44b323e0bd85cd7e897dc3e330a6b5807670318410

[lywinged]

Confirmed at the same pins, independently: trace-tests 98c34c7, trace-spec 98aae176. I built the four worlds from the receipt helpers in tests/test_tr_anc_inclusion.py rather than from the packet, and the table reproduces exactly: a matching entry passes, a wrong caller root fails, and changing only the retained entry's root or count leaves TR-ANC-002 at PASS while the receipt no longer matches the entry.

The reason is structural rather than a missed comparison. check(trace, receipt) has two inputs, and _check_inclusion never uses the transparency value to pick an entry. The value reaches that function only as part of the claim bytes hashed into the leaf, since the Anchor Format anchors the complete signed claim, and the word appears in the function once, inside a failure message. merkle_root and leaf_count come from the receipt and nowhere else. The Anchor Format's own algorithm in section 5.1 has three inputs, the claim, the proof, and the registry entry, and section 6 says a Level 2 verifier MUST be able to retrieve that entry. #79 folded the entry's two fields into the receipt to keep the check offline, and the #70 close said why: the question the fix had to answer was where the receipt comes from, and a new input was the choice that changed nothing about what a record is. So whoever supplies the receipt supplies the entry values, and nothing ties them to the entry the URI names. That is the gap here, and it is a consequence of a decision rather than an oversight.

The decision requested has two halves, and only one is answerable today.

Receipt to entry is answerable and stays offline: an entry input in the shape of the Anchor Format's section 4 registry line, with TR-ANC-002 requiring the receipt's root and count to equal the entry's. The third and fourth rows of the table go red under that and nothing else changes.

URI to entry is not, yet. Section 3.1 of trace-v0.2 calls transparency a SCITT Receipt URI and section 4, Standards Composition, says TRACE defines a SCITT receipt format, but no such format exists in the text; the Anchor Format's batch_id has no stated relation to the URI; and open question 3 in section 7 has not settled whether there is one log or many. Until the URI has a defined shape, no verifier can check which entry it names. Section 3.3 step 6 also says the receipt "resolves on the named transparency log", which is the network verb #79 was written to avoid, so on this point the suite and the text already part ways.

Whichever way the first half is decided, the cheapest honest change is the one #79 already made for TR-ANC-001: have the TR-ANC-002 PASS message state its own boundary, that it replays the proof against the supplied root and not that the root is the entry the URI names. Whether the suite grows a third input is the same kind of decision #79 made, and it belongs to the maintainers rather than to this thread.

Tool-assisted: the runs and this write-up.

[solloek369-arch]

Thanks — your independent replay and separation of receipt→entry from URI→entry made the remaining decision much clearer.

I rechecked the #79 lineage and the current checker (src/trace_tests/modules/tr_anc.py at e93f085). #79 was a real strengthening: before it, Level 2 could pass on URI shape alone; #79 added actual offline inclusion-proof verification. The remaining question is therefore not whether that proof kernel works, but what Level 2 is intended to require beyond it.

Anchor Format §5.1 defines verification over three inputs: the claim, the proof (leaf_index, audit_path), and the registry entry (merkle_root, leaf_count). The current checker instead receives the claim plus one receipt object, and that receipt supplies both the proof and the root/count used to judge it.

Section 6 of the same document separately says that transparency identifies the registry entry and that a Level-2 verifier must be able to retrieve that entry and check inclusion without contacting the record's issuer.

That leaves three distinct relations:

transparency → the independently retrieved registry entry;
receipt root/count ↔ that registry entry;
inclusion proof → those root/count values.

The current checker establishes the third relation, but does not separately establish the first two.

This also seems to be the cleanest way to read the wording boundary. The no-receipt failure path (tr_anc.py lines 48–58) already says that the URI is a pointer rather than evidence, while the PASS path (lines 69–75) establishes inclusion against the supplied root/count. The Level-2 documentation describes the stronger property of durable commitment to an append-only transparency log that can be audited without trusting the agent or operator.

So I think the remaining maintainer decision is one step before API shape:

If Level 2's anchoring guarantee currently intends only pointer shape plus relation 3, should its PASS wording and documented claim be narrowed to those earned properties?
If Level 2 intends all three relations, should the first two become explicit prerequisites before Level 2 can pass?

A receipt↔entry comparison would close only relation 2. It would not by itself establish relation 1 if the entry were merely another caller-supplied object.

No API shape or severity implied — only an attempt to separate the relations that Level 2 is meant to earn.