Prior-art survey · surveyed 2026-09-01

61 records, six accountability fields, one question

Does any existing system bind all six accountability fields inside a signed record?

No. 0 of 61. The nearest binds five and routes the sixth to litigation.

All 366 cells below carry a quotation and the URL it was read from — including the ABSENT ones, where the note records what was searched and not found. Nothing that could not be confirmed from a fetched primary source is asserted: those cells say UNVERIFIED. Download the dataset (JSON).

61records surveyed
366verdict cells (61 × 6)
366cells with quote + source URL
158verdicts of INSIDE or OUTSIDE
9unverified, recorded as such
0bind all six inside
0bind challenge inside

The six fields

These six are what a verdict record binds alongside its verdict. The verdict itself is not one of them.

idfieldthe question it answers
F1AgentWhich AI or automated party made the call
F2AuthorityWhat it was allowed to decide — granted scope, delegation
F3Rubric versionWhich version of the governing rules was applied
F4EvidenceDigests of the inputs read
F5ApproverWhich human signed off on release
F6ChallengeWho disputed the record and the reply, as a lifecycle state of that record

What a verdict means

INSIDE Present, required (MUST), and covered by the signature or canonical hash. Mutating it breaks verification.
OUTSIDE Present but OPTIONAL, SHOULD-level, outside the canonical hash, application-layer, or non-normative.
ABSENT No such field.
N/A Outside the system's stated scope.
UNVERIFIED Could not be confirmed from a fetched primary source. Recorded, not guessed.

The result

Ranked by how many of the six each record binds inside its signature.

Challenge (F6) is INSIDE in 0 of 61. Issuer-side revocation, by contrast, is shipped and often shipped well.

The nearest system, Agentic Witnessing, binds five of six. Its sixth is absent by design, not by oversight: it routes dispute to litigation, “for example in a court of law”.

Two near misses are worth knowing before citing this:

  • MLflow 3 — Has built the shape of a challenge field — overrides, valid, disputing party and rationale — but unsigned and mutable in its database.
  • ReScience C — Publishes dissent as a first-class outcome, but as a separate article about a different record.

“Nobody records challenges” is false. “Nobody binds them” is true.

record F1F2F3F4F5F6 inside
Agentic Witnessing (arXiv:2604.24203) · lane 4 INSIDE INSIDE INSIDE INSIDE INSIDE ABSENT 5/6
AERF — Agent Evidence Receipt Format · lane 2 INSIDE INSIDE OUTSIDE INSIDE ABSENT ABSENT 3/6
C2PA Technical Specification · lane 1 INSIDE OUTSIDE OUTSIDE INSIDE OUTSIDE ABSENT 2/6
EU AI Act Art.12 — systima aiact-audit-log · lane 2 INSIDE ABSENT ABSENT INSIDE OUTSIDE ABSENT 2/6
Sigstore Rekor · lane 2 INSIDE ABSENT ABSENT INSIDE ABSENT ABSENT 2/6
Sigsum · lane 2 INSIDE ABSENT ABSENT INSIDE ABSENT ABSENT 2/6
Microsoft Entra Agent ID · lane 3 INSIDE INSIDE ABSENT ABSENT OUTSIDE ABSENT 2/6
UCAN · lane 3 INSIDE INSIDE ABSENT ABSENT ABSENT ABSENT 2/6
ZCAP-LD · lane 3 INSIDE INSIDE ABSENT ABSENT ABSENT ABSENT 2/6
SLSA Verification Summary Attestation (VSA) · lane 1 INSIDE ABSENT OUTSIDE OUTSIDE ABSENT ABSENT 1/6
W3C VC Data Integrity · lane 1 OUTSIDE INSIDE ABSENT ABSENT ABSENT ABSENT 1/6
W3C Verifiable Credentials Data Model · lane 1 INSIDE OUTSIDE OUTSIDE OUTSIDE ABSENT ABSENT 1/6
EU AI Act Art.12 — ai-decision-logging-spec · lane 2 INSIDE ABSENT OUTSIDE OUTSIDE OUTSIDE ABSENT 1/6
Go checksum database (sumdb) · lane 2 ABSENT ABSENT ABSENT INSIDE ABSENT ABSENT 1/6
RFC 9162 Certificate Transparency v2 · lane 2 INSIDE OUTSIDE OUTSIDE OUTSIDE ABSENT ABSENT 1/6
RFC 9943 SCITT · lane 2 INSIDE ABSENT OUTSIDE N/A ABSENT ABSENT 1/6
TUF (The Update Framework) · lane 2 OUTSIDE INSIDE ABSENT ABSENT OUTSIDE ABSENT 1/6
Biscuit · lane 3 ABSENT INSIDE ABSENT ABSENT ABSENT ABSENT 1/6
IETF SPICE SD-CWT · lane 3 INSIDE ABSENT ABSENT ABSENT ABSENT ABSENT 1/6
IETF WIMSE workload-creds · lane 3 INSIDE ABSENT ABSENT ABSENT ABSENT ABSENT 1/6
Macaroons · lane 3 ABSENT INSIDE ABSENT ABSENT OUTSIDE ABSENT 1/6
SPIFFE/SPIRE SVID · lane 3 INSIDE OUTSIDE ABSENT ABSENT ABSENT ABSENT 1/6
Microsoft Agent Governance Toolkit — AUDIT-COMPLIANCE-1.0 · lane 4 INSIDE OUTSIDE OUTSIDE OUTSIDE OUTSIDE ABSENT 1/6
CycloneDX Attestations (CDXA) · lane 1 OUTSIDE OUTSIDE OUTSIDE OUTSIDE OUTSIDE OUTSIDE 0/6
Grafeas · lane 1 OUTSIDE OUTSIDE ABSENT OUTSIDE ABSENT ABSENT 0/6
OpenSSF Scorecard / scorecard-attestor · lane 1 ABSENT ABSENT ABSENT ABSENT ABSENT ABSENT 0/6
RO-Crate + Workflow Run RO-Crate · lane 1 OUTSIDE ABSENT OUTSIDE OUTSIDE ABSENT ABSENT 0/6
SPDX Build profile · lane 1 OUTSIDE OUTSIDE OUTSIDE OUTSIDE ABSENT ABSENT 0/6
Sigstore bundle format · lane 1 OUTSIDE ABSENT OUTSIDE N/A ABSENT ABSENT 0/6
W3C PROV-O / PROV-DM · lane 1 OUTSIDE OUTSIDE OUTSIDE OUTSIDE ABSENT ABSENT 0/6
in-toto Attestation Framework (Statement) + DSSE · lane 1 OUTSIDE ABSENT ABSENT ABSENT ABSENT ABSENT 0/6
KEYTRANS (IETF) · lane 2 OUTSIDE ABSENT OUTSIDE N/A ABSENT ABSENT 0/6
Notary Project / Notation · lane 2 OUTSIDE OUTSIDE OUTSIDE ABSENT ABSENT ABSENT 0/6
OpenTimestamps · lane 2 N/A N/A N/A N/A N/A N/A 0/6
Trillian · lane 2 N/A N/A N/A N/A N/A N/A 0/6
GNAP · lane 3 OUTSIDE OUTSIDE ABSENT ABSENT OUTSIDE ABSENT 0/6
MCP Authorization · lane 3 ABSENT OUTSIDE ABSENT ABSENT ABSENT ABSENT 0/6
OAuth 2.0 RAR · lane 3 ABSENT OUTSIDE ABSENT ABSENT ABSENT ABSENT 0/6
W3C DID Core · lane 3 OUTSIDE ABSENT ABSENT ABSENT ABSENT ABSENT 0/6
AI Verify (Singapore IMDA / AI Verify Foundation) · lane 4 OUTSIDE ABSENT OUTSIDE OUTSIDE OUTSIDE ABSENT 0/6
Arize Phoenix / OpenInference semantic conventions · lane 4 OUTSIDE ABSENT OUTSIDE OUTSIDE OUTSIDE ABSENT 0/6
ISO/IEC 42001:2023 · lane 4 UNVERIFIED UNVERIFIED UNVERIFIED UNVERIFIED UNVERIFIED UNVERIFIED 0/6
LangSmith run / feedback schema · lane 4 OUTSIDE ABSENT OUTSIDE OUTSIDE OUTSIDE OUTSIDE 0/6
MLflow 3 GenAI assessments · lane 4 OUTSIDE ABSENT ABSENT OUTSIDE OUTSIDE OUTSIDE 0/6
NIST AI RMF 1.0 (AI 100-1) + NIST AI 600-1 · lane 4 N/A N/A N/A N/A N/A N/A 0/6
NVIDIA NeMo Guardrails logging · lane 4 OUTSIDE ABSENT ABSENT OUTSIDE ABSENT ABSENT 0/6
Open Policy Agent decision logs · lane 4 OUTSIDE ABSENT OUTSIDE OUTSIDE ABSENT ABSENT 0/6
OpenTelemetry GenAI semantic conventions · lane 4 OUTSIDE ABSENT ABSENT OUTSIDE ABSENT ABSENT 0/6
Weights & Biases Weave · lane 4 OUTSIDE ABSENT OUTSIDE OUTSIDE OUTSIDE ABSENT 0/6
ACM Artifact Review and Badging · lane 5 ABSENT OUTSIDE OUTSIDE OUTSIDE OUTSIDE ABSENT 0/6
CODECHECK · lane 5 ABSENT OUTSIDE OUTSIDE OUTSIDE OUTSIDE ABSENT 0/6
CORE-Bench · lane 5 OUTSIDE N/A UNVERIFIED UNVERIFIED N/A N/A 0/6
COS Open Practices Badges · lane 5 ABSENT OUTSIDE OUTSIDE OUTSIDE OUTSIDE OUTSIDE 0/6
Code Ocean (substitute for eLife RDS) · lane 5 ABSENT ABSENT ABSENT ABSENT OUTSIDE ABSENT 0/6
EU AI Act Article 12 · lane 5 ABSENT ABSENT ABSENT OUTSIDE OUTSIDE ABSENT 0/6
FAIRsoft / OpenEBench · lane 5 OUTSIDE ABSENT UNVERIFIED ABSENT ABSENT ABSENT 0/6
NISO RP-31-2021 · lane 5 ABSENT OUTSIDE OUTSIDE OUTSIDE OUTSIDE OUTSIDE 0/6
Open Badges 3.0 (1EdTech) · lane 5 ABSENT ABSENT OUTSIDE OUTSIDE ABSENT OUTSIDE 0/6
ReScience C · lane 5 ABSENT OUTSIDE ABSENT OUTSIDE OUTSIDE OUTSIDE 0/6
W3C Bitstring Status List · lane 5 N/A N/A N/A N/A N/A OUTSIDE 0/6
Zenodo / DataCite · lane 5 ABSENT ABSENT ABSENT OUTSIDE ABSENT OUTSIDE 0/6

Every verdict, with its quotation and source

61 records. Open one to read the quoted text each verdict rests on and the URL it was fetched from on 2026-09-01.

5/6 Agentic Witnessing (arXiv:2604.24203) v1, 27 Apr 2026 · lane 4, Agent governance toolkits

https://arxiv.org/abs/2604.24203

INSIDE F1 Agent
"This quote binds the H of the Auditor container's initial memory state (MRENCLAVE – e.g. the docker container) and the Auditor's public key PK_A_Aud to the hardware manufacturer's root of trust" — formalised as Quote_A_Aud = Sign_SK_HW(M_A_Aud ∥ PK_A_Aud ∥ T_p ∥ IPAddr_A_Aud)

https://arxiv.org/html/2604.24203v1

INSIDE F2 Authority
"The protocol initiates with the Prover generating a signed ticket (T_p) containing:" … "K_max: The upper bound on the number of Verifier questions in this session (e.g. K_max = 40)" … "N_queries: A limit on the number of MCP-calls the Auditor can make to the Prover for a single question" — formalised as T_p = Sign_SK_A_Prv(N_v ∥ timestamp ∥ K_max ∥ N_queries ∥ PK_A_Prv)

https://arxiv.org/html/2604.24203v1

INSIDE F3 Rubric version
Γ_pub = Sign_SK_A_Aud(σ_A_Prv ∥ Q) — the audited question Q is inside the final signature; and the judging rules themselves are inside the attested enclave image: "It had all the Auditor codebase and prompts, and the on-disk image size is 86.3 MB", measured as MRENCLAVE and bound by Quote_A_Aud

https://arxiv.org/html/2604.24203v1

INSIDE F4 Evidence
"Transcript Binding: The hash h_file is included in the tool result a_i that updates the global transcript hash chain H_k. This cryptographically binds the specific version of the file viewed by the Auditor to the final attestation Γ." — seeded by "the Prover calculates the H of each file in the corpus… The Prover then takes the H(F_map), which we refer to as the corpus hash (H_corpus)… (H_corpus) is used by both A_Prv and A_Aud as the first entry in a transcript hash chain."

https://arxiv.org/html/2604.24203v1

INSIDE F5 Approver
"A_Prv creates σ_A_Prv to acknowledge \"I showed this evidence and accept the Auditor came to this conclusion\" and sends it to the A_Aud" — and release is gated on it: "To receive the final attestation Γ_pub, the Prover must countersign this final hash (σ_P = Sign_SK_P(H_k))"

https://arxiv.org/html/2604.24203v1

ABSENT F6 Challenge
Searched the full converted text for challenge, dispute, appeal, contest, rebut, revoke, arbitrat. The only challenge hits are the word used in its ordinary sense ("This challenge spans multiple domains", "three fundamental systems challenges"). No dispute state exists in the record's lifecycle.

https://arxiv.org/html/2604.24203v1

3/6 AERF — Agent Evidence Receipt Format v0.2.0-draft.1 (May 2026, Apache-2.0) · lane 2, Transparency logs and registries

https://github.com/aerf-spec/aerf

INSIDE F1 Agent
§4.2 Required fields: "| agent | string (≤256) | Asserted identity of the acting agent. |"

https://github.com/aerf-spec/aerf/blob/main/SPEC.md

INSIDE F2 Authority
§4.2 Required fields: "| plan_id | string | Identifier of the plan receipt this evidence references. |" — where §2 defines: "Plan. A signed envelope that defines the scope of allowed actions for an agent or set of agents over a bounded period."

https://github.com/aerf-spec/aerf/blob/main/SPEC.md

OUTSIDE F3 Rubric version
§4.3 Optional fields: "| policy_hash | string | SHA-256 hex of canonical {scope, checkpoints, delegates_to} of the plan. REQUIRED when pdp_signature is present. |"

https://github.com/aerf-spec/aerf/blob/main/SPEC.md

INSIDE F4 Evidence
§4.2 Required fields: "| evidence_hash_<alg> | string | Digest of the canonical JSON of evidence. The <alg> suffix declares the algorithm (locked decision C-3). v0.2: evidence_hash_sha512. |" — plus §4.6 context_hash_sha256: "SHA-256 hex digest of the canonical JSON … of the input context the agent observed. REQUIRED when pdp_signature is present"

