Governance-decision evidence as a composable layer in the Trust Record schema

[victor-davidenko]

Spec section affected

§3.1 (Logical schema — Trust Record field set), §4.3 (Bindings TRACE adds)

Problem

The policy field in §3.1 binds a policy hash and enforcement mode to the Trust Record. This proves which policy was in force during execution. It does not prove what governance decision that policy produced for a specific agent action, what the evaluation inputs were, or whether the decision record is independently verifiable with keys not controlled by the platform operator.

The tool_transcript field captures what tools were called, with what parameters, and what responses were returned. This proves what the agent did. It does not prove what governance evaluation was applied to each action before it was permitted or denied.

These are distinct evidence requirements. A runtime attestation proves the environment was intact and the policy was bound. A governance-decision record proves the per-action evaluation: what was requested, what policy was evaluated, what the decision was, and that the resulting record was not altered after evaluation. For cross-organizational AI agent interactions, a counterparty needs to verify both: (a) the runtime was trustworthy (covered by TRACE) and (b) the governance decision applied to a specific agent action was correctly recorded and is independently verifiable (not currently covered).

§4.3 lists four bindings TRACE adds on top of existing standards: policy claim, data_class claim, tool_transcript claim, and AI-agent execution profile. None of these bindings capture governance-decision-level evidence as a composable artifact that can be verified independently of the platform that produced it.

Proposed change

TRACE should define a composition interface in §4.3 that allows governance-decision evidence records to be referenced from or bound to a Trust Record. This would enable a Trust Record to link to a governance-decision evidence artifact carrying:

The governance policy identifier evaluated for a specific agent action
The evaluation inputs (request metadata, entity identifiers, classification results)
The governance decision outcome (permit, deny, modify, flag)
A cryptographic signature over the canonicalized decision record, produced with keys not controlled by the platform operator
A chain-integrity field linking the current decision record to the prior record, enabling tamper-evident sequences across the lifecycle of an agent session

This does not require TRACE to define the governance-decision evidence format itself. It requires TRACE to define how an external governance-decision evidence artifact, produced by a governance layer operating alongside the runtime, can be referenced from a Trust Record so that verifiers can validate both layers in a single verification pass.

In §3.1, this would appear as an optional governance_evidence field (or equivalent) carrying a reference URI, a digest of the governance-decision record, and the verification key identifier, following the same pattern TRACE already uses for transparency (URI + cryptographic anchor) and tool_transcript (hash + reference).

An existing open-source implementation of governance-decision evidence verification exists: github.com/scarpprotocol/scarp-verify (Apache 2.0, Go, zero external dependencies, offline verification, RFC 8785 canonicalization). The architectural requirements for governance-decision evidence are described in a peer-reviewed companion paper (DOI 10.5281/zenodo.21927017).

Backward compatibility

Non-breaking (new optional field, informative addition)

A composition interface for governance-decision evidence would be additive. Existing Trust Records remain valid. Verifiers that do not support governance-decision evidence ignore the new optional field. Verifiers that do support it gain the ability to validate both runtime attestation and per-action governance decisions in a single verification pass.

Motivation

Runtime attestation and governance-decision evidence address different regulatory and operational requirements:

The EU AI Act (high-risk obligations, effective December 2027) requires evidence of governance decisions applied to AI systems, not only evidence of runtime integrity. Article 12 mandates logging that enables verification of compliance at the decision level.
The OSAIA SAFE RFC review framework asks whether authorization assumptions were correct and whether the model recognized scope boundaries. These are governance-decision questions that runtime attestation alone cannot answer.
Contractual flow-down requirements already in force (e.g., Fannie Mae LL-2026-04, effective August 2026) require vendors to maintain AI governance records demonstrating policy enforcement at the per-action level.
Cross-organizational agent interactions require both parties to independently verify the other's governance decisions, not only their runtime environment. The principle stated in the TRACE announcement applies equally here: evidence that is portable, independently verifiable, and not controlled by the vendor producing it must extend to governance decisions, not only to runtime attestation.

Related issues or PRs

OSAIA SAFE RFC Issue #24: Lifecycle infrastructure dependencies (github.com/osaia/safe-rfc)
OSAIA SAFE RFC Issue #25: Identity infrastructure dependencies (github.com/osaia/safe-rfc)
OSAIA SAFE RFC Issue #26: Composition governance dependencies (github.com/osaia/safe-rfc)
Governance-decision evidence verifier: github.com/scarpprotocol/scarp-verify
Companion paper: DOI 10.5281/zenodo.21927017

[imran-siddique]

The distinction you draw is right, and the mechanism for it already exists. What is missing is smaller than what you have proposed, which is good news for you.

Where you are right

policy proves which policy was in force. tool_transcript proves what the agent did. Neither proves what evaluation was applied to a specific action before it was permitted, and for a cross-organisational counterparty those are genuinely different questions. Your (a) and (b) split is the correct one.

What already covers most of it

§3.1.2, merged in #197, is a references block whose whole purpose is binding a fact that lives outside the record to the record itself:

field	meaning
rel	relationship type, from a registered set
id	identifier of the referenced fact in the resolver's system
resolver	the party obliged to resolve id
retention	how long that party undertakes to keep it resolvable
digest	digest of the referenced object, when the producer holds it at issue time

Two registered values are already the shape you are asking for:

• authorized-intent, an authorization decided before execution and held in another system
• approval-outcome, an attributable human approval attached to a step-up or defer decision

So a decision record produced by a system the operator does not control can be committed to by digest, with a named party obliged to keep it resolvable, without moving it into the Trust Record. That is composability, and the limit is stated normatively in the same section: a verifier MUST NOT reject a record because a reference cannot be resolved, and MUST NOT treat a resolved reference as attested evidence.

That last rule is worth reading before you scope further. It bounds what this can ever prove, and it bounds it in the direction your proposal cares about.

What is actually missing

A registered rel for a per-action policy evaluation. authorized-intent covers a decision made before execution and held elsewhere; nothing covers the evaluation that ran at the action.

That is a much smaller change than a new schema layer, and it is the version I would like to see scoped. Reframe it as a rel proposal: what the referenced object is, who resolves it, what a verifier may and may not conclude from a resolved one, and what a digest over it commits to.

Context you would not have had

Yours is the fourth governance-shaped request against this repository in about a week, from four unconnected directions: #191 on human approval outcomes, #209 on public-sector auditability, an external transition-closure layer, and now this. @lywinged noticed the pattern on #209 and put it better than I would have:

All three need the same thing, which is a way to bind a governance fact that lives outside the record to the record itself. The demand is real and it is arriving faster than the profiles for it.

Four now. So the answer is not four schema proposals, it is the rel registry, and I am opening a tracking issue to hold it as one question rather than four. Yours is the clearest statement of the underlying need, which is why it is getting the direction rather than a holding reply.

[imran-siddique]

Tracking issue opened: #226, holding the rel registry as one question across #191, #209, #220 and the transition-closure thread.