[Feat]: Trust Decision Provenance and Evaluation Assurance for computed trust signals

### Is your feature request related to a problem? Please describe.

A2A is developing mechanisms for agents to exchange trust signals such as behavioral, governance, credential, and reputation evidence.

However, when a trust provider returns a computed result such as:

trust_score = 0.84

the relying agent can verify who issued the result, but there is no common way to understand how that decision was produced.

Important evaluation context may be missing or provider-specific, including:

- evaluation engine or model identifier
- model/version used
- policy version
- evidence window
- evidence freshness
- feature/profile version
- confidence or calibration information
- drift or degraded-state information
- whether a fallback evaluator was used
- reason codes for the decision

This becomes important when trust decisions are used for high-risk or autonomous agent actions.

For example, two providers may both return a trust score of 0.84, while one result was produced using a current approved model and fresh evidence, and another was produced using an outdated model or stale evidence.

A signed trust result proves that a provider issued the result, but it does not provide a standardized way for a relying party to determine whether the evaluation process itself satisfies its local trust or governance policy.

This proposal is intended to complement existing trust-signal work such as #1628. It does not introduce another trust score or scoring methodology.

The gap is specifically the provenance and assurance of a computed trust decision.

### Describe the solution you'd like

Add an optional, provider-agnostic evaluation provenance object that can accompany computed A2A trust signals.

The goal is not to standardize the trust model, scoring algorithm, thresholds, or feature engineering. The goal is to standardize enough metadata for a relying agent to understand how a trust decision was produced and decide whether that evaluation satisfies its own policy.

For example:

{
"type": "behavioral",
"score": 0.84,
"evaluationProvenance": {
"engine": {
"id": "behavioral-risk",
"version": "3.4.1",
"digest": "sha256:..."
},
"policy": {
"id": "enterprise-agent-trust",
"version": "2.1",
"digest": "sha256:..."
},
"evidence": {
"profile": "behavioral-v3",
"window": "24h",
"observedAt": "2026-08-13T09:30:00Z",
"digest": "sha256:..."
},
"assurance": {
"confidence": 0.94,
"driftStatus": "normal",
"fallbackUsed": false
},
"reasonCodes": [
"STABLE_BEHAVIOR",
"LOW_POLICY_VIOLATION_RATE"
]
}
}

The structure should be:

- optional and backward-compatible
- usable across different trust providers
- independent of any specific ML model or scoring implementation
- privacy-preserving, without requiring raw behavioral data or proprietary model details
- compatible with existing signed trust signals and provider verification mechanisms
- extensible so additional assurance metadata can be added later

A relying agent could then apply local policy such as:

- accept only approved evaluation engine versions
- reject or step up when driftStatus is degraded
- reject decisions based on stale evidence
- require a minimum confidence level
- reject decisions produced using an unapproved fallback evaluator

This would complement existing trust-signal work such as #1628 by adding provenance and assurance for the process that produced a computed trust decision, rather than introducing a new trust score or trust taxonomy.

### Describe alternatives you've considered

I considered a few alternatives:

1. Keep evaluation provenance provider-specific

Each trust provider could define its own metadata for model version, policy version, evidence freshness, confidence, and drift status.

This is simple for individual implementations, but it reduces interoperability because relying agents would need custom logic for every provider.

2. Add these fields directly to each trust signal type

For example, behavioral, governance, or reputation signals could each define their own model/version and assurance fields.

This would work, but it risks duplicating the same concepts across multiple signal types and creating inconsistent semantics.

3. Treat provider signatures and expiry as sufficient

Existing signed trust signals already provide issuer authenticity and freshness through signatures and expiration.

However, a signature only proves that a provider issued a result. It does not indicate which evaluation engine, policy, evidence profile, or fallback path produced that result.

4. Standardize the trust-scoring algorithm itself

A2A could define a common scoring methodology or required model.

I do not think this is desirable because different domains and providers will use different risk models, evidence sources, and policies. A2A should remain implementation-agnostic.

5. Keep this entirely outside A2A

Enterprise systems could maintain their own model-governance metadata out of band.

This avoids protocol changes, but a relying agent receiving a portable trust signal would still have no interoperable way to evaluate the provenance of that decision across organizational boundaries.

For these reasons, an optional common evaluationProvenance structure appears to provide a useful middle ground: it preserves provider flexibility while giving relying agents a consistent way to evaluate the provenance and assurance of computed trust decisions.

### Additional context

This proposal is intended to complement the existing A2A trust work rather than replace or duplicate it.

In particular, #1628 is already defining a trust.signals[] model for independently verifiable trust evidence such as behavioral, governance, vouch-chain, and on-chain signals.

The additional gap this proposal is trying to address is narrower:

Existing trust work helps answer:
"What trust evidence exists about this agent?"

This proposal helps answer:
"What evaluation process produced this computed trust decision, and is that process acceptable to the relying party?"

For example, a relying enterprise may want to accept a behavioral trust result only when:

- the evaluation engine version is approved
- the policy version is current
- the evidence is sufficiently fresh
- the evaluator is not in a degraded or drifted state
- no unapproved fallback was used
- confidence meets a local threshold

These checks are especially useful in regulated, financial, enterprise, or other high-impact agent workflows where the trust decision itself may influence authorization, delegation, or execution.

The proposal intentionally avoids exposing raw behavioral data, proprietary features, model weights, or internal implementation details. Content digests and version identifiers could be used where stronger reproducibility or auditability is required.

It may also be useful to align the structure with the existing A2A extension mechanism so that this can evolve independently without requiring a breaking change to the core protocol.

I would be happy to help refine the schema, define a minimal required/optional field set, and provide example policy-evaluation flows if the maintainers think this direction is useful.

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

The issue relates to extending A2A trust signals with an optional evaluationProvenance object. Start by reviewing the existing trust signal definitions, likely in a directory like `spec/trust/` or `docs/trust/`. Examine the linked issue #1628 to understand the current trust.signals[] model. The work involves designing a JSON schema for the provenance metadata and integrating it as an optional extension. Check for existing extension mechanisms in the protocol. 'Done' means a proposed schema and integration points that are backward-compatible and provider-agnostic.

Scritto dal modello di indicizzazione a partire dal testo della issue.