https://github.com/aerf-spec/aerf/blob/main/SPEC.md

ABSENT F5 Approver
Searched SPEC.md for human, approv, sign-off, escalat. Three hits, none an approver field: policy_reason ("Human-readable explanation"), session_escalation ("Escalation marker emitted by the session policy"), and a §13 note on governance escalation. The nearest structure is parent_signature, which is a parent agent's countersignature, not a human's.

https://github.com/aerf-spec/aerf/blob/main/SPEC.md

ABSENT F6 Challenge
Searched SPEC.md for dispute, challeng, revok, contest. Zero hits. §12.3 covers key compromise and §12.4 malicious issuers, both as threat-model discussion, with no record-lifecycle state for a disputed receipt.

https://github.com/aerf-spec/aerf/blob/main/SPEC.md

2/6 C2PA Technical Specification 2.4 · lane 1, Provenance and attestation formats

https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html

INSIDE F1 Agent
"Detailed information about the claim generator shall be present as the value of claim_generator_info." and "The data in this object shall represent the non-human (hardware or software) actor that actually generated the claim (aka the claim generator itself)."

https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html

OUTSIDE F2 Authority
The scope check is the certificate EKU — "A validator shall ensure a signing certificate is authorized for the purpose for which it is being used, and reject certificates used for an unauthorized purpose." — but the credential carrying it need not be signed: "Validators shall accept the header from either the protected or unprotected bucket, to maintain compatibility with previous versions of this specification."

https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html

OUTSIDE F3 Rubric version
"A specVersion field should be present, and if so, shall contain a SemVer formatted specVersion field representing the version of this specification used as the normative reference by the Claim Generator to create this C2PA Manifest (e.g., "2.4.0" for version 2.4). Validators should treat this field as purely informational and should not change their validation logic based on this value."

https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html

INSIDE F4 Evidence
"The created_assertions field shall be present and it shall contain one or more URI references to assertions being made by this claim. In a standard manifest, it shall contain, at minimum, a reference to an assertion that represents a hard binding." and "All C2PA Manifests shall contain an assertion store with at least one assertion, a claim and a claim signature."

https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html

OUTSIDE F5 Approver
humanOversightLevel, inside the optional contentProfile of the optional c2pa.ai-disclosure assertion: "; \"human_validated\" -> human reviewed/approved final output prior to release (reduced automated scrutiny when attested)"

https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html

ABSENT F6 Challenge
(no field) — searched the full 2.4 specification text for dispute / challenge / contest / rebut. The only hit is prose in the introduction ("extraordinary challenges to trust in media"). Redaction and OCSP revocation exist but govern content removal and credential status, not a dispute recorded against the record.

https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html

2/6 EU AI Act Art.12 — systima aiact-audit-log schemaVersion v1 (2026-02-28, MIT) · lane 2, Transparency logs and registries

https://github.com/systima-ai/aiact-audit-log

INSIDE F1 Agent
Required-fields table: "| systemId | string | 12(1) system identification |" and "| modelId | string or null | 12(2)(a), 72 model version tracking |". In source: systemId: string and modelId: string | null on interface AuditLogEntry.

https://github.com/systima-ai/aiact-audit-log/blob/main/src/schema.ts

ABSENT F2 Authority
Searched README.md schema table and src/schema.ts. No authority, scope, delegation, or permission field on AuditLogEntry or AuditLogEntryExtended.

https://github.com/systima-ai/aiact-audit-log/blob/main/src/schema.ts

ABSENT F3 Rubric version
Searched the same two files. schemaVersion: 'v1' is annotated "Forward compatibility" — it versions the log format. parameters: Record<string, unknown> | null holds runtime config without identifying a policy. No governing-rules version field exists.

https://github.com/systima-ai/aiact-audit-log/blob/main/src/schema.ts

INSIDE F4 Evidence
Required-fields table: "| input | { type, value } | 12(2)(a), 12(2)(c), 12(3)(c) |", with hashing available: "For systems processing personal data, enable pii.hashInputs and pii.hashOutputs to store SHA-256 hashes instead of raw content".

https://github.com/systima-ai/aiact-audit-log/blob/main/README.md

OUTSIDE F5 Approver
Optional extended field: "Extended fields (optional): humanIntervention, stepIndex, parentEntryId, toolCall, referenceDatabase, matchResult, metadata." In source, humanIntervention?: HumanIntervention — optional, carrying type, userId: string, reason?, originalOutput?, timestamp.

https://github.com/systima-ai/aiact-audit-log/blob/main/src/schema.ts

ABSENT F6 Challenge
Searched README.md and src/schema.ts. EventType is inference, tool_call, tool_result, human_intervention, system_event, session_start, session_end — no dispute or challenge event, and no lifecycle state on an entry.

https://github.com/systima-ai/aiact-audit-log/blob/main/src/schema.ts

2/6 Sigstore Rekor hashedrekord v0.0.1, main @ 2026-08-31 · lane 2, Transparency logs and registries

https://raw.githubusercontent.com/sigstore/rekor/main/pkg/types/hashedrekord/v0.0.1/hashedrekord_v0_0_1_schema.json

INSIDE F1 Agent
Schema: "publicKey" — "The public key that can verify the signature; this can also be an X509 code signing certificate that contains the raw public key information". Enforced in validate(): return nil, nil, &types.InputValidationError{Err: errors.New("missing public key")} and copied into the canonical entry: canonicalEntry.Signature.PublicKey.Content, err = keyObj.CanonicalValue()

https://raw.githubusercontent.com/sigstore/rekor/main/pkg/types/hashedrekord/v0.0.1/hashedrekord_v0_0_1_schema.json

ABSENT F2 Authority
Searched hashedrekord_v0_0_1_schema.json (whose required is exactly [ "signature", "data" ]) and entry.go. No field expresses granted scope or delegation.

https://raw.githubusercontent.com/sigstore/rekor/main/pkg/types/hashedrekord/v0.0.1/hashedrekord_v0_0_1_schema.json

ABSENT F3 Rubric version
Searched the same two files. apiVersion is present in the canonical bytes (APIVERSION = "0.0.1") but it versions the *entry-type schema*, not any governing rule. No policy or rubric field exists.

https://raw.githubusercontent.com/sigstore/rekor/main/pkg/types/hashedrekord/v0.0.1/entry.go

INSIDE F4 Evidence
Schema: "hash" — "Specifies the hash algorithm and value for the content", with "required": [ "algorithm", "value" ], and in the canonicalizer canonicalEntry.Data.Hash = v.HashedRekordObj.Data.Hash while "data content is not set deliberately".

https://raw.githubusercontent.com/sigstore/rekor/main/pkg/types/hashedrekord/v0.0.1/entry.go

ABSENT F5 Approver
Searched the hashedrekord schema and entry.go. No approver field.

https://raw.githubusercontent.com/sigstore/rekor/main/pkg/types/hashedrekord/v0.0.1/hashedrekord_v0_0_1_schema.json

ABSENT F6 Challenge
Structurally excluded by design: "Auditors can monitor the log for consistency, meaning that the log remains append-only and entries are never mutated or removed."

https://docs.sigstore.dev/logging/overview/

2/6 Sigsum Log Server Protocol, stable v1 · lane 2, Transparency logs and registries

https://git.glasklar.is/sigsum/project/documentation/-/raw/main/log.md

INSIDE F1 Agent
"key_hash is a hash of the submitter's public key. It is included in tree_leaf so that each leaf can be attributed to its own submitter." (§2.2.4)

https://git.glasklar.is/sigsum/project/documentation/-/raw/main/log.md

ABSENT F2 Authority
Searched log.md. The leaf format is closed: "resulting in exactly 128 bytes. No other leaf types are supported." (§2.2.4) There is no slot for scope.

https://git.glasklar.is/sigsum/project/documentation/-/raw/main/log.md

ABSENT F3 Rubric version
Same closed-format clause. Policy exists but lives entirely on the verifier's side, never in the record: "A verifier receives a data item together with a proof of logging … and verifies, offline, that the proof is valid and complies with the verifier's policy. This policy defines known logs and which witnesses to be depended on for security." (§1.2)

https://git.glasklar.is/sigsum/project/documentation/-/raw/main/log.md

INSIDE F4 Evidence
"checksum is the hash of a message submitted to the log. This message is meant to represent some data. It is recommended that the submitter uses H(data) as the message, in which case checksum is H(H(data)). Logs must reject messages that are not exactly 32 bytes" (§2.2.4)

https://git.glasklar.is/sigsum/project/documentation/-/raw/main/log.md

ABSENT F5 Approver
Searched log.md. Witnesses cosign *tree heads*, not individual leaves, and attest only consistency: "witnesses certify that each later tree head that they cosign includes everything that was contained by the tree heads signed previously." (§1.2) That is not approval of a record's content.

https://git.glasklar.is/sigsum/project/documentation/-/raw/main/log.md

ABSENT F6 Challenge
Searched log.md. The design goal is that a bad entry *stays* visible rather than being challengeable: "as long as a sufficient number of witnesses are not compromised, the unauthorized signature stays in the public record and is thus detectable by monitors." (§1.1)

https://git.glasklar.is/sigsum/project/documentation/-/raw/main/log.md

2/6 Microsoft Entra Agent ID GA docs, agent-identities updated 2026-06-15; token claims updated 2026-08-27 · lane 3, Agent identity and delegation

https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/agent-token-claims

INSIDE F1 Agent
Token claims table: "azp or appid | Authorized party / actor. The application ID of the agent identity. Enables proper client attribution in audit logs." Overview: "Request agent tokens from Microsoft Entra ID. The subject of the access token is the agent identity." Facets: "The xms_sub_fct and xms_act_fct claims are used to describe facts about the subject (sub) and the actor (azp or appid) of the token, respectively."

https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/agent-token-claims
https://learn.microsoft.com/en-us/entra/agent-id/agent-identities

INSIDE F2 Authority
Token claims table: "scp | Scope. Delegated permissions for user-context tokens. Only present in user delegation and agent's user account scenarios. Empty or / for app-only scenarios". Autonomous-agent scenario table: "roles | Permissions granted to the agent identity".

https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/agent-token-claims

ABSENT F3 Rubric version
— searched the full claims reference table, the three scenario tables and the agent-identities anatomy list: no policy or rubric version claim

https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/agent-token-claims

ABSENT F4 Evidence
— searched the same tables; no input-digest claim

https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/agent-token-claims

OUTSIDE F5 Approver
Anatomy of an agent identity: "Sponsor. Agent identities can have a sponsor, which records the human user or group that's accountable for an agent. This sponsor is used for various purposes, such as contacting a human in case a security incident happens." Governance overview: "Sponsors can be assigned to agent identities after creation. Sponsors of agent identities are human users accountable for making decisions about its lifecycle and access." No sponsor claim appears anywhere in the token claims reference.

https://learn.microsoft.com/en-us/entra/agent-id/agent-identities
https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview
https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/agent-token-claims

ABSENT F6 Challenge
— searched the claims reference and the governance overview; access reviews and expiry notifications exist as directory workflows, but there is no dispute-and-response state attached to any issued record

https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview

2/6 UCAN Delegation 1.0.0 / spec 1.0.0 · lane 3, Agent identity and delegation

https://github.com/ucan-wg/delegation

INSIDE F1 Agent
Delegation payload table, iss, Required: "Issuer DID (sender). All DIDs are represented as string URLs." Spec README: "Every UCAN MUST be signed with the private key associated with the DID in the iss field." Envelope table: .0 = "A signature by the Payload's iss over the SigPayload field"; .1 = "The content that was signed".

https://raw.githubusercontent.com/ucan-wg/delegation/main/README.md
https://raw.githubusercontent.com/ucan-wg/spec/main/README.md

INSIDE F2 Authority
Delegation payload table, both Required: cmd — "The Command to eventually invoke"; pol — "Policy". Also Required: sub — "Principal that the chain is about (the Subject)". These sit in the Payload, and the signature is taken over the SigPayload.

https://raw.githubusercontent.com/ucan-wg/delegation/main/README.md

ABSENT F3 Rubric version
— searched the Delegation 1.0.0 payload field table and the spec README; no rubric/policy-version field. pol carries the policy *content*, not a version identifier for an external governing ruleset

https://raw.githubusercontent.com/ucan-wg/delegation/main/README.md

ABSENT F4 Evidence
— searched the Delegation 1.0.0 payload field table; no input-digest field

https://raw.githubusercontent.com/ucan-wg/delegation/main/README.md

ABSENT F5 Approver
— searched the Delegation 1.0.0 payload field table; no human-approver field

https://raw.githubusercontent.com/ucan-wg/delegation/main/README.md

ABSENT F6 Challenge
— searched the Delegation 1.0.0 payload table and the spec README lifecycle list. Revocation exists but is a different thing: "[Revocation] Undo a delegation, breaking a delegation chain for malicious users." A revocation cancels the record; it is not a dispute-and-response state *within* the record's lifecycle

https://raw.githubusercontent.com/ucan-wg/spec/main/README.md

2/6 ZCAP-LD Authorization Capabilities v0.4.0-draft · lane 3, Agent identity and delegation

https://w3c-ccg.github.io/zcap-spec/v0.4.0-draft/

INSIDE F1 Agent
"A delegated zcap MUST have a controller that is a string or an array of strings that each express a URI that identifies a controller for the delegated zcap." "A delegated zcap MUST have a proof field that is an object or an array of objects that each express a DI proof. At least one of these proofs MUST be a zcap capability delegation proof."

https://w3c-ccg.github.io/zcap-spec/v0.4.0-draft/

INSIDE F2 Authority
"A delegated zcap MUST have a parentCapability that is a string that expresses the ID of the parent zcap." "A root zcap MUST have an invocationTarget that is a string that expresses a URI."

https://w3c-ccg.github.io/zcap-spec/v0.4.0-draft/

ABSENT F3 Rubric version
— searched the v0.4.0-draft Delegated Capability and Root Capability sections; no policy version field

https://w3c-ccg.github.io/zcap-spec/v0.4.0-draft/

ABSENT F4 Evidence
— searched the same sections; no input-digest field

https://w3c-ccg.github.io/zcap-spec/v0.4.0-draft/

ABSENT F5 Approver
— searched the same sections; no human-approver field distinct from the delegating controller

https://w3c-ccg.github.io/zcap-spec/v0.4.0-draft/

ABSENT F6 Challenge
— searched the same sections; no dispute/challenge lifecycle state

https://w3c-ccg.github.io/zcap-spec/v0.4.0-draft/

1/6 SLSA Verification Summary Attestation (VSA) predicate v1 / SLSA spec v1.2 (Approved) · lane 1, Provenance and attestation formats

https://slsa.dev/spec/v1.2/verification_summary

INSIDE F1 Agent
"verifier _object, required_ … Identifies the entity that performed the verification." and "The field is required, even if it is implicit from the signer, to aid readability and debugging."

