Review External

Optional: if the artifact being reviewed here IS another party's already-signed verdict proof (a verdict-of-verdict re-review), pass that proof's full signed event — the exact {id, pubkey, created_at, kind, tags, content, sig} block from its own /prove or /review(sign=true) response. We independently re-verify it ourselves (schnorr signature + decision_ref recompute — never your claim about it) before its source_class can affect this call's own: the outer verdict's source_class is capped at the inner verdict's, never upgraded by it (an independent_mediator outer call reviewing an agent_reported inner verdict stays agent_reported). If the inner event fails to verify, this call proceeds at agent_reported regardless of your own registry status (fail-closed) — an unverifiable amplification claim never gets the benefit of the doubt. One hop only: we do not walk the inner verdict's own related_decision_ref transitively. HONEST SCOPE: we verify the cited event's own authenticity and source_class — NOT that it is actually, topically what this call's artifact claims to be re-reviewing. related_decision_ref being present proves the cited proof is authentic and was accounted for, not that it's genuinely related.

Optional (policy v22, mitre-atlas/atlas-data#20): the caller's MEDIATOR proves control of its own key. Object {key_url, public_key_ed25519_b64, requested_at, nonce, signature_ed25519_b64}: the mediator signs (Ed25519) the RFC 8785 JCS bytes of {schema: 'invinoveritas.mediator_request.v1', artifact_hash (sha256 hex of the exact artifact text), artifact_type, requested_at (unix s, within 600 s of now), nonce (8-128 ASCII)} with a key published at key_url (https, the mediator's own domain; the document lists it as public_key_ed25519_b64 or keys[].public_key_ed25519_b64). Requires sign=true. Checked BEFORE any charge (422 if it fails); carried in the proof and bound as mediator_attestation_hash; /verify-proof re-checks it offline. Establishes control of the published key at issue time -- it does NOT change source_class or establish independence.

Optional (verdict-relay/v2, garyyang-finchip/task-token-standard#2): also return a BIP-340 signature an ERC-8414 InvinoveritasVerdictAuthoritySigned contract verifies on-chain, so anyone can submit the ruling. Object {chain_id, authority, task_contract, token_id, submission_id, task_version, result_hash, task_document}. Requires sign=true. result_hash MUST equal sha256 of the exact artifact text reviewed, and task_document is the plaintext task document whose sha256 is the kernel's taskOf(tokenId).tdHash; it is put into the review context so the verdict is judged against it (422 before any charge if invalid). approved and decision_ref are never caller-supplied: approve -> true, reject -> false; approve_with_concerns and defer get no relay signature. Response field verdict_relay {digest, signature, approved, decision_ref, fields, reissue_token}. The task document is treated as untrusted data (<= 8000 chars). If signing fails after the charge, re-issue free within 7 days with POST /review/verdict-relay/reissue {event_id, reissue_token, verdict_relay}.

Optional (policy v20, agentrust-io/trace-spec#398 prototype): a structured claim about the proof passed in related_proof_event -- a non-empty subset of {artifact_hash, verdict, verified_at, policy_version, decision_ref}, string/integer values. We compare it by exact equality with the referenced proof's own signed fields (which we independently re-verify) and bind the claims hash, comparison version and RESULT (matched | mismatched | missing_proof | unverifiable_proof; not_supplied when omitted) into decision_ref. Exact equality establishes that the restatement is faithful; it does not establish that the referenced verdict is relevant to, authorizes, or is true of this call. A mismatch never upgrades context_provenance.

Optional: a requester-signed submission_commitment (v0) proving YOU attempted THIS exact submission: {type:'submission_commitment', version:'v0', request_digest (sha256 of the artifact text exactly as we hash it), attempt_id, sent_at, requester_pubkey (BIP-340 x-only), sig}. It is its own object, signed with your key and kept by you -- independently meaningful even if no receipt from us ever exists. If it verifies and commits to exactly this artifact, the admission receipt binds to it by hash (submission_commitment_ref, folded into receipt_hash and so into the Merkle/OTS checkpoints). It proves attempted submission ONLY; it never implies we admitted, reviewed or approved anything. The response's admission_receipt.submission_commitment_status is one of: absent | verified | invalid:<reason> | duplicate_of_admission:<n> (one attempt_id binds to one admission). An invalid commitment does NOT block the review; it just is not bound. Shape origin: eth-magicians t/29563 (chugarchugarr). Tooling + vectors: github.com/babyblueviper1/preaction-governance-conformance examples/submission-commitment.

Optional: claim a PREAUTHORIZED run slot {run_id, attempt_index (default 0)} created earlier with POST /admission-chain/slot by the same api key (formulary-systems Procedure Manifests v0.0.3 section 3). When valid, run_id, attempt_id = H(run_id, attempt_index) and the slot row's receipt_hash are folded into this admission's receipt_hash; one admission per attempt_id (unique), and attempt k>0 only after attempt k-1 has a chained NO_RESULT terminal AND the slot committed retry_on: ["NO_RESULT"] (an UNRESOLVED terminal consumes the run). admission_receipt.slot_status is claimed | invalid:<reason> | duplicate_attempt_of_admission:<n>. A bad slot never blocks the review; it is just not bound.

Optional: a coordinate naming real content to independently fetch and review, instead of trusting the artifact field's caller-supplied bytes. Real gap this closes (named by Dipankar Sarkar, 2026-08-12, trustless-ai working group): a hand-typed artifact and a hand-typed SUMMARY of one are indistinguishable to a reviewer that only ever sees pasted text — a summary has no coordinates that let anyone reproduce it. Two shapes, detected by which keys are present (not a separate discriminator field):

1. For artifact_type='code_diff'/'patch': {'repo': 'owner/name', 'base_sha': ..., 'head_sha': ...} — fetches https://github.com/{repo}/compare/{base_sha}...{head_sha}.diff ourselves (public repos only, no auth).
2. For artifact_type='onchain_action' (or any on-chain state read): {'chain_id': 8453 or 84532, 'block_number': <a specific pinned integer, NEVER the string 'latest' — 'latest' isn't reproducible on a later independent recompute>, 'contract_address': '0x...', 'calldata': '0x...', 'block_hash': <optional 0x-prefixed 32-byte hash>} — independently re-runs the exact eth_call at that pinned block via a public RPC and reviews the returned bytes. Deterministic and STRONGER than a git sha (Dipankar's own follow-up taxonomy, same day): anyone with an archive node re-runs the call pinned to that block and gets the identical bytes, because the execution itself is deterministic too, not just the storage. block_hash, if supplied, is cross-checked against the answering RPC's own block hash at that number and the call fails closed (422) on a mismatch — a block NUMBER alone isn't a stable identity until finalization, so this catches a reorg or a different chain view rather than silently reviewing the wrong fork (Dipankar's same-day follow-up, 2026-08-12). The returned artifact also records the resolved block_hash and which RPC endpoint answered, since public RPCs prune state — a re-fetch at this same block can start failing months later purely because it fell outside a node's retention window, which is not evidence the original claim was wrong; the result bytes captured at review time remain the source of truth either way.
3. For an on-chain EFFECT rather than a state read: {'chain_id': 8453 or 84532, 'tx_hash': '0x...'} — fetches the transaction receipt and DERIVES block_number, block_hash, contract_address, status and logs from it. Added 2026-08-24 to close a real seam shape 2 does not: shape 2's re-derivation is strong (EIP-1898 requireCanonical on eth_call, non-canonical fails closed, RPC set is ours not caller-nominated) but its COORDINATE is chosen by the party submitting the evidence, so an agent authorized to release escrow A can submit a truthful, canonically-pinned, independently re-derivable read of escrow B and every check passes. Under shape 3 the coordinate fields are OUTPUTS, never inputs; if you also send contract_address, block_number or block_hash they are treated as assertions, checked against the receipt, and a mismatch is a hard 422 rather than something reviewed. Canonicality is confirmed by re-fetching the block by hash and cross-checking its number and the transaction's inclusion in it. A REVERTED transaction (status 0x0) is returned with an explicit reverted: true and a note, not rejected — it is a real on-chain fact and often the disputed one. What shape 3 still does NOT establish, stated so it isn't read as more than it is: that this transaction is the one a given authorization or policy decision referred to. That binding belongs to the authorization layer's own preimage. In all cases the artifact field, if also sent, is discarded, never merged with the fetched content. artifact_hash and every downstream hash bind to the independently-fetched bytes, not what you sent. FAILS CLOSED: if the fetch fails (private repo, bad sha, unsupported chain_id, RPC error) the call returns an error rather than silently falling back to caller-supplied text — a silent fallback would defeat the property this field exists to provide. The response's artifact_provenance field discloses which mode a given verdict actually used ('independently_fetched_github', 'independently_fetched_onchain', 'independently_fetched_onchain_effect', or 'caller_supplied') — informational only as of this policy version, not yet bound into decision_ref (a live, already-adopted signing contract — extending its preimage needs its own careful version bump, tracked separately, not done in this same change). A third tier — witnessed capture, for content that genuinely can't be re-derived later (e.g. a revised/backfilled order-book quote) — already exists as a SEPARATE endpoint, /witness, rather than a mode of /review: it anchors a third party's exact claim bytes as-is, unjudged, distinct from /review's own independent judgment on a fetched-or-supplied artifact.

Optional: the exact real-world action this verdict authorizes — tool identity, materialized (not templated) arguments, and the id of the agent that will execute it. This is the piece named but explicitly deferred in artifact_source's own docstring above ('that binding belongs to the authorization layer's own preimage') — now built. Distinct from artifact (free text arguing FOR the action — recomputable via artifact_hash, but only as strong as whatever the caller chose to include) and from state_hash (a broader graph/agent-state commitment that is explicitly NOT bound into decision_ref — see its own docstring). Shape: {'tool': 'place_order', 'agent_id': 'your-stable-agent-id', 'args': {...materialized parameters...}} — any JSON object under ~8KB is accepted; this shape is a convention, not an enforced schema, and every sub-key is optional (absent ones simply don't produce their corresponding hash below). v14 (2026-08-31, delphisecurity/xaidr#1, anirudhraokotaru): tool and args are bound as SEPARATE preimage fields — action_binding_tool_hash = sha256(tool, raw UTF-8) and action_binding_args_hash = sha256(RFC-8785-JCS(args)) — rather than one opaque blob hash (v13's shape), so a verifier can actually assert 'same tool, different arguments' as a checkable statement instead of just seeing an opaque diff. agent_id is bound DIRECTLY as a plain string (action_binding_agent_id, not hashed — short ids gain nothing from hashing and lose direct readability) — same treatment as intended_verifier/intended_audience elsewhere on this endpoint. All three are bound into decision_ref (see decision_ref_preimage_fields in the response), so decision_ref commits to the exact action, not just the artifact text or the verdict conclusion — recomputing decision_ref without byte-identical tool/args/agent_id values produces a different hash. HONEST, NAMED LIMIT (not fixed by this field split, a real open question named by anirudhraokotaru): nothing stops a caller from submitting an UNDER-SPECIFIED action_binding (e.g. tool+side but not size) and getting an approval that's replayable across whatever dimension was omitted — that's a property of who controls what goes INTO the fingerprint, not how it's hashed once it's there. We hash exactly what you send and do not independently verify it matches what actually executes; a caller who wants that guarantee needs an in-process sensor emitting the fingerprint from the real call, not an external judgment layer like this one.