Specify a machine-readable baseline for the Evidence Preservation list: map it to OpenTelemetry GenAI semantic conventions

[meshailabs]

The Evidence Preservation section requires members to preserve prompts, traces, tool calls, logs, model and safeguard versions, agent and workload identities, permissions available during the run, human approval and intervention events, and a complete incident timeline. The Notification Timelines table requires "machine-readable updates" while material risks remain unresolved, and "From Lessons to Controls" commits to a versioned catalog of machine-readable policies and reproducible verification methods.

None of these name a format. Without one, each member preserves evidence in a proprietary shape, and every cross-member incident review starts with manual normalization before the eight-layer review framework can be applied. The verification methods in the catalog also cannot be executable if the evidence they run against has no common representation.

Proposal: reference the OpenTelemetry GenAI semantic conventions as the baseline representation for the runtime items on the evidence list, rather than defining a new schema. Most of the list already has a home there:

SAFE evidence item	Existing OTel representation
Prompts, tool calls, model versions	gen_ai.* spans and events (inference and tool-execution conventions)
Agent and workload identities	gen_ai.agent.* attributes, with SPIFFE IDs (already an alliance contribution via HPE) as the identity value
Incident timeline	W3C Trace Context, which the MCP specification adopted in its July 2026 revision
Detection, containment, recovery events	Span events and log records on the same trace

Two items on the list have no settled upstream convention yet: human approval and intervention events, and safeguard/policy version identifiers. These are the requirements SAFE is best placed to surface from real incidents. Rather than specifying them independently, SAFE should feed them into the OpenTelemetry GenAI SIG, where related threads are already open: agent lifecycle events covering pause and resume for human approval (open-telemetry/semantic-conventions-genai#159), opaque references from decision spans to governance records (open-telemetry/semantic-conventions-genai#368), and guardrail conventions that include a policy version attribute (open-telemetry/semantic-conventions-genai#427).

The practical benefit: incident evidence becomes something members collect from telemetry their systems already emit in production, rather than a separate forensic artifact assembled after the fact. That serves the RFC's stated principle that reporting should reflect actual risk with minimal friction, and it keeps SAFE from becoming the source of one more competing agent-telemetry schema.

If maintainers want it, I can open a PR against the RFC adding the full mapping as an appendix.

Disclosure: I work on OTel-based runtime evidence tooling for AI agents (MeshAI Labs) and participate in the OTel GenAI semantic-conventions threads linked above.

[lumirosh]

Anchoring on the two items you flag as having no settled upstream convention, in particular human approval and intervention events.

I agree that OTel GenAI is the right transport and that a parallel schema would be a mistake. One thing worth separating: transport and semantics fail independently here. Even once gen_ai.* spans carry approval events, two members can each satisfy the Evidence Preservation list and still produce reports that cannot be mechanically compared, because "human approval event" does not by itself say what was approved.

The narrow question I would like to see covered somewhere in the SAFE evidence model:

What exact action was approved, under which evidence and context, and did observed execution remain inside that approved scope?

That sits alongside rather than inside the current proposals:

• Add Temporal Authority and Self-Extension Denial to the SAFE Evidence Framework #1 proposes evidence that externally issued authority was valid, time-bound, and not self-extended.
• Support design-time control lineage in SAFE findings (design_coverage + design_references) #3 proposes design-time control lineage.
• Specify a machine-readable baseline for the Evidence Preservation list: map it to OpenTelemetry GenAI semantic conventions #5 proposes an OpenTelemetry-based representation for runtime evidence and identity.
• Add a pre-connection tool-trust attestation as an interoperable evidence type, expressed against the OTel GenAI conventions #6 proposes pre-connection tool-trust attestation.
• Add an optional causal incident graph profile for reconstructable, mechanically verifiable SAFE findings #7 proposes an optional causal incident graph.

None of them binds a specific approval to a specific executed action. For two of the RFC's reportable conditions, a system acting on a third-party system without authorization, and a system continuing to probe after detection, that binding is what separates "authority was absent" from "authority existed and execution left its scope." Those are different control failures with different remediation, but the current evidence list does not require a machine-readable distinction between them.

Proposed attributes, offered as attributes rather than a new document type. These are proposed here; they are not lifted from an existing implementation:

approval_event_id      authority_issuer       authority_subject
approved_action        approved_resource      scope
basis_hash             valid_from             expires_at
revoked_at             execution_reference    scope_match
parent_receipt_id      reopen_event_id

valid_from / expires_at / revoked_at deliberately reuse #1's concepts rather than competing with them. basis_hash is proposed as a compact reference to the evidence and authority basis that justified the approval, so a later report can state whether that basis still held at execution time. scope_match is the verdict of the comparison above.

Disclosure: I maintain Open Decision Receipt, an Apache-2.0 vendor-neutral schema and reference lifecycle in this area. Linking as prior art and a runnable lifecycle example, not as a proposal for SAFE to adopt:

• schema: https://github.com/lumirosh/open-decision-receipt/blob/main/schemas/decision-receipt.schema.json
• executable artifact bundle: https://github.com/lumirosh/open-decision-receipt/tree/main/examples/end-to-end-artifact-bundle

Honest boundary, and it is the reason I am raising this at all. That implementation binds check-time context and an authority snapshot, detects later drift, records single-use authority consumption, preserves sealed parents, and creates append-only reopen lineage. It already records both operands of the comparison above: approval_scope on the authority block and actual_action on the execution block. Both are free-text strings, so the reference engine cannot compare them mechanically, and a downstream consumer cannot perform that comparison reliably without interpreting organization-specific prose. That is the same gap I am describing at SAFE scale. I would rather name it in my own implementation than propose a field as though it were solved.

Happy to leave this here if it belongs inside the transport mapping, or to open a focused issue if the semantics are better tracked separately.

[meshailabs]

Agreed on the transport/semantics split — and I think you've located the gap precisely. Two reactions:

1. This deserves its own issue. Specify a machine-readable baseline for the Evidence Preservation list: map it to OpenTelemetry GenAI semantic conventions #5 is deliberately scoped to "don't invent a schema for what already has a home"; the approval-to-execution binding is the opposite case — semantics with no settled home. A focused issue keeps that distinction clean, and SAFE's two reportable conditions you cite are the right forcing function for it. Please link it back here; I'd add the eventual attributes to the appendix mapping as the contents of the governance-record reference (otel#368 kept that reference opaque precisely because these semantics weren't settled — your list is a credible first draft of what's behind it, and otel#159's pause/resume events are the natural carrier for the approval moment).

2. On the free-text boundary you named in your own implementation: I don't think approved_action/scope become comparable until they're bound to structured vocabularies rather than prose — tool-call schemas for actions, and workload identifiers (e.g., the SPIFFE IDs already proposed in this mapping) for resources. That would also let scope_match be recomputable rather than merely asserted; if it's recorded as a verdict, it should reference the comparison method and version, or it becomes evidence that itself can't be verified. Worth stating both constraints as requirements in the new issue even if the vocabularies start small.

Once that issue exists I'll reference it from the OTel GenAI SIG threads so the upstream and SAFE discussions don't fork.

[lumirosh]

Opened as #13.

Adopted both constraints you raised: structured operands rather than prose, and a recomputable verdict carrying its comparison method and version, on the grounds that a verdict without a stated method is an assertion rather than evidence. Framed the requirements against the opaque reference in otel-genai#368 rather than proposing a competing transport, and cited #159 as the carrier for the approval moment.

Cited ODR as prior art and as a worked example of the free-text limitation, not as a solved standard.