https://slsa.dev/spec/v1.2/verification_summary

ABSENT F2 Authority
(no field) — the complete Fields list is verifier, timeVerified, resourceUri, policy, inputAttestations, verificationResult, verifiedLevels, dependencyLevels, slsaVersion. Authority is pushed out-of-band: "Consumers MUST accept only specific (signer, verifier) pairs."

https://slsa.dev/spec/v1.2/verification_summary

OUTSIDE F3 Rubric version
"The entry MUST contain a uri identifying which policy was applied and SHOULD contain a digest to indicate the exact version of that policy." and "slsaVersion _string, optional_"

https://slsa.dev/spec/v1.2/verification_summary

OUTSIDE F4 Evidence
"inputAttestations _array (ResourceDescriptor), optional_ … This field MAY be absent if the verifier does not support this feature."

https://slsa.dev/spec/v1.2/verification_summary

ABSENT F5 Approver
(no field) — searched the full Fields section of the v1.2 VSA page; no human sign-off, countersignature, or release-approval property.

https://slsa.dev/spec/v1.2/verification_summary

ABSENT F6 Challenge
(no field) — same document; the record has no dispute state. The only lifecycle value is verificationResult: "Either 'PASSED' or 'FAILED' to indicate if the artifact passed or failed the policy verification."

https://slsa.dev/spec/v1.2/verification_summary

1/6 W3C VC Data Integrity 1.0 (Rec 15 May 2025) · lane 1, Provenance and attestation formats

https://www.w3.org/TR/vc-data-integrity/

OUTSIDE F1 Agent
"A verification method is the means and information needed to verify the proof. If included, the value MUST be a string that maps to a [URL]. Inclusion of verificationMethod is OPTIONAL, but if it is not included, other properties such as cryptosuite might provide a mechanism by which to obtain the information necessary to verify the proof."

https://www.w3.org/TR/vc-data-integrity/

INSIDE F2 Authority
"The reason the proof was created MUST be specified as a string that maps to a URL. The proof purpose acts as a safeguard to prevent the proof from being misused by being applied to a purpose other than the one that was intended." Coverage confirmed: "Let proofConfig be a clone of the options object." → "Let proofConfigHash be the result of applying the SHA-256 … cryptographic hashing algorithm to the canonicalProofConfig."

https://www.w3.org/TR/vc-data-integrity/
https://www.w3.org/TR/vc-di-eddsa/

ABSENT F3 Rubric version
(no field) — searched vc-data-integrity; the proof's version-shaped properties are type and cryptosuite, which name the signature algorithm: "If the proof type is DataIntegrityProof, cryptosuite MUST be specified". No governing-rules version.

https://www.w3.org/TR/vc-data-integrity/

ABSENT F4 Evidence
(no field) — searched vc-data-integrity; the proof object carries only proof metadata. Inputs read belong to the credential body (row 4).

https://www.w3.org/TR/vc-data-integrity/

ABSENT F5 Approver
(no field) — proof sets and proof chains exist but assign no roles; searched vc-data-integrity for an approver / sign-off role property.

https://www.w3.org/TR/vc-data-integrity/

ABSENT F6 Challenge
(no field) — the challenge property in this spec is a replay nonce, not a dispute: "An optional string challenge, used by the verifier to ensure that an attacker is not replaying previously created proofs" and "The value is used once for a particular domain and window of time. This value is used to mitigate replay attacks."

https://www.w3.org/TR/vc-data-integrity/

1/6 W3C Verifiable Credentials Data Model 2.0 (Rec 15 May 2025) · lane 1, Provenance and attestation formats

https://www.w3.org/TR/vc-data-model-2.0/

INSIDE F1 Agent
"A verifiable credential MUST have an issuer property." and "The value of the issuer property MUST be either a URL or an object containing an id property whose value is a URL"

https://www.w3.org/TR/vc-data-model-2.0/

OUTSIDE F2 Authority
termsOfUse may express "the identity of the entity under whose authority the issuer issued this particular verifiable credential" — but it is an extension point, not required: "Implementers are advised to pay close attention to the extension points in this specification, such as in Sections 4.10 Status, 4.11 Data Schemas, 4.12 Securing Mechanisms, 5.4 Refreshing, 5.5 Terms of Use, and 5.6 Evidence. While this specification does not define concrete implementations for those extension points…"

https://www.w3.org/TR/vc-data-model-2.0/

OUTSIDE F3 Rubric version
"The credentialSchema property allows one to annotate type definitions or lock them to specific versions of the vocabulary." — same extension-point caveat as above.

https://www.w3.org/TR/vc-data-model-2.0/

OUTSIDE F4 Evidence
"If present, the value of the evidence property MUST be either a single object or a set of one or more objects." and "The evidence property provides information that is different from and information to the securing mechanism used."

https://www.w3.org/TR/vc-data-model-2.0/

ABSENT F5 Approver
(no field) — searched vc-data-model-2.0 for an approver / countersigner / release sign-off property. None exists; the model has exactly one issuer.

https://www.w3.org/TR/vc-data-model-2.0/

ABSENT F6 Challenge
(no field) — the nearest construct is issuer-controlled status, not third-party dispute: "This specification defines the credentialStatus property for discovering information related to the status of a verifiable credential, such as whether it is suspended or revoked."

https://www.w3.org/TR/vc-data-model-2.0/

1/6 EU AI Act Art.12 — ai-decision-logging-spec v0.1.0 (2026-03-10, MIT) · lane 2, Transparency logs and registries

https://github.com/synthetic-data-news/ai-decision-logging-spec

INSIDE F1 Agent
§5 Required Fields, model_version: "A version identifier for the model or system that produced this decision. Format is implementation-defined but MUST be stable and deterministic (i.e., the same model version always produces the same identifier)." Covered by record_hash: "The SHA-256 hash of this record's canonical form (RFC 8785), computed after all other fields are set."

https://github.com/synthetic-data-news/ai-decision-logging-spec/blob/main/SPEC.md

ABSENT F2 Authority
Searched §§5, 6, 7 of SPEC.md. No field expresses granted scope or delegation. The nearest is §7 optional operator_id, "An identifier for the deployer or operator responsible for this AI system", which names a responsible party without stating what it permitted.

https://github.com/synthetic-data-news/ai-decision-logging-spec/blob/main/SPEC.md

OUTSIDE F3 Rubric version
§6 Recommended Fields (SHOULD, not MUST), policy_version: "The version of the business rule set, policy document, or operational configuration active at the time of the decision."

https://github.com/synthetic-data-news/ai-decision-logging-spec/blob/main/SPEC.md

OUTSIDE F4 Evidence
§6 Recommended Fields, input_reference: "A reference to the input that triggered this decision. MAY be a hash, an opaque identifier, or a summary. MUST NOT be the full input content in public records. SHOULD be sufficient to reconstruct the input in a controlled audit context."

https://github.com/synthetic-data-news/ai-decision-logging-spec/blob/main/SPEC.md

OUTSIDE F5 Approver
§6 Recommended Fields, human_oversight_flag: "Whether a human reviewed, approved, or overrode this decision before it was acted upon." Type is boolean — it records that oversight happened, not who performed it.

https://github.com/synthetic-data-news/ai-decision-logging-spec/blob/main/SPEC.md

ABSENT F6 Challenge
Searched SPEC.md for challeng, dispute, revok, contest. No hits.

https://github.com/synthetic-data-news/ai-decision-logging-spec/blob/main/SPEC.md

1/6 Go checksum database (sumdb) Proposal 25530, sum.golang.org · lane 2, Transparency logs and registries

https://raw.githubusercontent.com/golang/proposal/master/design/25530-sumdb.md

ABSENT F1 Agent
Searched the proposal. The record is defined as "the data for the record (that is, the go.sum lines for module M version V)" — module path, version, and content hashes. No signer, author, or publisher identity is recorded. The design says so directly: "The simplest possible approach, which we never seriously considered, is to have one trusted server that issues a signed certificate for each module version."

https://raw.githubusercontent.com/golang/proposal/master/design/25530-sumdb.md

ABSENT F2 Authority
Searched the proposal. No notion of a party being permitted to publish a given module path.

https://raw.githubusercontent.com/golang/proposal/master/design/25530-sumdb.md

ABSENT F3 Rubric version
Searched the proposal. The database applies no evaluable policy — it records what it fetched.

https://raw.githubusercontent.com/golang/proposal/master/design/25530-sumdb.md

INSIDE F4 Evidence
"/lookup/M@V will serve the log record number for the entry about module M version V, followed by the data for the record (that is, the go.sum lines for module M version V) and a signed tree hash for a tree that contains the record. … Note that the data should never be used without first authenticating it against the signed tree hash"

https://raw.githubusercontent.com/golang/proposal/master/design/25530-sumdb.md

ABSENT F5 Approver
Searched the proposal for approver/human-sign-off semantics. None; insertion is automatic on first lookup: "If the module version is not yet recorded in the log, the notary will try to fetch it before replying."

https://raw.githubusercontent.com/golang/proposal/master/design/25530-sumdb.md

ABSENT F6 Challenge
Detection only, and by third parties: "We hope that proxies run by various organizations in the Go community will also serve as auditors and double-check Go checksum database log entries as part of their ordinary operation." There is no state a record can be moved into.

https://raw.githubusercontent.com/golang/proposal/master/design/25530-sumdb.md

1/6 RFC 9162 Certificate Transparency v2 RFC 9162 (Dec 2021, Experimental) · lane 2, Transparency logs and registries

https://www.rfc-editor.org/rfc/rfc9162.txt

INSIDE F1 Agent
"issuer_key_hash is the HASH of the public key of the CA that issued the certificate or precertificate, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo [RFC5280]. This is needed to bind the CA to the certificate or precertificate" (§4.7)

https://www.rfc-editor.org/rfc/rfc9162.txt

OUTSIDE F2 Authority
The authority-bearing chain is checked and stored but never enters the leaf: "Each of the zero or more intermediate CA certificates in the chain MUST have one or both of the following features: - The Basic Constraints extension with the cA boolean asserted. - The Key Usage extension with the keyCertSign bit asserted." (§4.2.1) and "If a submission is accepted and an SCT is issued, the accepting log MUST store the entire chain used for verification. … The log MUST provide this chain for auditing upon request (see Section 5.6) so that the CA cannot avoid blame by logging a partial or empty chain." (§4.3)

https://www.rfc-editor.org/rfc/rfc9162.txt

OUTSIDE F3 Rubric version
Acceptance policy exists but is per-log and unrecorded in the entry: "If the minimum acceptance criteria are met but the submission is not fully valid according to [RFC5280] verification rules … then the acceptability of the submission is left to the log's discretion." (§4.2.2)

https://www.rfc-editor.org/rfc/rfc9162.txt

OUTSIDE F4 Evidence
The inputs the log actually read to reach its accept decision — the chain and the trust anchor — are stored out-of-band, not committed to the leaf: "This chain MUST include the certificate or precertificate itself, the zero or more intermediate CA certificates provided by the submitter, and the trust anchor used to verify the chain (even if it was omitted from the submission)." (§4.3)

https://www.rfc-editor.org/rfc/rfc9162.txt

ABSENT F5 Approver
Searched RFC 9162 for approv, human, sign-off. No approver role exists; the log's accept decision is unattributed.

https://www.rfc-editor.org/rfc/rfc9162.txt

ABSENT F6 Challenge
Detection exists; a record-lifecycle challenge state does not. "Violation of the append-only property or the STH issuance rate limit can be detected by multiple clients comparing their instances of the STHs. This technique, known as 'gossip', is an active area of research and not defined here." (§11.3) and "The action taken by the auditor, if an audit fails, is not specified" (§8.3)

https://www.rfc-editor.org/rfc/rfc9162.txt

1/6 RFC 9943 SCITT RFC 9943 (June 2026, Standards Track) · lane 2, Transparency logs and registries

https://www.rfc-editor.org/rfc/rfc9943.txt

INSIDE F1 Agent
"The protected header of a Signed Statement and a Receipt MUST include the CWT Claims header parameter as specified in Section 2 of [RFC9597]. The CWT Claims value MUST include the Issuer Claim (Claim label 1) and the Subject Claim (Claim label 2) [IANA.cwt]." (§6) — and the definition: "Issuer: an identifier representing an organization, device, user, or entity securing Statements about supply chain Artifacts." (§3)

https://www.rfc-editor.org/rfc/rfc9943.txt

ABSENT F2 Authority
Searched RFC 9943 for authoriz, delegat, scope, permission. The only hits are unrelated (OAuth-style resource-owner authorization at §3, auditor access at §5.1.3, out-of-scope note at §9). No field expresses what an Issuer is permitted to attest.

https://www.rfc-editor.org/rfc/rfc9943.txt

OUTSIDE F3 Rubric version
"To enable auditability, TSs MUST maintain Registration Policies." … "Registration Policies and trust anchors MUST be made Transparent and available to all Relying Parties of the TS by Registering them as Signed Statements on the VDS." … "The TS MUST apply the Registration Policy that was most recently committed to the VDS at the time of Registration." (§5.1.1, §5.1.1.1)

https://www.rfc-editor.org/rfc/rfc9943.txt

N/A F4 Evidence
Out of scope: SCITT does not define statement content. "Statement payloads might be too large or too sensitive to be sent to a remote TS. In these cases, a Statement can be made over the hash of a payload rather than the full payload bytes." (§6.2) — an optional detached-payload mechanism, not an evidence-digest field.

https://www.rfc-editor.org/rfc/rfc9943.txt

ABSENT F5 Approver
Searched RFC 9943 for human, approv, sign-off, reviewer. "release approvals" appears once, at §2.1, as an example of a *kind of statement one might register* — "Examples of statements may include commit signatures, build environment and parameters, Software Bill of Materials (SBOM), static and dynamic application security testing results, fuzz testing results, release approvals, deployment records, vulnerability scan results, and patch logs." No approver field exists.

https://www.rfc-editor.org/rfc/rfc9943.txt

ABSENT F6 Challenge
Searched for revoc, dispute, challeng, complain, withdraw. "The SCITT ledger represents a linear and irrevocable history of statements made." (§1) and "Revocation strategies for compromised keys are out of scope for this document." (§9.4.2)

https://www.rfc-editor.org/rfc/rfc9943.txt

1/6 TUF (The Update Framework) v1.0.36 (2026-08-05) · lane 2, Transparency logs and registries

https://raw.githubusercontent.com/theupdateframework/specification/master/tuf-spec.md

OUTSIDE F1 Agent
The signer's identifier lives in the unsigned wrapper: "SIGNATURE :: A hex-encoded signature of the canonical form of the metadata for ROLE." — while "KEYID :: The identifier of the key signing the ROLE object, which is a hexdigest of the SHA-256 hash of the canonical form of the key." sits in the "signatures" array, alongside the signature rather than under it.

