references assumes resolution: the self-validating case, and registering position-commitment

Start with §3.1.2 and §7 open question 3, then read docs/rfcs/a2a-delegation-profile.md §4.3 and the discussion in #226. Work out how the proposed field, verification outcomes, and position-commitment registration fit the v0.3 spec. Done means the spec clearly distinguishes missing proof from a recomputation mismatch and states when the entry and resolver are required.

The gap

§3.1.2 models a reference as a fact held somewhere and fetched. The field table says id is the identifier of the referenced fact held by the resolver, resolver names the party obliged to keep it resolvable, and the unsettled paragraph closes with the sentence that gives the block its shape:

A reference is worth only the ability to resolve it later, and transparency-log practice shows that gap is real rather than theoretical: a record can remain valid and become unreachable when the index that addressed it is removed.

That is true when id is an address. It is false when id is a digest the verifier recomputes from a proof the holder already carries. In that case nothing is fetched, nothing is retained, and no party is obliged to do either. The block has no vocabulary for it, and the two fields that would describe it both say the opposite.

The live case

Michael Argento of Argento Computing Inc. (BitGraph) hit this building a position-commitment profile on TRACE, and has given permission to be named.

His construction: an enclave allocates a slot before the record's digest exists, the slot record is signed by the enclave and travels inside the proof, and the not-before is an external ordered sequence he does not operate. His words, quoted with permission:

The fact is not held anywhere. The slot record is signed by the enclave, carried in the proof, and checked by whoever holds it. There is nothing to resolve because there is nothing anyone keeps. References models facts held elsewhere. This is evidence carried here.

Under the spec as written the correct outcome is rule 4: omit the entry, and that is what his 0.4 package ships. The profile is otherwise assurance-neutral and passes the suite at Level 0.

Omitting it has a measurable cost, which he documents against himself rather than hiding:

The floor now bounds the commit rather than the record, so the profile rejects a backdate by rule, position taken at issuance, rather than by a contradiction inside the record. The version you ran could tell a backdate from a late commit; this one cannot.

That is the property a self-validating form would restore, stated as a capability lost rather than a feature wanted.

What the form has to say

Three requirements, the third split.

1. id is validated by recomputation from evidence the verifier holds, not by resolution, and the recomputation must bind the entry to the record carrying it. Establishing that the referenced object exists is not enough: a self-validating entry is public once its evidence is, so any record could carry it and pass. What binds it is the evidence committing to this record's digest.
2. There is no obliged party, so rule 4 does not apply and resolver carries no undertaking.
3. Two outcomes, kept apart:
   • the verifier cannot recompute because it lacks the proof: the entry is absent, and this is not a finding against the record;
   • the recomputation runs and disagrees: that is a contradiction and must stay one.

The third is the one worth guarding. Collapsing those two is the same defect docs/rfcs/a2a-delegation-profile.md §4.3 exists to prevent on the delegation surface, where a chain that was merely unreadable got reported as tampering. A single sentence covering both is how a verifier ends up reporting tampering as absence.

A field, not a rel

Self-validation is how an entry is checked. A rel names what the entry relates to. Putting the check semantics into a registered relation collapses the two, which is the same category error that put a vendor prefix in rel when resolver already named the producer.

So: one optional field marking any entry self-validating, applicable across relations, rather than a relation whose name secretly changes the verification rule.

Cost, and why this is v0.3

Allowing resolver to be absent breaks no existing record: every record already carries it. It does mint records that a v0.2 verifier rejects, which makes it a version gate rather than a patch, and puts it in v0.3 alongside the normative work already scheduled there.

Worth stating plainly because "backward compatible" usually means existing records keep validating, and that is satisfied here while forward compatibility is not.

Registration: position-commitment

Proposed, in the style of the three registered values:

• position-commitment. A commitment to a position in an externally ordered sequence, taken before the digest of this record exists. id is the commitment to that position, validated by recomputation from a proof the holder carries and that commits this record, rather than by resolution.

The relation is registrable independently of the field. It should be registered knowing that under v0.2 it earns nothing: recomputation is not a check the block defines, rule 3 still governs, the entry remains a pointer, and resolver is still required, so a producer who retains nothing must still omit the entry.

Relationship to #226

#226 gathers four governance requests as one question about which relations get registered values and what a verifier may conclude from each. This is a different axis: not which relation, but whether the block's resolution model is the only one. position-commitment belongs on #226's list; the self-validating field does not, because registering relations does not reach it.

§7 open question 3 is the neighbouring one, and §3.1.2 already says retention and transparency should be resolved together. A third case now sits beside them: a reference that needs no retention at all.