Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

related_claims: carry the claim-vs-referenced-proof comparison result inside the proof? (proposal, from #279)

Open
  • Is something wrong?
#398 11 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
security

Research direction

Start by reading the discussion on #279 and the existing proof_chain_check.py example to understand the current comparison and the unresolved design question. The issue asks whether TRACE should record the comparison result in the proof; implementation is conditional on that decision. If accepted, done means a new policy version records the result and vectors and negative cases cover the listed scenarios.

Written by the indexing model from the issue text.

Description

needs-review:HIGH

Opened at @imran-siddique's invitation on #279 (separate item; opening it does not mean TRACE agrees to add anything). This is a proposal, not shipped: the accepted context-provenance example shows where the gap is, this asks whether TRACE wants it closed inside the proof.

The example that exists today

Outer event 303c3d928a60ee55d15f33cf66d5b75f6e3434c6dc4e1775a12c017cfc4d6a31 references inner event 7aa10c9783ef2e96d33d8edb383583d126b6240589f824b39933600e79587002 through related_decision_ref (in the signed preimage). The caller's context is a fixed-grammar sentence in disclosed_summary restating the inner proof's artifact_hash, verdict, verified_at, policy_version, decision_ref and event id. A stdlib checker (proof_chain_check.py, 10 checks, 24 negative cases; you ran it at 2883f1b) parses each named field and compares exact values. Anything outside the grammar is CANNOT_ESTABLISH.

The gap that example leaves

The comparison lives in the verifier's script. The server verified the referenced proof and bound related_decision_ref, but it did not itself check the caller's claim against that proof, and the check result is not in the proof. So the proof cannot say "the claim matched" by itself, and a verifier that skips the script gets the reference without the comparison.

Proposal

A caller-supplied related_claims object ({artifact_hash, verdict, verified_at, policy_version, decision_ref}), compared by the server against the referenced proof it already re-verifies, with the result (matched | mismatched | not_supplied) bound into the preimage next to related_decision_ref. It is a policy-version change (new field list entry, registered per version), and a mismatch never upgrades context_provenance.

What a checker could establish

  • Exact equality of the named fields between the claim and the referenced proof, recomputed offline from the two events (the script above, unchanged), plus that the recorded result equals what that comparison gives.
  • That a claim which does not match is recorded as mismatched, not dropped.

What would remain unknown (stated so it is not oversold)

  • That the referenced verdict supports the action or the text of this call. Equality of restated fields says the restatement is faithful, not that it is relevant or sufficient. You made this point on the thread and it is not addressed by this proposal.
  • Anything about the referenced proof's own truth beyond its signature and decision_ref.
  • Retention: the referenced proof must still be obtainable; our store lost its events on 2026-09-20 (cause and fix on #279), which is why examples live in the repo and not only on the API.

Ask

Does TRACE want the comparison result carried inside the proof, or is a verifier-side script the right place for it? If inside, I will implement it behind a new policy version with vectors and negative cases (changed field, swapped slots, claim omitted, mismatch must not upgrade the label) before anyone is asked to rely on it. If not, I will leave the script as the reference and not add the field.

Dominant language
Python
Stars
37
Forks
33
Avg merge
1d 4h
Merged PRs (30d)
122

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from agentrust-io/trace-spec

All issues in agentrust-io/trace-spec

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.