https://raw.githubusercontent.com/theupdateframework/specification/master/tuf-spec.md

INSIDE F2 Authority
Root's signed block contains "roles" : { ROLE : { "keyids" : [ KEYID, ... ] , "threshold" : THRESHOLD } , ... }, and targets' signed block contains ("delegations" : DELEGATIONS). The delegation semantics: "the targets role can delegate full or partial trust to other roles. Delegating trust means that the targets role indicates another role (that is, another set of keys and the threshold required for trust) is trusted to sign target file metadata."

https://raw.githubusercontent.com/theupdateframework/specification/master/tuf-spec.md

ABSENT F3 Rubric version corrected from INSIDE by the independent pass (finding F-2) — the quotation below is the original reasoning, kept in place
"spec_version" appears inside the signed block of root, snapshot, targets, timestamp and mirrors: "SPEC_VERSION :: A string that contains the version number of the TUF specification. … Metadata is written according to version "spec_version" of the specification, and clients MUST verify that "spec_version" matches the expected version number."

https://raw.githubusercontent.com/theupdateframework/specification/master/tuf-spec.md

ABSENT F4 Evidence corrected from INSIDE by the independent pass (finding F-4) — the quotation below is the original reasoning, kept in place
Inside targets' signed block: TARGETPATH : { "length" : LENGTH, "hashes" : HASHES, ("custom" : CUSTOM) }, where "HASHES: A dictionary that specifies one or more hashes of the target file at [TARGETPATH]".

https://theupdateframework.github.io/specification/latest/

OUTSIDE F5 Approver
The required quorum is signed; who actually met it is not. "THRESHOLD A positive integer number of keys (>=1) of that role whose signatures are required in order to consider a file as being properly signed by that role." — but the identities that satisfied the threshold appear only in the unsigned "signatures" array, one KEYID per entry.

https://raw.githubusercontent.com/theupdateframework/specification/master/tuf-spec.md

ABSENT F6 Challenge
Searched tuf-spec.md. Key rotation exists — "To replace a compromised root key or any other top-level role key, the root role signs a new root.json file that lists the updated trusted keys for the role." — but it revokes *keys*, not records. No metadata file can be disputed, annotated, or marked contested; it can only be superseded by a higher VERSION.

https://theupdateframework.github.io/specification/latest/

1/6 Biscuit format version 2.0, biscuit versions 3-5 · lane 3, Agent identity and delegation

https://github.com/biscuit-auth/biscuit/blob/master/SPECIFICATIONS.md

ABSENT F1 Agent
— searched SPECIFICATIONS.md: the format defines no subject or actor field. A block carries "repeated FactV2 facts_v2, repeated RuleV2 rules_v2, repeated CheckV2 checks_v2" — the identity of the acting party, if present at all, is an application-defined Datalog fact, not a specified field

https://raw.githubusercontent.com/biscuit-auth/biscuit/master/SPECIFICATIONS.md

INSIDE F2 Authority
"The first one, named 'authority block', contains rights given to the token holder." "Each block contains the serialized Datalog, the next public key, and the signature by the previous key." "The holder of a biscuit token can at any time create a new token by adding a block with more checks, thus restricting the rights of the new token, but they cannot remove existing blocks without invalidating the signature."

https://raw.githubusercontent.com/biscuit-auth/biscuit/master/SPECIFICATIONS.md

ABSENT F3 Rubric version
— searched SPECIFICATIONS.md; the version numbers present are format/protocol versions, not versions of a governing ruleset

https://raw.githubusercontent.com/biscuit-auth/biscuit/master/SPECIFICATIONS.md

ABSENT F4 Evidence
— searched SPECIFICATIONS.md; no input-digest field

https://raw.githubusercontent.com/biscuit-auth/biscuit/master/SPECIFICATIONS.md

ABSENT F5 Approver
— searched SPECIFICATIONS.md; no human-approver field

https://raw.githubusercontent.com/biscuit-auth/biscuit/master/SPECIFICATIONS.md

ABSENT F6 Challenge
— searched SPECIFICATIONS.md. Revocation identifiers exist and are derived from the signature — "The revocation identifier for a block is its signature (as it uniquely identifies the block) serialized to a byte array" — but revocation is cancellation, not a recorded dispute with a response

https://raw.githubusercontent.com/biscuit-auth/biscuit/master/SPECIFICATIONS.md

1/6 IETF SPICE SD-CWT draft-ietf-spice-sd-cwt-08, June 2026 · lane 3, Agent identity and delegation

https://www.ietf.org/archive/id/draft-ietf-spice-sd-cwt-08.txt

INSIDE F1 Agent
Table 2 (§6): iss (1) — "MUST unless (see note)", "Never Redacted"; sub (2) — "MUST be present (disclosed or redacted)"; cnf (8) — "MUST", "Never Redacted". §8.1: "A KBT is itself a type of CWT, signed using the private key corresponding to the key in the cnf claim in the presented SD-CWT." §8: "Regardless if it discloses any claims, the Holder sends the Verifier a unique Holder Key Binding Token (KBT) for every presentation."

https://www.ietf.org/archive/id/draft-ietf-spice-sd-cwt-08.txt

ABSENT F2 Authority
— searched draft-08 §4, §6 (claim tables), §8: no granted-scope, permission or delegation field

https://www.ietf.org/archive/id/draft-ietf-spice-sd-cwt-08.txt

ABSENT F3 Rubric version
— searched draft-08 §4, §6, §8; no policy version field

https://www.ietf.org/archive/id/draft-ietf-spice-sd-cwt-08.txt

ABSENT F4 Evidence
— searched draft-08 §4, §6, §8; no input-digest field. The digests present are salted hashes of *redacted claims of this credential*, not of external inputs read

https://www.ietf.org/archive/id/draft-ietf-spice-sd-cwt-08.txt

ABSENT F5 Approver
— searched draft-08 §4, §6, §8; no human-approver field. §6.1 speaks only of the Issuer: "The Issuer SHOULD confirm the Holder controls all confirmation key material before issuing credentials using the cnf claim"

https://www.ietf.org/archive/id/draft-ietf-spice-sd-cwt-08.txt

ABSENT F6 Challenge
— searched draft-08 §4, §6, §8; no dispute/challenge lifecycle state

https://www.ietf.org/archive/id/draft-ietf-spice-sd-cwt-08.txt

1/6 IETF WIMSE workload-creds draft-ietf-wimse-workload-creds-02, July 2026 · lane 3, Agent identity and delegation

https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds

INSIDE F1 Agent
§5.1: "The Workload Identity Token (WIT) is a JWS signed JWT that represents the identity of a workload." §5.1 claim list: "sub: The subject of the token, which is the single Workload Identifier". §5.1: "It is issued by the Identity Server and binds a public key to the workload identity."

https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds

ABSENT F2 Authority
— searched draft-02: no entitlement or granted-scope field. §7 places the decision outside the credential: "The receiving application uses the authenticated peer's workload identifier in authorization, accounting, and auditing."

https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds

ABSENT F3 Rubric version
— searched draft-02; no policy version field

https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds

ABSENT F4 Evidence
— searched draft-02; no input-digest field

https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds

ABSENT F5 Approver
— searched draft-02; no human-approver field

https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds

ABSENT F6 Challenge
— searched draft-02; no dispute/challenge state

https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds

1/6 Macaroons NDSS '14, 23-26 February 2014 · lane 3, Agent identity and delegation

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41892.pdf

ABSENT F1 Agent
— searched §I-§IV of the paper: no defined actor field. Caveats *can* express it, but only as application-defined predicates: "a macaroon that authorizes service requests may contain caveats that require proof that the requests have been audited and approved by an abuse-detection service, and come from a specific device with a particular authenticated user."

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41892.pdf

INSIDE F2 Authority
"Macaroons allow authority to be delegated between protection domains with both attenuation and contextual confinement. For this, each macaroon embeds caveats which are predicates that restrict the macaroon's authority, as well as the context in which it may be successfully used." "Macaroons use cryptographic means to provide the symbolic security properties of verifiable integrity, secrecy of intermediate keys, and the inability for adversaries to remove caveats." "...with the embedding macaroon's signature ensuring the integrity of both identifiers."

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41892.pdf

ABSENT F3 Rubric version
— searched the full extracted text; no policy version field

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41892.pdf

ABSENT F4 Evidence
— searched the full extracted text. Third-party caveats demand evidence *at verification time* ("contextually confine it by requiring additional evidence, such as third-party signatures"), which is a requirement to produce a discharge, not a digest of the inputs that were read

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41892.pdf

OUTSIDE F5 Approver
"In particular, a macaroon that authorizes service requests may contain caveats that require proof that the requests have been audited and approved by an abuse-detection service, and come from a specific device with a particular authenticated user."

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41892.pdf

ABSENT F6 Challenge
— searched the full extracted text; no dispute/challenge lifecycle state

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41892.pdf

1/6 SPIFFE/SPIRE SVID X509-SVID + JWT-SVID (spiffe/spiffe main, fetched 2026-09-01) · lane 3, Agent identity and delegation

https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md

INSIDE F1 Agent
"An X.509 SVID MUST contain exactly one URI SAN, and by extension, exactly one SPIFFE ID." and, from SPIFFE-ID.md, "The SPIFFE ID and the public key (if present) MUST be included in a portion of the payload which is signed." JWT-SVID §3.1: "The sub claim MUST be set to the SPIFFE ID of the workload to which it is issued."

https://raw.githubusercontent.com/spiffe/spiffe/main/standards/X509-SVID.md
.../SPIFFE-ID.md
.../JWT-SVID.md

OUTSIDE F2 Authority corrected from ABSENT by the independent pass (finding F-7) — the quotation below is the original reasoning, kept in place
— searched X509-SVID.md, JWT-SVID.md, SPIFFE-ID.md: no granted-scope, permission or delegation field is defined. The only extension hook is JWT-SVID §3: "Registered claims not described in this document, in addition to private claims, MAY be used as implementers see fit."

https://raw.githubusercontent.com/spiffe/spiffe/main/standards/JWT-SVID.md

ABSENT F3 Rubric version
— searched X509-SVID.md, JWT-SVID.md, SPIFFE-ID.md; no policy or rubric version field

https://raw.githubusercontent.com/spiffe/spiffe/main/standards/X509-SVID.md

ABSENT F4 Evidence
— searched the same three documents; no input-digest field

https://raw.githubusercontent.com/spiffe/spiffe/main/standards/X509-SVID.md

ABSENT F5 Approver
— searched the same three documents; no human-approver field

https://raw.githubusercontent.com/spiffe/spiffe/main/standards/X509-SVID.md

ABSENT F6 Challenge
— searched the same three documents; no dispute/challenge lifecycle state

https://raw.githubusercontent.com/spiffe/spiffe/main/standards/X509-SVID.md

1/6 Microsoft Agent Governance Toolkit — AUDIT-COMPLIANCE-1.0 spec 1.0-DRAFT (repo v4.1.0) · lane 4, Agent governance toolkits

https://raw.githubusercontent.com/microsoft/agent-governance-toolkit/main/docs/specs/AUDIT-COMPLIANCE-1.0.md

INSIDE F1 Agent
§4.3: "agent_did | string | REQUIRED | DID of the agent." — and §4.4: "Construct a dictionary containing exactly: entry_id, timestamp (ISO format string), event_type, agent_did, action, resource, data, outcome, previous_hash."

(as above)

OUTSIDE F2 Authority
§11.6 Optional BOM Fields: "Implementations SHOULD include when available:" … "delegation_chain | LINEAGE | Chain of agent delegations leading to this action."

(as above)

OUTSIDE F3 Rubric version
§4.3: "policy_version | string | OPTIONAL | Version identifier of the policy bundle that produced this decision. Defends against silent policy downgrade. See §4.3.1."

(as above)

OUTSIDE F4 Evidence
§4.3: "arguments_hash | string | OPTIONAL | SHA-256 hash (hex, lowercase) of the canonical-JSON serialization of the action arguments. Defends against silent mutation of recorded arguments. See §4.3.1."

(as above)

OUTSIDE F5 Approver
§4.3: "approver_did | string | OPTIONAL | DID of the principal whose approval authorized this action. Surfaces approval-chain identity in the audit row itself. See §4.3.1."

(as above)

ABSENT F6 Challenge
Searched the full 94 KB of docs/specs/AUDIT-COMPLIANCE-1.0.md for challenge, dispute, appeal, contest. Zero occurrences. The only lifecycle-adjacent hits were delegation_chain (§11.6) and ai.agentmesh.delegation.created (§ event registry).

(as above)

0/6 CycloneDX Attestations (CDXA) CycloneDX 1.7 JSON schema · lane 1, Provenance and attestation formats

https://raw.githubusercontent.com/CycloneDX/specification/master/schema/bom-1.7.schema.json

OUTSIDE F1 Agent
declarations.assessors[].organization: "The entity issuing the assessment."; metadata.tools: "The tool(s) used in the creation, enrichment, and validation of the BOM."

https://raw.githubusercontent.com/CycloneDX/specification/master/schema/bom-1.7.schema.json

OUTSIDE F2 Authority
assessors[].thirdParty: "The boolean indicating if the assessor is outside the organization generating claims. A value of false indicates a self assessor."; affirmation.signatories[].role: "The signatory's role within an organization."

https://raw.githubusercontent.com/CycloneDX/specification/master/schema/bom-1.7.schema.json

OUTSIDE F3 Rubric version
definitions.standards[] → standard.version: "The version of the standard." (alongside name: "The name of the standard…" and owner: "The owner of the standard, often the entity responsible for its release.")

https://raw.githubusercontent.com/CycloneDX/specification/master/schema/bom-1.7.schema.json

OUTSIDE F4 Evidence
declarations.evidence[].data.contents: "The contents or references to the contents of the data being described." with only attachment and url beneath it — the evidence object defines no hash/digest property at all.

https://raw.githubusercontent.com/CycloneDX/specification/master/schema/bom-1.7.schema.json

OUTSIDE F5 Approver
affirmation.signatories: "The list of signatories authorized on behalf of an organization to assert validity of this document."; affirmation.statement example: "I certify, to the best of my knowledge, that all information is correct."

https://raw.githubusercontent.com/CycloneDX/specification/master/schema/bom-1.7.schema.json

OUTSIDE F6 Challenge
claims[].counterEvidence: "The list of bom-ref to counterEvidence that supports this claim."; attestations[].map[].counterClaims: "The list of bom-ref to the counter claims being attested to."

https://raw.githubusercontent.com/CycloneDX/specification/master/schema/bom-1.7.schema.json

0/6 Grafeas v1 proto, master (repo alive: last push 2026-07-25) · lane 1, Provenance and attestation formats

https://raw.githubusercontent.com/grafeas/grafeas/master/proto/v1/attestation.proto

