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

vantage_limitation: a recomputable marker for occurrence vs absence claims on irreversible-class verdicts (implementation evidence, from #279)

Open
  • Is something wrong?
#397 12 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
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
security

Research direction

Start by reading the discussion in #279 and the receipt_gap_disclosed precedent in #260; this issue asks for a design decision, not a scoped implementation. The payload names decision_ref_preimage_fields and the registries data/independent_mediators.json and data/platform_operators_registry.json, but says the derivation function is in a private repo. Done means TRACE decides whether to represent claim type as a first-class marker and, if so, defines its representation and verification expectations.

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). Real implementation evidence first, then the question.

The example (live, no key needed)

POST https://api.babyblueviper.com/verify-proof {"event_id":"c6b4235aa1ee2a64d67224f175a986c6760cd43ad82f52c4da23ac60bd1b5274"} returns valid: true with vantage_limitation_recomputes: true. It is a trade-type verdict under policy_version: invinoveritas.review.v19 (artifact hash only, no artifact content). The relevant signed fields:

artifact_type:       trade
source_class:        agent_reported
vantage_limitation:  "source_class=agent_reported: nothing external confirms this /review call happened, or could not be bypassed, before the action it governs. Recomputability makes this record internally consistent (an occurrence claim) — it is not an absence/completeness claim, which needs a vantage the acting agent doesn't control. ..."

What it is

A disclosure carried on the proof that says what kind of evidence this is: the record is an occurrence claim (this check happened), not an absence/completeness claim (nothing else bypassed it). It exists only for irreversible-class artifacts (trade, onchain_action, sanctions_screening); other types carry null. It is a pure function of two fields that are already inside decision_ref:

vantage_limitation = NOTE[source_class]   if artifact_type in {trade, onchain_action, sanctions_screening}
                     else null
source_class in {agent_reported, platform_operator, independent_mediator}   # three fixed note strings

vantage_limitation itself is in the signed preimage (decision_ref_preimage_fields) since v4, so it cannot be stripped or edited without changing decision_ref.

What a checker can establish

  • The note equals the one derived from (source_class, artifact_type); a proof carrying a different string, or a note on a non-irreversible type, is inconsistent with the signed fields (a mismatch, not a claim about cause).
  • It is bound: removing or changing it changes decision_ref.
  • The recompute needs nothing from us: the function is above and the three exact strings are listed below (the implementation, _compute_vantage_limitation, is in a private repo, so they are reproduced here rather than linked).

What remains unknown

  • Whether the source_class is true. agent_reported is the default and means the calling agent chose to call; independent_mediator is decided by a hand-maintained registry of Bearer keys we curate (data/independent_mediators.json), which a verifier cannot recompute from the proof.
  • Absence: nothing here says the agent did not act without calling. That is exactly what the note says it cannot say.
  • Currency: it does not say the situation still holds now.

The question for TRACE

#260 gave receipt_gap_disclosed a name rather than a generic null. This is the same instinct one step earlier: should a verdict record carry a first-class marker for which kind of claim it is (occurrence vs absence/completeness), rather than leaving readers to infer it? If yes, this is one working shape with a recomputable derivation; if TRACE would rather express it another way (for example as part of the appraisal), I would build to that instead. If it helps, I can add a stdlib checker and negative cases (stripped note, wrong-class note, note on a reversible type) in the same style as the context-provenance example you ran.

The three exact note strings (JSON-escaped, byte-for-byte) 
{
  "agent_reported": "source_class=agent_reported: nothing external confirms this /review call happened, or could not be bypassed, before the action it governs. Recomputability makes this record internally consistent (an occurrence claim) — it is not an absence/completeness claim, which needs a vantage the acting agent doesn't control. Sufficient as standalone evidence for a reversible action; for an irreversible or privileged action, treat this proof as advisory input, not standalone authorization, until paired with an independent mediation-point integration.",
  "platform_operator": "source_class=platform_operator: this /review call was made using a Bearer key registered to the platform that operates/hosts the agent under review, not the agent's own self-report — the reviewed agent cannot bypass this call by calling us directly under its own key, the same custody-separation property independent_mediator has. It is NOT interest-separated the way a genuinely independent mediator is: the platform operator has an ongoing commercial relationship with the agent it hosts and may share its interest in a favorable outcome, unlike a mediator with no stake in the reviewed action. Treat this as stronger than agent_reported and weaker than independent_mediator — registration is a manual, human-verified trust decision on our side, not a cryptographic or on-chain guarantee. See data/platform_operators_registry.json for the registered operator and the evidence checked before registration.",
  "independent_mediator": "source_class=independent_mediator: this /review call was made using a Bearer key registered to a third party verified to be structurally separate from the agent under review (distinct infrastructure, distinct calling identity) — the reviewed agent cannot bypass this call by calling us directly under its own key. This is stronger than agent_reported (a self-report can't fake a different party's credentials), but registration is a manual, human-verified trust decision on our side, not a cryptographic or on-chain guarantee. See data/independent_mediators.json for the registered mediator and the evidence checked before registration."
}
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.