OUTSIDE F1 Agent
Signature.public_key_id: "The identifier for the public key that verifies this signature. * The public_key_id is required. * The public_key_id SHOULD be an RFC3986 conformant URI." — required, but a sibling of the signature rather than part of serialized_payload.

https://raw.githubusercontent.com/grafeas/grafeas/master/proto/v1/common.proto

OUTSIDE F2 Authority
AttestationNote: "Note kind that represents a logical attestation 'role' or 'authority'. For example, an organization might have one Authority for 'QA' and one for 'build'." — but: "Note that these hints should not be used to look up authorities in security sensitive contexts, such as when looking up attestations to verify." and "the authority to which this attestation is attached is primarily useful for lookup … and intent".

https://raw.githubusercontent.com/grafeas/grafeas/master/proto/v1/attestation.proto

ABSENT F3 Rubric version
(no field) — searched attestation.proto and grafeas.proto; AttestationOccurrence has exactly three fields (serialized_payload, signatures, jwts) and none names a policy or its version.

https://raw.githubusercontent.com/grafeas/grafeas/master/proto/v1/attestation.proto

OUTSIDE F4 Evidence
The binding between the record and what it is about is explicitly unenforced: "Each JWT SHOULD encode a claim specific to the resource_uri of this Occurrence, but this is not validated by Grafeas metadata API implementations. The JWT itself is opaque to Grafeas."

https://raw.githubusercontent.com/grafeas/grafeas/master/proto/v1/attestation.proto

ABSENT F5 Approver
(no field) — multiple signatures are permitted but are treated as interchangeable, not role-bearing: "Verifier implementations should consider this attestation message verified if at least one signature verifies serialized_payload."

https://raw.githubusercontent.com/grafeas/grafeas/master/proto/v1/attestation.proto

ABSENT F6 Challenge
(no field) — searched attestation.proto and grafeas.proto; the Occurrence lifecycle is create / update / delete with no dispute state.

https://raw.githubusercontent.com/grafeas/grafeas/master/proto/v1/grafeas.proto

0/6 OpenSSF Scorecard / scorecard-attestor main branch, fetched 2026-09-01 · lane 1, Provenance and attestation formats

https://raw.githubusercontent.com/ossf/scorecard/main/attestor/README.md

ABSENT F1 Agent
(no field) — sign.go threads only the image and a fixed note constant into the signer: const scorecardNoteID = "ossf-scorecard-attestation" … r := signer.New(client, cSigner, scorecardNoteName, attestationProject, overwrite) … err = r.SignImage(image). No Scorecard version, tool identity, or run identifier is passed.

https://raw.githubusercontent.com/ossf/scorecard/main/attestor/command/sign.go

ABSENT F2 Authority
(no field) — searched attestor/README.md and attestor/command/sign.go.

https://raw.githubusercontent.com/ossf/scorecard/main/attestor/README.md

ABSENT F3 Rubric version
(no field) — the rubric is a run-time argument that is never recorded: "Policies for scorecard attestor can be passed through the CLI using the --policy flag."

https://raw.githubusercontent.com/ossf/scorecard/main/attestor/README.md

ABSENT F4 Evidence
(no field) — Scorecard's findings are consumed and discarded; only the image is signed (r.SignImage(image), above).

https://raw.githubusercontent.com/ossf/scorecard/main/attestor/command/sign.go

ABSENT F5 Approver
(no field) — RequiredApprovers exists but is a *policy input about the repository's* reviewers, not an approver of the record: "CodeReviewRequirements.RequiredApprovers: A set of approvers, any of whom must be found to have approved all changes."

https://raw.githubusercontent.com/ossf/scorecard/main/attestor/README.md

ABSENT F6 Challenge
(no field) — searched attestor/README.md and sign.go.

https://raw.githubusercontent.com/ossf/scorecard/main/attestor/README.md

0/6 RO-Crate + Workflow Run RO-Crate RO-Crate 1.2 (2025-06-04) / Workflow Run Crate 0.5 / Process Run Crate 0.5 · lane 1, Provenance and attestation formats

https://www.researchobject.org/workflow-run-crate/profiles/workflow_run_crate/

OUTSIDE F1 Agent
Process Run Crate CreateAction table: "instrument | MUST | Identifier of the executed tool." and "agent | SHOULD | Identifier of a Person or Organization contextual entity that started/executed this tool."

https://www.researchobject.org/workflow-run-crate/profiles/process_run_crate/

ABSENT F2 Authority
(no field) — searched Process Run Crate 0.5, Workflow Run Crate 0.5, and all eleven RO-Crate 1.2 pages; no delegation or granted-scope property.

https://www.researchobject.org/workflow-run-crate/profiles/process_run_crate/

OUTSIDE F3 Rubric version
Workflow Run Crate conformsTo: "MUST reference a CreativeWork entity with an @id URI that is consistent with the versioned Permalink of this document, and SHOULD also reference versioned permalinks for Process Run Crate and Workflow RO-Crate."

https://www.researchobject.org/workflow-run-crate/profiles/workflow_run_crate/

OUTSIDE F4 Evidence
"object | MAY | The identifier of one or more entities of the RO-Crate that were consumed by this action, e.g. input files or reference datasets." — and on integrity generally: "Warning: The BagIt manifest is intended to detect 'bit rot' and accidental damage, it does not provide proof the RO-Crate has not been deliberately tampered with, as a malicious actor can also update the checksums."

https://www.researchobject.org/workflow-run-crate/profiles/process_run_crate/
https://www.researchobject.org/ro-crate/specification/1.2/appendix/implementation-notes.html

ABSENT F5 Approver
(no field) — searched all three profile pages and the eleven RO-Crate 1.2 pages.

https://www.researchobject.org/workflow-run-crate/profiles/workflow_run_crate/

ABSENT F6 Challenge
(no field) — same documents searched.

https://www.researchobject.org/workflow-run-crate/profiles/workflow_run_crate/

0/6 SPDX Build profile 3.0.1 · lane 1, Provenance and attestation formats

https://spdx.github.io/spdx-spec/v3.0.1/model/Build/Classes/Build/

OUTSIDE F1 Agent
CreationInfo property table: "createdBy | Agent | minCount 1 | maxCount *" and "createdUsing | Tool | minCount 0 | maxCount *" — required by SHACL, but no signature covers it.

https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Classes/CreationInfo/

OUTSIDE F2 Authority
RelationshipType vocabulary: "delegatedTo: The from Agent is delegating an action to the Agent of the to Relationship (which must be of type invokedBy), during a LifecycleScopeType (e.g. the to invokedBy Relationship is being done on behalf of from)." Relationships are separate, optional Elements.

https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Vocabularies/RelationshipType/

OUTSIDE F3 Rubric version
CreationInfo: "specVersion | SemVer | minCount 1 | maxCount 1"; Build: "buildType | xsd:anyURI | minCount 1 | maxCount 1"

https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Classes/CreationInfo/
https://spdx.github.io/spdx-spec/v3.0.1/model/Build/Classes/Build/

OUTSIDE F4 Evidence
Build property table: "configSourceDigest | /Core/Hash | minCount 0 | maxCount *" — and on Element: "verifiedUsing | IntegrityMethod | minCount 0 | maxCount *"

https://spdx.github.io/spdx-spec/v3.0.1/model/Build/Classes/Build/

ABSENT F5 Approver
(no field) — searched spdx-model.ttl (the complete 3.0.1 model): the only matches for "Approv" are ns2:isOsiApproved — "Specifies whether the License is listed as approved by the Open Source Initiative (OSI)." No record-approval construct, and no approval relationship type in the RelationshipType vocabulary.

https://spdx.org/rdf/3.0.1/spdx-model.ttl

ABSENT F6 Challenge
(no field) — same file searched; no dispute/challenge/contest construct.

https://spdx.org/rdf/3.0.1/spdx-model.ttl

0/6 Sigstore bundle format v0.3 (protobuf-specs) + Fulcio OID extensions · lane 1, Provenance and attestation formats

https://raw.githubusercontent.com/sigstore/protobuf-specs/main/protos/sigstore_bundle.proto

OUTSIDE F1 Agent
Identity lives in the Fulcio certificate, not in the signed payload — "MUST include claim to support: Build Signer URI that identifies the specific build instructions that are responsible for signing." The bundle nonetheless permits a bare key with no identity: "This allows key material to be conveyed in one of three forms: 1. An unspecified public key identifier, for retrieving a key from an out-of-band mechanism (such as a keyring)".

https://raw.githubusercontent.com/sigstore/fulcio/main/docs/oid-info.md
https://raw.githubusercontent.com/sigstore/protobuf-specs/main/protos/sigstore_bundle.proto

ABSENT F2 Authority
(no field) — searched sigstore_bundle.proto and the full Fulcio OID directory. The closest, Runner Environment, records execution setting rather than granted decision scope: "For platforms to specify whether the build took place in platform-hosted cloud infrastructure or customer-hosted infrastructure. For example: platform-hosted and self-hosted."

https://raw.githubusercontent.com/sigstore/fulcio/main/docs/oid-info.md

OUTSIDE F3 Rubric version
"SHOULD include claim to support: Build Signer Digest which is an immutable reference to a specific version of the build instructions that are responsible for signing."

https://raw.githubusercontent.com/sigstore/fulcio/main/docs/oid-info.md

N/A F4 Evidence
Out of the bundle format's stated scope — the bundle transports a signature and verification material, and treats the judged content as opaque: "A DSSE envelope can contain arbitrary payloads. Verifiers must verify that the payload type is a supported and expected type."

https://raw.githubusercontent.com/sigstore/protobuf-specs/main/protos/sigstore_bundle.proto

ABSENT F5 Approver
(no field) — and structurally excluded: "DSSE envelopes in a bundle MUST have exactly one signature. … During verification a client MUST reject an envelope if the number of signatures is not equal to one."

https://raw.githubusercontent.com/sigstore/protobuf-specs/main/protos/sigstore_bundle.proto

ABSENT F6 Challenge
(no field) — searched sigstore_bundle.proto; the bundle has no lifecycle state beyond transparency-log inclusion.

https://raw.githubusercontent.com/sigstore/protobuf-specs/main/protos/sigstore_bundle.proto

0/6 W3C PROV-O / PROV-DM Rec 30 April 2013 · lane 1, Provenance and attestation formats

https://www.w3.org/TR/prov-o/

OUTSIDE F1 Agent
"Class: prov:SoftwareAgent … A software agent is running software."

https://www.w3.org/TR/prov-o/

OUTSIDE F2 Authority
"Class: prov:Delegation … Delegation is the assignment of authority and responsibility to an agent (by itself or by another agent) to carry out a specific activity as a delegate or representative, while the agent it acts on behalf of retains some responsibility for the outcome of the delegated work."

https://www.w3.org/TR/prov-o/

OUTSIDE F3 Rubric version
"Class: prov:Plan … A plan is an entity that represents a set of actions or steps intended by one or more agents to achieve some goals." — a plan may be referenced, with no version pin defined.

https://www.w3.org/TR/prov-o/

OUTSIDE F4 Evidence
"Property: prov:used … Usage is the beginning of utilizing an entity by an activity. Before usage, the activity had not begun to utilize this entity and could not have been affected by the entity." — an entity reference, and the vocabulary defines no digest.

https://www.w3.org/TR/prov-o/

ABSENT F5 Approver
(no field) — searched prov-o and prov-dm; there is prov:wasAssociatedWith / prov:wasAttributedTo for responsibility, but no approval, sign-off, or release-gate construct.

https://www.w3.org/TR/prov-o/

ABSENT F6 Challenge
(no field) — same two documents searched; no dispute construct.

https://www.w3.org/TR/prov-dm/

0/6 in-toto Attestation Framework (Statement) + DSSE spec layers v1.2 / DSSE envelope 1.0.2 (2024-05-10) · lane 1, Provenance and attestation formats

https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md

OUTSIDE F1 Agent
"KEYID: Optional, unauthenticated hint indicating what key and algorithm was used to sign the message. … It MUST NOT be used for security decisions; it may only be used to narrow the selection of possible keys to try." — and the parameter table: KEYID | string | Required: No | Authenticated: No

https://raw.githubusercontent.com/secure-systems-lab/dsse/master/protocol.md

ABSENT F2 Authority
(no field) — searched statement.md, predicate.md, README.md, resource_descriptor.md, envelope.md, protocol.md. The Statement's complete field set is _type, subject, predicateType, predicate.

https://raw.githubusercontent.com/in-toto/attestation/main/spec/v1/statement.md

ABSENT F3 Rubric version
(no field) — the only versioned identifier is the predicate schema: "The predicateType URI includes the major version number and will always change whenever there is a backwards incompatible change. Minor version changes are always backwards compatible … Such changes do not update the predicateType." That names the schema, not the governing rules.

https://raw.githubusercontent.com/in-toto/attestation/main/spec/v1/README.md

ABSENT F4 Evidence
(no field) — subject is required but is the object of judgment, not the inputs read: "subject _array of ResourceDescriptor objects, required_ > Set of software artifacts that the attestation applies to."

https://raw.githubusercontent.com/in-toto/attestation/main/spec/v1/statement.md

ABSENT F5 Approver
(no field) — envelope.md permits multiple signatures but assigns them no roles: "An envelope MAY have more than one signature, which is equivalent to separate envelopes with individual signatures."

https://raw.githubusercontent.com/secure-systems-lab/dsse/master/envelope.md

ABSENT F6 Challenge
(no field) — searched all six documents above.

https://raw.githubusercontent.com/in-toto/attestation/main/spec/v1/README.md

0/6 KEYTRANS (IETF) draft-ietf-keytrans-protocol-05 (6 July 2026) · lane 2, Transparency logs and registries

https://www.ietf.org/archive/id/draft-ietf-keytrans-protocol-05.txt

OUTSIDE F1 Agent
Per-entry signer attribution exists in only one of four deployment modes: "struct { select (Configuration.mode) { case thirdPartyManagement: opaque signature<0..2^16-1>; }; } UpdateSuffix;" (§11.5) — in contactMonitoring and thirdPartyAuditing modes the suffix is empty and the entry carries no signer.

https://www.ietf.org/archive/id/draft-ietf-keytrans-protocol-05.txt

ABSENT F2 Authority
Searched draft-05. Label ownership is stated architecturally, never as a field: "a label owner is the authoritative source for a label's contents and must either initiate all changes to the label's value themself or at least be informed of changes afterwards." (§9) The UpdateValue struct carries no scope or permission.

https://www.ietf.org/archive/id/draft-ietf-keytrans-protocol-05.txt

OUTSIDE F3 Rubric version corrected from INSIDE by the independent pass (finding F-5) — the quotation below is the original reasoning, kept in place
The log's governing parameters are inside every signed head: "The signature itself is computed over a TreeHeadTBS structure, which incorporates the log's current state as well as long-term log configuration" — struct { Configuration config; uint64 tree_size; opaque root[Hash.Nh]; } TreeHeadTBS; where Configuration holds ciphersuite, mode, public keys, max_ahead, max_behind, reasonable_monitoring_window, maximum_lifetime. The same Configuration is inside UpdateTBS (§11.2, §11.5).

https://www.ietf.org/archive/id/draft-ietf-keytrans-protocol-05.txt

N/A F4 Evidence
Out of scope — KEYTRANS distributes key material and records no decision, so "the inputs that were read" has no referent. UpdateValue.value is an opaque blob: "The value field contains the value associated with the label-version pair."

https://www.ietf.org/archive/id/draft-ietf-keytrans-protocol-05.txt

ABSENT F5 Approver
Searched draft-05. No human approver; in third-party-management mode the Service Operator signs, but that is an operator, not a release approver, and no second-party sign-off state exists.

https://www.ietf.org/archive/id/draft-ietf-keytrans-protocol-05.txt

ABSENT F6 Challenge
Fork detection is a client-side out-of-band procedure, not a record state: "The information exchanged can either be just the list of root values, if bandwidth is a particular concern, or a signed query response, if the ability to provide non-repudiable evidence of misbehavior is desired." (§10.2) A label can be superseded by a higher version; it cannot be marked disputed.

https://www.ietf.org/archive/id/draft-ietf-keytrans-protocol-05.txt

0/6 Notary Project / Notation signature-specification.md, main · lane 2, Transparency logs and registries

https://raw.githubusercontent.com/notaryproject/specifications/main/specs/signature-specification.md

OUTSIDE F1 Agent
Listed under "### Unsigned Attributes": "Signing Agent: An OPTIONAL claim that provides the identifier of the software (e.g. Notation) that produced the signature on behalf of the user. It is an opaque string set by the software that produces the signature. It's intended primarily for diagnostic and troubleshooting purposes, this attribute is unsigned, the verifier MUST NOT validate formatting, or fail validation based on the content of this claim."

https://raw.githubusercontent.com/notaryproject/specifications/main/specs/signature-specification.md

OUTSIDE F2 Authority
The authority-bearing chain is a REQUIRED but unsigned attribute: "Certificate Chain: This is a REQUIRED attribute that contains the ordered list of X.509 public certificates associated with the signing key used to generate the signature. … The certificate chain MUST be authenticated against a trust store as part of signature validation." Scope narrowing is optional: for leaf certificates, "The extendedKeyUsage extension is OPTIONAL".

https://raw.githubusercontent.com/notaryproject/specifications/main/specs/signature-specification.md

OUTSIDE F3 Rubric version
The only version-of-governing-logic field is optional: "Verification Plugin Minimum Version (critical): An OPTIONAL attribute that specifies the minimum version of the verification plugin that MUST be used to verify the signature." The one required scheme selector names a scheme, not a version: "Signing Scheme (critical): A REQUIRED claim that defines the Notary Project Signing Scheme used by the signature. … Supported values are notary.x509 and notary.x509.signingAuthority."

https://raw.githubusercontent.com/notaryproject/specifications/main/specs/signature-specification.md

ABSENT F4 Evidence corrected from INSIDE by the independent pass (finding F-3) — the quotation below is the original reasoning, kept in place
The signed payload: "targetArtifact : Required property whose value is the descriptor of the target artifact manifest that is being signed. … Descriptor MUST contain mediaType, digest, and size fields."

https://raw.githubusercontent.com/notaryproject/specifications/main/specs/signature-specification.md

ABSENT F5 Approver
Searched signature-specification.md for approv, human, sign-off, reviewer. No approver role or field; the signing identity and the approving identity are not distinguished.

https://raw.githubusercontent.com/notaryproject/specifications/main/specs/signature-specification.md

ABSENT F6 Challenge
Searched signature-specification.md. No dispute, contest, or challenge state on a signature. Revocation applies to certificates, not to records.

https://raw.githubusercontent.com/notaryproject/specifications/main/specs/signature-specification.md

0/6 OpenTimestamps python-opentimestamps master; opentimestamps.org · lane 2, Transparency logs and registries

https://opentimestamps.org/

N/A F1 Agent
Out of stated scope — OTS attests existence-before-time and nothing else: "A timestamp proves that some data existed prior to some point in time."

https://opentimestamps.org/

N/A F2 Authority
Same scope clause.

https://opentimestamps.org/

N/A F3 Rubric version
Same scope clause.

https://opentimestamps.org/

N/A F4 Evidence
Same scope clause — the single msg digest is the thing timestamped, and OTS has no notion of a decision or of the inputs to one.

https://raw.githubusercontent.com/opentimestamps/python-opentimestamps/master/opentimestamps/core/timestamp.py

N/A F5 Approver
Same scope clause.

https://opentimestamps.org/

N/A F6 Challenge
Same scope clause.

https://opentimestamps.org/

0/6 Trillian master, maintenance mode · lane 2, Transparency logs and registries

https://raw.githubusercontent.com/google/trillian/master/README.md

N/A F1 Agent
Out of scope — the payload's meaning belongs to the personality, not to Trillian. "To build a complete transparent application, the Trillian core service needs to be paired with additional code, known as a *personality*, that provides functionality that is specific to the particular application."

https://raw.githubusercontent.com/google/trillian/master/README.md

N/A F2 Authority
Same clause.

https://raw.githubusercontent.com/google/trillian/master/README.md

N/A F3 Rubric version
Admission rules are the personality's: "Admission Criteria – ensuring that submissions comply with the overall purpose of the application." Trillian records no policy identity.

https://raw.githubusercontent.com/google/trillian/master/README.md

N/A F4 Evidence
Same clause.

https://raw.githubusercontent.com/google/trillian/master/README.md

N/A F5 Approver
Same clause.

https://raw.githubusercontent.com/google/trillian/master/README.md

N/A F6 Challenge
Same clause.

https://raw.githubusercontent.com/google/trillian/master/README.md

0/6 GNAP RFC 9635, October 2024 · lane 3, Agent identity and delegation

https://www.rfc-editor.org/rfc/rfc9635.txt

OUTSIDE F1 Agent
§2.3: "The client instance MUST prove possession of any presented key by the proofing mechanism associated with the key in the request." §1.2: "Client: Application that consumes resources from one or several resource servers, possibly requiring access privileges from one or several ASes."

https://www.rfc-editor.org/rfc/rfc9635.txt

OUTSIDE F2 Authority
§2.1.1: "access (array of objects/strings): Describes the rights that the client instance is requesting for the access token to be used at the RS. REQUIRED."

https://www.rfc-editor.org/rfc/rfc9635.txt

ABSENT F3 Rubric version
— searched RFC 9635 §1-§4, §9, §13; no policy version field

https://www.rfc-editor.org/rfc/rfc9635.txt

ABSENT F4 Evidence
— searched the same sections; no input-digest field

https://www.rfc-editor.org/rfc/rfc9635.txt

OUTSIDE F5 Approver
§1.6.1: "(B) If interaction is required, the AS interacts with the RO (Section 4) to gather authorization." §2.4: "If the client instance knows the identity of the end user through one or more identifiers or assertions, the client instance MAY send that information to the AS in the user field." §1.2: "End user: Natural person that operates a client instance."

https://www.rfc-editor.org/rfc/rfc9635.txt

ABSENT F6 Challenge
— searched RFC 9635; no dispute/challenge lifecycle state

https://www.rfc-editor.org/rfc/rfc9635.txt

0/6 MCP Authorization revision 2026-07-28 · lane 3, Agent identity and delegation

https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization

ABSENT F1 Agent
— searched the full 2026-07-28 authorization page. The spec names only the *client application*, never the model or agent: "An *MCP client* acts as an [OAuth 2.1 client], making protected resource requests on behalf of a resource owner." There is no field, claim or parameter identifying which AI system produced a call

https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization

OUTSIDE F2 Authority
"Clients MUST treat the scopes provided in the challenge as authoritative for the current operation." "MCP servers SHOULD include a scope parameter in the WWW-Authenticate header as defined in [RFC 6750 Section 3] to indicate the scopes required for accessing the resource." The spec governs how scope is *requested and challenged*; the access token format and whether scope appears inside it are left to the authorization server

https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization

ABSENT F3 Rubric version
— searched the full 2026-07-28 authorization page; no policy version field

https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization

ABSENT F4 Evidence
— searched the full 2026-07-28 authorization page; no input-digest field

https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization

ABSENT F5 Approver
— searched the full 2026-07-28 authorization page. The flow diagram carries the note "User authorizes", but no field records who did so and nothing binds that human into any artifact the server can verify later

https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization

ABSENT F6 Challenge
— searched the full 2026-07-28 authorization page; no dispute/challenge lifecycle state

https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization

0/6 OAuth 2.0 RAR RFC 9396, May 2023 · lane 3, Agent identity and delegation

https://www.rfc-editor.org/rfc/rfc9396.txt

ABSENT F1 Agent
— searched RFC 9396 §2, §7, §9, §12: the RFC defines no field naming the requesting party; client identification is inherited from RFC 6749 and is not part of the authorization_details structure

https://www.rfc-editor.org/rfc/rfc9396.txt

OUTSIDE F2 Authority
§2: "The request parameter authorization_details contains, in JSON notation, an array of objects... type: An identifier for the authorization details type as a string... This field is REQUIRED." §7: "the AS MUST also return the authorization_details as granted by the resource owner and assigned to the respective access token." But §9.1: "If the access token is a JWT [RFC7519], the AS is RECOMMENDED to add the authorization details object, filtered to the specific audience, as a top-level claim."

https://www.rfc-editor.org/rfc/rfc9396.txt

ABSENT F3 Rubric version
— searched RFC 9396; no policy version field

https://www.rfc-editor.org/rfc/rfc9396.txt

ABSENT F4 Evidence
— searched RFC 9396; no input-digest field

https://www.rfc-editor.org/rfc/rfc9396.txt

ABSENT F5 Approver
— searched RFC 9396; the resource owner grants, but no approver identity field is defined in the structure

https://www.rfc-editor.org/rfc/rfc9396.txt

ABSENT F6 Challenge
— searched RFC 9396; no dispute/challenge state

https://www.rfc-editor.org/rfc/rfc9396.txt

0/6 W3C DID Core 1.0, W3C Recommendation 19 July 2022 · lane 3, Agent identity and delegation

https://www.w3.org/TR/did-core/

OUTSIDE F1 Agent
§5.1.1: "The value of id MUST be a string that conforms to the rules in 3.1 DID Syntax and MUST exist in the root map of the data model for the DID document."

https://www.w3.org/TR/did-core/

ABSENT F2 Authority
— searched DID Core §5 (Core Properties), §8, §9, §10: no granted-scope field. The nearest constructs name a *key usage*, not a scope — §5.3.5: "The capabilityDelegation verification relationship is used to specify a verification method that can be used to delegate a cryptographic capability to another party."

https://www.w3.org/TR/did-core/

ABSENT F3 Rubric version
— searched DID Core §5, §8, §9, §10; no policy version field

https://www.w3.org/TR/did-core/

ABSENT F4 Evidence
— searched DID Core §5, §8, §9, §10; no input-digest field

https://www.w3.org/TR/did-core/

ABSENT F5 Approver
— searched DID Core §5, §8, §9, §10; no human-approver field

https://www.w3.org/TR/did-core/

ABSENT F6 Challenge
— searched DID Core §5, §8, §9, §10; no dispute/challenge state

https://www.w3.org/TR/did-core/

0/6 AI Verify (Singapore IMDA / AI Verify Foundation) v2.2.1 · lane 4, Agent governance toolkits

https://raw.githubusercontent.com/aiverify-foundation/aiverify/main/aiverify-apigw/aiverify_apigw/models/test_result_model.py

OUTSIDE F1 Agent
TestResultModel: "algorithm_id: Mapped[int] = mapped_column(ForeignKey(\"algorithm.id\"))" / "algorithm: Mapped[\"AlgorithmModel\"] = relationship()" and "model_id: Mapped[int] = mapped_column(ForeignKey(\"test_model.id\"))"

.../models/test_result_model.py

ABSENT F2 Authority
Read test_result_model.py in full (55 lines) and test_run_model.py, test_artifact_model.py, test_dataset_model.py. No column expresses granted decision scope or delegation.

.../aiverify-apigw/aiverify_apigw/models/

OUTSIDE F3 Rubric version
TestResultModel: "version: Mapped[Optional[str]] = mapped_column(String(256))" — the algorithm version, Optional

.../models/test_result_model.py

OUTSIDE F4 Evidence
TestDatasetModel: "zip_hash: Mapped[Optional[str]]" — an optional hash on a *separate* table; the result row references datasets only by foreign key: "test_dataset_id: Mapped[int] = mapped_column(ForeignKey(\"test_dataset.id\"))"

.../models/test_dataset_model.py
.../models/test_result_model.py

OUTSIDE F5 Approver
TestResultModel: "user_id: Mapped[Optional[int]] = mapped_column(ForeignKey(\"user.id\"))" / "user: Mapped[Optional[\"UserModel\"]] = relationship()"

.../models/test_result_model.py

ABSENT F6 Challenge
The four model files above searched for challenge, dispute, appeal, contest, override. No occurrences.

.../aiverify-apigw/aiverify_apigw/models/

0/6 Arize Phoenix / OpenInference semantic conventions spec @ 18de978 (2026-08-27) · lane 4, Agent governance toolkits

https://raw.githubusercontent.com/Arize-ai/openinference/main/spec/semantic_conventions.md

OUTSIDE F1 Agent
"agent.name | String | researcher | The name of the agent that this span represents."

.../spec/semantic_conventions.md

ABSENT F2 Authority
Enumerated the full attribute table. Greps for authoriz, delegat, permission, scope, approv returned no attribute.

.../spec/semantic_conventions.md

OUTSIDE F3 Rubric version
"evaluation.metadata | JSON String | "{\"rubric_version\":\"2\"}" | Additional result or judge data"

.../spec/semantic_conventions.md

OUTSIDE F4 Evidence
"document.id", "document.content", "input.value" — and greps for hash, digest, checksum across the whole spec return zero results

.../spec/semantic_conventions.md

OUTSIDE F5 Approver
"evaluation.annotator_kind | String | "HUMAN" | Judge kind: HUMAN, LLM, CODE, or custom" and "evaluation.identifier | String | "reviewer-42" | Stable result ID for the same name and target"

.../spec/semantic_conventions.md

ABSENT F6 Challenge
Full spec searched for challenge, dispute, appeal, contest, override, supersede. No occurrences.

.../spec/semantic_conventions.md

0/6 ISO/IEC 42001:2023 ed. 1 (2023) · lane 4, Agent governance toolkits

https://www.iso.org/standard/42001.html

UNVERIFIED F1 Agent
— no primary source obtained

—

UNVERIFIED F2 Authority
—

—

UNVERIFIED F3 Rubric version
—

—

UNVERIFIED F4 Evidence
—

—

UNVERIFIED F5 Approver
—

—

UNVERIFIED F6 Challenge
—

—

0/6 LangSmith run / feedback schema langsmith-sdk v0.11.2 · lane 4, Agent governance toolkits

https://raw.githubusercontent.com/langchain-ai/langsmith-sdk/main/python/langsmith/schemas.py

OUTSIDE F1 Agent
RunBase: "serialized: Optional[dict] = None" / """Serialized object that executed the run for potential reuse.""" — and "run_type: str" / """The type of run, such as tool, chain, llm, retriever, embedding, prompt, parser."""

.../python/langsmith/schemas.py

ABSENT F2 Authority
Searched all 60+ classes in schemas.py for authority, delegat, scope, permission, capability. No field expresses what the run was permitted to decide.

.../python/langsmith/schemas.py

OUTSIDE F3 Rubric version
RunBase.revision_id property: """Retrieve the revision ID (if any).""" → return self.metadata.get("revision_id") — i.e. a free-form key inside extra["metadata"]. Rubrics themselves are queue-level config: AnnotationQueueWithDetails: "rubric_instructions: Optional[str] = None" / """The rubric instructions for the annotation queue."""

.../python/langsmith/schemas.py

OUTSIDE F4 Evidence
RunBase: "inputs: dict = Field(default_factory=dict)" / """Inputs used for the run."""

.../python/langsmith/schemas.py

OUTSIDE F5 Approver
FeedbackSourceBase: """Base class for feedback sources. This represents whether feedback is submitted from the API, model, human labeler, etc.""" with "user_id: Optional[Union[UUID, str]] = None"

.../python/langsmith/schemas.py

OUTSIDE F6 Challenge
FeedbackBase: "correction: Union[str, dict, None] = None" / """Correction for the run.""" and "comment: Optional[str] = None" / """Comment or explanation for the feedback."""

.../python/langsmith/schemas.py

0/6 MLflow 3 GenAI assessments v3.15.2 · lane 4, Agent governance toolkits

https://raw.githubusercontent.com/mlflow/mlflow/master/mlflow/entities/assessment.py

OUTSIDE F1 Agent
AssessmentSourceType: "Available source types: - HUMAN: Assessment performed by a human evaluator - LLM_JUDGE: Assessment performed by an LLM-as-a-judge (e.g., GPT-4) - CODE: Assessment performed by deterministic code/heuristics - SOURCE_TYPE_UNSPECIFIED: Default when source type is not specified"

.../mlflow/entities/assessment_source.py

ABSENT F2 Authority
Read assessment.py and assessment_source.py in full. No field expresses what the judging party was permitted to decide.

.../mlflow/entities/

ABSENT F3 Rubric version
Assessment carries "name: str" (the scorer name) and "metadata: dict[str, str] | None = None" (free-form). SerializedScorer carries only "mlflow_version: str = mlflow.__version__" and "serialization_version: int = _SERIALIZATION_VERSION" — the MLflow library version and the serialization format version, neither of which versions the rubric. No rubric-version field exists in either file.

.../mlflow/entities/assessment.py
.../mlflow/genai/scorers/base.py

OUTSIDE F4 Evidence
Assessment: "trace_id: str | None = None" and "span_id: str | None = None" — the assessment points at a trace by id; the inputs live in the trace as raw content, and no digest field exists on either side

.../mlflow/entities/assessment.py

OUTSIDE F5 Approver
AssessmentSource: "source_id: An identifier for the source, e.g. user ID or LLM judge ID." with the documented example "source_type=AssessmentSourceType.HUMAN, # or \"HUMAN\"" / "source_id=\"bob@example.com\","

.../mlflow/entities/assessment_source.py

OUTSIDE F6 Challenge
Assessment: "# The ID of the assessment which this assessment overrides." / "overrides: str | None = None" and "# Whether this assessment is valid (i.e. has not been overridden). # This should not be set by the user, it is automatically set by the backend." / "valid: bool | None = None"

.../mlflow/entities/assessment.py

0/6 NIST AI RMF 1.0 (AI 100-1) + NIST AI 600-1 100-1 Jan 2023; 600-1 Jul 2024 · lane 4, Agent governance toolkits

https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

N/A F1 Agent
out of scope: the framework defines outcomes, not record fields

NIST.AI.100-1.pdf

N/A F2 Authority
same

NIST.AI.100-1.pdf

N/A F3 Rubric version
same

NIST.AI.100-1.pdf

N/A F4 Evidence
same

NIST.AI.100-1.pdf

N/A F5 Approver
same

NIST.AI.100-1.pdf

N/A F6 Challenge
same — appeal is required as an organisational capability, not as a state on a record

NIST.AI.600-1.pdf

0/6 NVIDIA NeMo Guardrails logging v0.24.0 · lane 4, Agent governance toolkits

https://raw.githubusercontent.com/NVIDIA-NeMo/Guardrails/develop/nemoguardrails/logging/explain.py

OUTSIDE F1 Agent
LLMCallInfo: "llm_model_name: Optional[str] = Field(default=\"unknown\", description=\"The name of the model use for the LLM call.\")" and "llm_provider_name: Optional[str] = Field(default=\"unknown\", description=\"The provider of the model used for the LLM call, e.g. 'openai', 'nvidia'.\")"

.../nemoguardrails/logging/explain.py

ABSENT F2 Authority
Read explain.py in full (100 lines) and enumerated every field of GenerationLogOptions, ExecutedAction, ActivatedRail, GenerationStats, GenerationLog, GenerationResponse in options.py. No field expresses granted scope or delegation.

.../nemoguardrails/logging/explain.py
.../rails/llm/options.py

ABSENT F3 Rubric version
ActivatedRail records only "type: str = Field(description=\"The type of the rail that was activated, e.g., input, output, dialog.\")" and "name: str = Field(description=\"The name of the rail, i.e., the name of the flow implementing the rail.\")". No version of the rails configuration is recorded anywhere in either file.

.../rails/llm/options.py

OUTSIDE F4 Evidence
LLMCallInfo: "prompt: Optional[str] = Field(default=None, description=\"The prompt that was used for the LLM call.\")" — verbatim text, never a digest

.../nemoguardrails/logging/explain.py

ABSENT F5 Approver
Both files searched for approv, reviewer, human, sign. No occurrences.

.../logging/explain.py
.../rails/llm/options.py

ABSENT F6 Challenge
Both files searched for challenge, dispute, appeal, override. No occurrences.

.../logging/explain.py
.../rails/llm/options.py

0/6 Open Policy Agent decision logs v1.20.1 · lane 4, Agent governance toolkits

https://raw.githubusercontent.com/open-policy-agent/opa/main/docs/docs/management-decision-logs.md

OUTSIDE F1 Agent
"[_].labels | object | Set of key-value pairs that uniquely identify the OPA instance." and "[_].requested_by | string | Identifier for client that executed policy query, e.g., the client address."

.../management-decision-logs.md

ABSENT F2 Authority
Searched the full decision-log field table (24 documented fields, lines 63–84) plus the whole document for delegat, authority, scope, capability. No field describes what the deciding party was permitted to decide.

.../management-decision-logs.md

OUTSIDE F3 Rubric version
"[_].bundles[_].revision | string | Revision of the bundle at the time of evaluation."

.../management-decision-logs.md

OUTSIDE F4 Evidence
"[_].input | any | Input data provided in the policy query." — plus "[_].erased | array[string] | Set of JSON Pointers specifying fields in the event that were erased."

.../management-decision-logs.md

ABSENT F5 Approver
Same field table searched for approv, sign-off, reviewer, human. No occurrences.

.../management-decision-logs.md

ABSENT F6 Challenge
Same document searched for challenge, dispute, appeal, contest. No occurrences.

.../management-decision-logs.md

0/6 OpenTelemetry GenAI semantic conventions semantic-conventions-genai main (base semconv v1.44.0) · lane 4, Agent governance toolkits

https://raw.githubusercontent.com/open-telemetry/semantic-conventions-genai/main/docs/gen-ai/gen-ai-agent-spans.md

OUTSIDE F1 Agent
"gen_ai.agent.id | Development | Conditionally Required If applicable. | string | The stable unique identifier of the invoked GenAI agent."

.../docs/gen-ai/gen-ai-agent-spans.md

ABSENT F2 Authority
Enumerated every gen_ai.* attribute in both span documents (≈70 distinct attributes). None expresses granted scope, delegation, or permission. Greps for authoriz, approv, policy returned zero attribute hits.

.../docs/gen-ai/ (both files)

ABSENT F3 Rubric version
Same enumeration and same greps: there is no policy, rubric, or governing-rules attribute of any kind. gen_ai.agent.version exists but versions the agent, not the rules it applied.

.../docs/gen-ai/ (both files)

OUTSIDE F4 Evidence
"gen_ai.system_instructions | Development | Opt-In | any | The system message or instructions provided to the GenAI model separately from the chat history." — and gen_ai.input.messages, carrying content verbatim

.../docs/gen-ai/gen-ai-agent-spans.md

ABSENT F5 Approver
Same enumeration; no human-identity or sign-off attribute exists.

.../docs/gen-ai/ (both files)

ABSENT F6 Challenge
Same enumeration; greps for challenge, dispute, appeal, contest returned zero.

.../docs/gen-ai/ (both files)

0/6 Weights & Biases Weave v0.53.7 · lane 4, Agent governance toolkits

https://raw.githubusercontent.com/wandb/weave/master/weave/trace_server/trace_server_interface.py

OUTSIDE F1 Agent
CallSchema: "# Name of the calling function (op)" / "op_name: str", with "# WB Metadata" / "wb_user_id: str | None = None"

.../weave/trace_server/trace_server_interface.py

ABSENT F2 Authority
Searched the full 140 KB interface for authority, delegat, permission, scope, capability. No field expresses granted decision scope.

.../weave/trace_server/trace_server_interface.py

OUTSIDE F3 Rubric version
FeedbackCreateReq: "runnable_ref: str | None = Field(default=None, examples=["weave:///entity/project/op/name:digest"])" — the scoring op is referenced by content digest, but the field is optional and the feedback row is unsigned

.../weave/trace_server/trace_server_interface.py

OUTSIDE F4 Evidence
CallSchema: "# Inputs" / "inputs: dict[str, Any]" — raw. Content addressing exists only for stored objects: ObjSchemaForInsert.expected_digest: "Client-computed digest for server-side validation. If provided, the server will verify it matches the server-computed digest."

.../weave/trace_server/trace_server_interface.py

OUTSIDE F5 Approver
FeedbackCreateReq: "creator: str | None = Field(default=None, examples=["Jane Smith"])" and AnnotationQueueItemSchema: "annotator_user_id: str | None = ( None # wb_user_id of annotator who owns the most recent state (nullable) )"

.../weave/trace_server/trace_server_interface.py

ABSENT F6 Challenge
The complete review-lifecycle state set is AnnotationState = Literal["unstarted", "in_progress", "completed", "skipped"] (weave/trace_server/common_interface.py:96). There is no disputed, contested, or overridden state.

.../weave/trace_server/common_interface.py

0/6 ACM Artifact Review and Badging v1.1, 24 Aug 2020 · lane 5, Reproducibility badging and re-execution

https://www.acm.org/publications/policies/artifact-review-and-badging-current

ABSENT F1 Agent
(no automated- or AI-evaluator concept anywhere on the page; the page speaks only of "an independent audit" and "a person or team other than the authors")

archived ACM v1.1 page

OUTSIDE F2 Authority
"Editors-in-Chiefs and Conference Steering Committee Chairs (or an appropriate SIG Chair should a conference not have an extant steering committee) will have the authority to award these badges post-publication if warranted."

archived ACM v1.1 page

OUTSIDE F3 Rubric version
"Artifact Review and Badging Version 1.1 - August 24, 2020" — and the version rides on the badge label itself: "Results Reproduced v1.1", "Artifacts Evaluated – Functional v1.1", "Artifacts Available v1.1"

archived ACM v1.1 page

OUTSIDE F4 Evidence
"For Results Validated, a peer-reviewed publication which reports the replication or reproduction must be submitted as evidence, and if awarded, the badge will contain a link to this paper."

archived ACM v1.1 page

OUTSIDE F5 Approver
"badges included in PDFs and in ACM Digital Library metadata should be linked to a brief explanation of the particular review process which led to the awarding of the badge."

archived ACM v1.1 page

ABSENT F6 Challenge
(searched the full archived v1.1 page for "dispute", "appeal", "revoke", "challenge", "withdraw" — no match)

archived ACM v1.1 page

0/6 CODECHECK config spec 1.0 · lane 5, Reproducibility badging and re-execution

https://codecheck.org.uk/spec/config/1.0/

ABSENT F1 Agent
(searched spec 1.0 in full; the only actor field is codechecker, a human with an ORCID — no automated-agent field)

https://codecheck.org.uk/spec/config/1.0/

OUTSIDE F2 Authority
Principle 1: "Codecheckers record but don't investigate or fix."

https://codecheck.org.uk/

OUTSIDE F3 Rubric version
"SHOULD include a root-level node version" — whose value is the spec URI, e.g. https://codecheck.org.uk/spec/config/1.0/

https://codecheck.org.uk/spec/config/1.0/

OUTSIDE F4 Evidence
"MUST have a root-level sequence (i.e., a list) of files called manifest"; each entry "MUST have a node file" and "MAY have a node comment"

https://codecheck.org.uk/spec/config/1.0/

OUTSIDE F5 Approver
"MUST include minimal metadata about the codechecker in a root-level sequence codechecker"; each "MUST have one node name" and "SHOULD have a child ORCID"

https://codecheck.org.uk/spec/config/1.0/

ABSENT F6 Challenge
(searched spec 1.0 and the community-process pages for "dispute", "appeal", "challenge", "revoke" — no match)

https://codecheck.org.uk/spec/config/1.0/

0/6 CORE-Bench arXiv:2409.11363v2, 22 Jun 2026 · lane 5, Reproducibility badging and re-execution

http://export.arxiv.org/api/query?id_list=2409.11363

OUTSIDE F1 Agent
"We evaluated two baseline agents: the general-purpose AutoGPT and a task-specific agent called CORE-Agent. We tested both variants using two underlying language models: GPT-4o and GPT-4o-mini."

arXiv API
2409.11363v2

N/A F2 Authority
out of scope — a benchmark grants no decision authority to the agent it measures

arXiv API
2409.11363v2

UNVERIFIED F3 Rubric version
—

—

UNVERIFIED F4 Evidence
—

—

N/A F5 Approver
out of scope — no release-approval step exists; scoring is automated ("We provide an evaluation system to measure the accuracy of agents in a fast and parallelizable way")

arXiv API
2409.11363v2

N/A F6 Challenge
out of scope — a benchmark score is not a record with a lifecycle

arXiv API
2409.11363v2

0/6 COS Open Practices Badges v1.1, 24 Jun 2015 · lane 5, Reproducibility badging and re-execution

https://api.osf.io/v2/wikis/64akh/content/

ABSENT F1 Agent
(searched all three wiki pages; the awarding actors are "certifying organizations", "reviewers", "an organization staff member" — no automated party)

OSF wiki 64akh

OUTSIDE F2 Authority
"Any organization can issue badges as long as the process and practices are transparent. Reputation of certifying organizations will depend on the quality and reliability of their certification process. Because of this, when badges are mentioned or displayed, the awarding entity must be indicated or obvious."

OSF wiki 64akh

OUTSIDE F3 Rubric version
"Version 1.1; 24 June 2015" (final line of the awarding specification)

OSF wiki 64akh

OUTSIDE F4 Evidence
Open Data disclosure item 1: "Provide the URL, DOI, or other permanent path for accessing the data in a public, open access repository."

OSF wiki 64akh

OUTSIDE F5 Approver
"Badges awarded following peer review receive an additional 'PR' notation."

OSF wiki 64akh

OUTSIDE F6 Challenge
"The body that certified a badge is likewise empowered to revoke it. For example, a certification body might provide a mechanism for community members to report that the data are no longer available for an article with an Open Data badge. Following verification of the community report, the badge could be revoked."

OSF wiki xdesg
FAQ item 10

0/6 Code Ocean (substitute for eLife RDS) OSL guide, live 2026-09-01 · lane 5, Reproducibility badging and re-execution

https://docs.codeocean.com/osl-guide/publishing-on-code-ocean/the-verification-process/code-oceans-verification-process-for-computational-reproducibility-and-quality

ABSENT F1 Agent
(searched the verification-process documentation; the verifier is "Code Ocean staff", with no automated-party field)

Code Ocean OSL guide
verification process

ABSENT F2 Authority
(same document; no granted-scope statement beyond the peer-review disclaimer)

Code Ocean OSL guide
verification process

ABSENT F3 Rubric version
(same document; requirements are stated as prose with no version or date on the checklist)

Code Ocean OSL guide
verification process

ABSENT F4 Evidence
(same document; no digests of inputs — capsules are identified by DOI of the form 10.24433/CO.<slug>.v<version>)

Code Ocean OSL guide
verification process

OUTSIDE F5 Approver
"Code Ocean staff check everything that is submitted for publication or peer review on the platform."

Code Ocean OSL guide
verification process

ABSENT F6 Challenge
(same document; no appeal or dispute path documented)

Code Ocean OSL guide
verification process

0/6 EU AI Act Article 12 Reg (EU) 2024/1689 as amended by Reg (EU) 2026/1744 · lane 5, Reproducibility badging and re-execution

https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R1689

ABSENT F1 Agent
(searched Article 12 in full; the logging subject is the system itself, and no log field identifies the deciding party)

archived CELEX:32024R1689

ABSENT F2 Authority
(searched Article 12 in full; no granted-scope or delegation field — human oversight is Article 14, outside the record)

archived CELEX:32024R1689

ABSENT F3 Rubric version
(searched Article 12 in full; no policy- or rubric-version field)

archived CELEX:32024R1689

OUTSIDE F4 Evidence
Art. 12(3): "the logging capabilities shall provide, at a minimum: … (b) the reference database against which input data has been checked by the system; (c) the input data for which the search has led to a match;"

archived CELEX:32024R1689

OUTSIDE F5 Approver
Art. 12(3)(d): "the identification of the natural persons involved in the verification of the results, as referred to in Article 14(5)."

archived CELEX:32024R1689

ABSENT F6 Challenge
(searched Article 12 in full; no dispute, challenge or correction state. Rights to complain and to an explanation exist at Articles 85 and 86, but they act on the authority and the deployer, not on the log record)

archived CELEX:32024R1689

0/6 FAIRsoft / OpenEBench Bioinformatics 40(8) btae464, 2024 · lane 5, Reproducibility badging and re-execution

https://pmc.ncbi.nlm.nih.gov/articles/PMC11330317/

OUTSIDE F1 Agent
"For each indicator, an algorithm was further designed and implemented to decide whether that indicator was being fulfilled or not."

https://pmc.ncbi.nlm.nih.gov/articles/PMC11330317/

ABSENT F2 Authority
(searched the article; no delegation, scope or authority model — the algorithm decides unconditionally)

https://pmc.ncbi.nlm.nih.gov/articles/PMC11330317/

UNVERIFIED F3 Rubric version
—

—

ABSENT F4 Evidence
(searched the article for hashes/digests of evaluated software; metadata is drawn from eleven named sources — bio.tools, Bioconda, Bioconductor, Galaxy ToolShed, SourceForge, Galaxy Europe, GitHub, Bitbucket, OpenEBench, PubMed, Europe PMC, Wikidata — by reference, not by digest)

https://pmc.ncbi.nlm.nih.gov/articles/PMC11330317/

ABSENT F5 Approver
(searched the article; assessment is fully automated, with no human approval or sign-off step)

https://pmc.ncbi.nlm.nih.gov/articles/PMC11330317/

ABSENT F6 Challenge
(searched the article; no appeal or dispute path for a developer who disagrees with a score)

https://pmc.ncbi.nlm.nih.gov/articles/PMC11330317/

0/6 NISO RP-31-2021 RP-31-2021, 28 Jan 2021 · lane 5, Reproducibility badging and re-execution

https://groups.niso.org/higherlogic/ws/public/download/24810/RP-31-2021_Reproducibility_Badging_and_Definitions.pdf

ABSENT F1 Agent
(searched the full 21-page PDF for "agent", "automated", "AI", "algorithm" — the only automated actor named is a company, "The company Code Ocean certifies that the results can be computationally reproduced")

NISO RP-31-2021 PDF

OUTSIDE F2 Authority
"The determination of what objects are 'relevant' to a research publication is in the hands of the editorial board or leadership members of the community, in addition to the authors themselves."

NISO RP-31-2021 PDF §2.1

OUTSIDE F3 Rubric version
Recommended minimum badge metadata fields include "Version of the schema or specification" and "Review criteria URI (for the ROR badge)"; the whole list is SHOULD-level: "Badge metadata should be stored in a machine-readable format and available via hyperlink from the issued badge."

NISO RP-31-2021 PDF §3.2

OUTSIDE F4 Evidence
"Optional: validation hash or cryptographic key"

NISO RP-31-2021 PDF §3.2

OUTSIDE F5 Approver
"Issuing organization" (recommended minimum badge metadata field) — and "when badges are mentioned or displayed, the awarding entity must be indicated or obvious"

NISO RP-31-2021 PDF §3.2

OUTSIDE F6 Challenge
"For a variety of reasons, it should be possible to revoke a badge. A revoked badge should not disappear but be replaced with information regarding the revocation and why (in the manner of a retraction)."

NISO RP-31-2021 PDF §3.6

0/6 Open Badges 3.0 (1EdTech) 3.0, doc v1.4.5, 29 Jun 2026 · lane 5, Reproducibility badging and re-execution

https://www.imsglobal.org/spec/ob/v3p0/

ABSENT F1 Agent
(searched §B.1 data models in full; the issuer is a ProfileRef describing "the individual, entity, or organization that issued the credential" — there is no field distinguishing an automated from a human issuer, and no field for a deciding agent separate from the issuer)

https://www.imsglobal.org/spec/ob/v3p0/

ABSENT F2 Authority
(searched §B.1 class list — Achievement, AchievementCredential, AchievementSubject, Criteria, EndorsementCredential, Evidence, Profile, Related, Result, TermsOfUse, CredentialStatus … — no delegation or granted-scope model)

https://www.imsglobal.org/spec/ob/v3p0/

OUTSIDE F3 Rubric version
Criteria carries only id "The URI of a webpage that describes in a human-readable format the criteria for the achievement" [0..1] and narrative [0..1] — both optional, and neither is a version

https://www.imsglobal.org/spec/ob/v3p0/ §B.1.6

OUTSIDE F4 Evidence
evidence is [0..*]; Evidence.id is "The URL of a webpage presenting evidence of achievement or the evidence encoded as a Data URI. The schema of the webpage is undefined." [0..1]

https://www.imsglobal.org/spec/ob/v3p0/ §B.1.9

ABSENT F5 Approver corrected from INSIDE by the independent pass (finding F-1) — the quotation below is the original reasoning, kept in place
issuer — "A description of the individual, entity, or organization that issued the credential." multiplicity [1]; and "at least one proof mechanism, and the details necessary to evaluate that proof, MUST be expressed for a credential to be a verifiable credential"

https://www.imsglobal.org/spec/ob/v3p0/ §B.1.2
§B.1.7

OUTSIDE F6 Challenge
credentialStatus is [0..1]; "A Credential is revoked if the credentialStatus property is present, and the type of the CredentialStatus object is 'BitstringStatusListEntry', and if the Credential has been revoked as shown in Bitstring Status List v1.0."

https://www.imsglobal.org/spec/ob/v3p0/ §9.1

0/6 ReScience C article metadata.yaml, master · lane 5, Reproducibility badging and re-execution

https://raw.githubusercontent.com/ReScience/template/master/metadata.yaml

ABSENT F1 Agent
(searched metadata.yaml field by field; contributors carry role: editor and role: reviewer only — no automated-party field)

ReScience `metadata.yaml`

OUTSIDE F2 Authority
contributors: - name: orcid: role: editor / role: reviewer / role: reviewer

ReScience `metadata.yaml`

ABSENT F3 Rubric version
(searched metadata.yaml and the editorial guidelines; the acceptance criteria live on an unversioned web page and no field records which version was applied)

ReScience `metadata.yaml`

OUTSIDE F4 Evidence
"Code URL and DOI/SWH (url is mandatory for replication, doi after acceptance) — You can get a DOI for your code from Zenodo, or an SWH identifier from Software Heritage." with fields code: - url: - doi: - swh:

ReScience `metadata.yaml`

OUTSIDE F5 Approver
contributors: with name, orcid, role: editor — "This information will be provided by the editor"

ReScience `metadata.yaml`

OUTSIDE F6 Challenge
"For a successful replication, it should be prefixed with '[Re]'"; "For a failed replication, it should be prefixed with '[¬Re]'"; and review: - url: = "For example, the URL of the GitHub issue where review actually occured"

ReScience `metadata.yaml`

0/6 W3C Bitstring Status List v1.0, W3C Rec 15 May 2025 · lane 5, Reproducibility badging and re-execution

https://www.w3.org/TR/vc-bitstring-status-list/

N/A F1 Agent
out of scope — the specification models credential status only, not the actor who reached a verdict

https://www.w3.org/TR/vc-bitstring-status-list/

N/A F2 Authority
out of scope — no delegation model

https://www.w3.org/TR/vc-bitstring-status-list/

N/A F3 Rubric version
out of scope

https://www.w3.org/TR/vc-bitstring-status-list/

N/A F4 Evidence
out of scope

https://www.w3.org/TR/vc-bitstring-status-list/

N/A F5 Approver
out of scope — the status-list credential has an issuer who signs it, but there is no approver of the underlying claim

https://www.w3.org/TR/vc-bitstring-status-list/

OUTSIDE F6 Challenge
"revocation: Used to cancel the validity of a verifiable credential. This status is not reversible."; "suspension: Used to temporarily prevent the acceptance of a verifiable credential. This status is reversible."; "message: Used to convey an arbitrary message related to the status of the verifiable credential."; "the issuer of a verifiable credential and the issuer of an associated BitstringStatusListCredential might not be the same"

https://www.w3.org/TR/vc-bitstring-status-list/

0/6 Zenodo / DataCite Zenodo General Policies v1.0; DataCite Schema 4.6 · lane 5, Reproducibility badging and re-execution

https://about.zenodo.org/policies/

ABSENT F1 Agent
(searched Zenodo General Policies and the DataCite 4.6 property list — 20 properties, none an actor beyond Creator/Contributor/Publisher)

https://about.zenodo.org/policies/

ABSENT F2 Authority
(same documents; no delegation or scope model)

https://about.zenodo.org/policies/

ABSENT F3 Rubric version
(DataCite 4.6 has a Version property, Optional — but it versions the deposited resource, not any governing rule set)

https://datacite-metadata-schema.readthedocs.io/en/4.6/properties/overview/

OUTSIDE F4 Evidence
"All data files are stored along with a MD5 checksum of the file content. Files are regularly checked against their checksums to assure that file content remains constant."

https://about.zenodo.org/policies/

ABSENT F5 Approver
(searched both; deposit is self-service, with no approval or sign-off step)

https://about.zenodo.org/policies/

OUTSIDE F6 Challenge
"If the uploaded research object must later be withdrawn, the reason for the withdrawal will be indicated on a tombstone page, which will henceforth be served in its place… The DOI and the URL of the original object are retained."

https://about.zenodo.org/policies/

Independent verification

The verifying agent produced none of the survey data. Five of its six corrections moved a cell out of INSIDE; the sixth moved one from ABSENT to OUTSIDE. Every one of them makes a prior system look stronger, or this survey's own reasoning look weaker. None strengthened the claim the survey set out to test.

15 of 61 records were re-checked (25%), drawn by random.sample with seed 20260901 fixed before the verifying agent started, so a hard row could not be swapped out. It found 6 verdicts to overturn.

findingrecordfieldwasis
F-1 Open Badges 3.0 (1EdTech) F5 Approver INSIDE ABSENT
F-2 TUF (The Update Framework) F3 Rubric version INSIDE ABSENT
F-3 Notary Project / Notation F4 Evidence INSIDE ABSENT
F-4 TUF (The Update Framework) F4 Evidence INSIDE ABSENT
F-5 KEYTRANS (IETF) F3 Rubric version INSIDE OUTSIDE
F-7 SPIFFE/SPIRE SVID F2 Authority ABSENT OUTSIDE

Known limits — read before citing

  • ABSENT is only as deep as the documents fetched. A field living in an unfetched sibling specification would have been missed. The verifier says so about its own pass too.
  • Signature coverage was read from specification text. It was not proven by mutating a real artifact and observing verification fail.
  • ISO/IEC 42001 is entirely unverified — iso.org returned 403 to every automated client tried. No claim about it should rest on this survey.
  • acm.org and eur-lex.europa.eu block automated clients; those rows were read through dated Internet Archive captures, with timestamps recorded in the lane file.
  • One quotation was found misattributed: a sentence in lane 1's in-toto row is verbatim slsa.dev text, not in-toto's README. The cell is ABSENT, which needs no quote, so no verdict moves — but the other SLSA-adjacent rows in lane 1 deserve a spot-check.
  • The count of 61 includes Sigstore twice (bundle format in lane 1, Rekor in lane 2) and the EU AI Act twice (two implementations in lane 2, the regulation itself in lane 5). These are distinct artifacts, but anyone quoting "61" should be ready to say so.

Built from the five lane files by data/prior_art_survey/scripts/build_from_lanes.py, which fails rather than choosing a winner when the summary grid and a per-record table disagree. The dataset behind this page.