As an implementation data point, TadpoleDBHub has already implemented a server-specific version of this audit context.

Current behavior:

• user_query: original user request, same across a user turn
• invocation_reason: per-tool-call rationale generated by the AI/client
• model: currently captured from an HTTP header (X-MCP-Client-Model) as best-effort, client-asserted metadata
• correlation is stored through request/session IDs so AI audit logs and SQL/service audit logs can be joined

Operational lessons:

1. user_query and invocation_reason need to remain separate.
   The first is turn-level user intent; the second is per-call tool-selection rationale.

2. invocation_reason is useful for audit review, but it must not be treated as authorization evidence.
   It is AI/client-generated and can be incomplete or inaccurate.

3. Free-text audit context needs redaction/tokenization before persistence.
   Both user intent and invocation rationale can contain sensitive data.

4. Putting these fields into tool arguments works as a compatibility convention, but it pollutes tool-specific schemas.
   A protocol-level _meta location would be cleaner and easier for clients to implement consistently.

5. For backwards compatibility, servers may need to accept both:

   • standardized _meta fields, if adopted
   • existing server-specific tool arguments

Based on this experience, _meta.invocationReason, _meta.model.name, _meta.userIntent, and _meta.turnId as optional metadata seem like a practical direction.

This proposal maps closely to what I would want from an operational "agent run record" around MCP calls.

A few fields I would consider separating explicitly:

• turnId: user-turn correlation, as proposed.
• runId or sessionId: the longer-lived agent/run/session that may contain multiple user turns.
• toolCallId: stable per invocation, so tool output, approval events, retries, and logs can join back to the same call.
• host.name / host.version: the MCP host/client that initiated the call.
• server.name / server.instanceId: useful when the same MCP server type is running in multiple environments.
• approval.status: not_required, requested, approved, denied, expired, etc. This should be audit metadata, not authorization by itself.
• tool.sideEffect: coarse class such as read, write, external_network, exec, admin, financial, etc. This may belong in tool metadata, but copying the resolved class into the run/audit record helps later review.

I agree strongly that invocationReason should not be treated as authorization evidence. It is useful for human review and debugging, but policy should rely on deterministic context: principal, scopes, tool metadata, environment, approval state, and server-side checks.

One thing I would avoid is making userIntent mandatory or assuming it is safe to persist. In practice I would expect clients/hosts to support modes like:

• omit userIntent
• store a redacted version
• store a hash/reference to a client-side/private transcript
• store only a short client-generated intent label

From an ops perspective, the real value is being able to answer later:

Which user turn and agent run caused this tool call, which model/host produced it, which server executed it, what policy/approval state applied, and which output/action resulted?

That is also the direction we are experimenting with in Armorer: local/self-hosted agent runs need an inspectable record of tools, approvals, files/data touched, and final artifacts. MCP standardizing even a small optional _meta convention here would make cross-server audit logs much easier to build consistently.

Thanks @armorer-labs — this is a helpful framing, and I agree with the broader operational direction.

The full "agent run record" is valuable, but I would like to keep this initial proposal narrower. The immediate interoperability gap is that MCP servers currently have no standard place to receive the audit context for an AI-initiated request:

• why the AI/client invoked this specific MCP request (invocationReason)
• which model produced the invocation (model.name), distinct from the MCP host/client identity
• what user request caused the work, when safe to provide (userIntent)
• which requests belong to the same user turn (turnId)

This came from an implementation problem in practice: servers can add custom tool arguments such as user_query and invocation_reason, and can capture model information through transport-specific mechanisms such as HTTP headers. That works, but it creates server-specific schemas and does not generalize cleanly across transports such as stdio.

A standard _meta location would let clients provide the same audit context consistently without every server inventing its own tool arguments.

I agree strongly on userIntent: it should remain optional and should not be assumed safe to persist. Clients should be able to omit it, send a redacted version, send a hash/reference to a private transcript, or send a short client-generated intent label.

On the additional fields:

• host.name / host.version are related to existing MCP initialize.clientInfo; useful for audit, but different from model.name.
• server.name / server.instanceId should probably be server-provided, not client-provided request metadata.
• toolCallId and runId are real audit needs, but I would treat them as follow-up work because they need clearer semantics around retries, approvals, and resumability.
• approval.status is a policy/approval lifecycle state, not AI invocation context.
• tool.sideEffect feels closer to tool metadata, although copying the resolved value into an audit record is useful.

So I think the clean split is:

1. This proposal: a small optional _meta convention for AI-generated invocation audit context: invocationReason, model.name, optional userIntent, and turnId.
2. Follow-up work: fuller agent run records, stable tool-call identity, approval lifecycle, side-effect classification, and server/host deployment metadata.

That would solve the immediate interoperability problem while keeping the first proposal small enough to standardize.

Implementation data point from a non-MCP-native runtime that already records this shape — agent-guard emits per-tool-call audit context for Bash / WriteFile / HttpRequest / Custom tools. Two operational refinements worth contributing back:

1. turnId is necessary but not sufficient — pair it with a per-turn decision sequence.

A single user turn in a coding agent regularly produces a tree of N retries inside one tool invocation, plus K cascading tool calls. With only turnId, post-hoc audit cannot reconstruct ordering or distinguish "the agent retried after a Deny" from "the agent issued a second different tool call." We thread session_id (the turn) + a monotonic decision sequence + parent decision reference. Cheap addition, makes the audit chain actually replayable.

2. The proposal as written is input audit (what the AI claimed it was doing). It pairs with — but doesn't replace — output audit (what was allowed and by which rule).

invocationReason is AI-asserted, and as the OP notes, "may be incomplete or inaccurate." For security-sensitive servers (DB, files, admin actions) the audit record that holds up isn't the model's stated intent; it's the server-side decision record: decision (allow | deny | ask_user), decision_code, policy_hash, trust_level, and an execution proof if the call ran. Those compose naturally — _meta.invocationReason is "why I asked," server-side record is "what I allowed and why." Without the second half you can't answer the OWASP LLM06 Excessive Agency question in practice, only whether the agent said it needed it.

On the proposal's specific questions:

1. _meta is the right location.
2. invocationReason + model.name are clean names. Worth making it explicit in the field definition (not just the trust section) that invocationReason is client-asserted and must not be used as authz evidence — server implementers consistently misuse free-text rationale as a control signal in practice.
3. userIntent is worth including but with a redacted: bool marker so privacy-sensitive deployments can carry the structural correlation without the content.
4. turnId belongs in this proposal — joining the user-turn boundary to multi-call audit is the operational use case.
5. Echoing turnId in response _meta: yes, otherwise async/streamed tool responses can't be correlated downstream.
6. SEP feels right. The current state where every server invents user_query / invocation_reason / ai_model is exactly the fragmentation MCP exists to prevent.

Thanks @XuebinMa — this is a useful implementation data point, especially from a non-MCP-native runtime.

I agree with the distinction between input audit and server-side decision/output audit.

The intent of this proposal is the input side: what the AI/client asked for and why:

• invocationReason: why the AI/client requested this MCP operation
• model.name: which model produced the invocation
• userIntent: what user request caused the work, when safe to provide
• turnId: which user turn the request belongs to

The server-side decision record you described — allow | deny | ask_user, decision_code, policy_hash, trust_level, execution proof, etc. — is the other half of the audit story. I agree it is important, especially for excessive-agency controls, but I would keep it separate from this initial proposal so that client-asserted explanation metadata and server-authoritative policy decisions do not get mixed into one layer.

I also agree that invocationReason should be explicit in the field definition, not only in a security note: it is client/AI-asserted metadata and must not be used as authorization evidence.

On the specific refinements:

• turnId belongs in this proposal.
• Echoing turnId in response _meta seems like a small and useful addition, especially for async or streamed responses. I would frame that as optional: servers MAY echo the same turnId in response _meta.
• A per-call sequence / parent reference is useful for replayable audit chains, but I would group that with toolCallId, retries, approvals, and resumability as follow-up work.
• For userIntent, I agree that privacy state should be visible somehow. I am not sure yet whether the right shape is redacted: bool, a mode such as raw | redacted | reference | label, or making userIntent an object rather than a string. That feels like a SEP-level schema decision.

So my current split would be:

1. This proposal: small optional _meta input-audit context for AI-initiated MCP requests, plus optional response echo of turnId.
2. Follow-up work: stable tool-call identity, replayable decision sequence, approval lifecycle, and server-side decision/output audit records.

That keeps the first step focused while preserving the stronger audit model you are pointing to.

Thanks @hangum — the split lands well. Keeping SEP-0 to client-asserted input audit (plus the optional turnId response echo) and pushing the server-side decision record into follow-up is the right ordering; mixing client-asserted "why I asked" with server-authoritative "what I allowed" in the same SEP would have made both harder to standardize.

Two small things for the record on the follow-up:

1. Reference implementation availability. When the server-side decision-record SEP opens, agent-guard has a working field shape that could serve as a starting point — decision (allow / deny / ask_user), decision_code, policy_hash, trust_level, and a signed ExecutionProof for executed calls. It emits these as JSONL audit records today, so the follow-up SEP would have a concrete reference rather than designing from scratch. Not asking SEP-0 to absorb any of it; just flagging availability.

2. Forward-compatibility line in SEP-0 turnId. A one-line addition to the turnId field description would keep the follow-up clean — something like "MAY be combined with additional correlation fields defined by future SEPs (e.g., per-call sequence or parent reference for replayable audit chains)." No commitment to any specific sequence shape; it just preserves the seam so the follow-up can layer in without re-litigating turnId semantics.

On the userIntent redaction shape — agreed it's SEP-level. I'll hold opinions until that schema discussion opens.

Thanks @XuebinMa — both points are useful and I think we can fold both in cleanly.

1. Forward-compatibility line in turnId. Agreed — essentially free in SEP-0 and worth doing. I plan to include something like:

turnId MAY be combined with additional correlation fields defined by future SEPs (for example, per-call sequence or parent-reference fields for replayable audit chains).

That preserves the seam without committing to any specific follow-up shape.

2. Reference implementation for the server-side decision record. Noted, and thanks for flagging it ahead of time. Having a concrete working shape (decision, decision_code, policy_hash, trust_level, signed ExecutionProof) will make the follow-up SEP much easier to ground in real implementation experience rather than designing from scratch. I will cross-reference agent-guard when that follow-up opens.

On userIntent redaction shape — agreed, deferring to the SEP schema discussion.

Next step from my side: prepare the SEP-0 draft for the input-audit _meta convention (invocationReason, model.name, userIntent, turnId, with the optional turnId response echo and the forward-compatibility note). If anyone has input on naming or field shape before then, this is the time.

Thanks for the quick turnaround. The forward-compat line and the cross-reference offer are both very appreciated.

Since you explicitly asked for input on field shape before the SEP-0 draft, here's some from the implementation side — agent-guard has been chewing on these for a while:

1. invocationReason — structured kind + free-form text

In practice we needed both: a machine-readable kind for policy/routing, and a free-form text for humans and SIEM. Pure free-form is essentially un-filterable at audit time.

invocationReason: {
  kind: "user_request" | "agent_chain" | "scheduled" | "retry" | "replay" | "tool_chain",
  text?: string
}

Policy engines can branch on kind without NLP-ing text. Start the enum conservative (3–4 values) and let future SEPs extend it.

2. model.name — leave room for provider/version

We've hit cases where name alone ("claude-opus-4-7") isn't enough for chain validation across aliases or proxies:

model: {
  name: string,
  provider?: string,
  version?: string
}

Common case stays cheap ({ name }), but the shape doesn't paint future audits into a corner.

3. userIntent — explicit length + redaction signal

Echoing the earlier privacy note: even when optional, implementations end up logging either the raw text, a truncated version, or a hash. Worth defining the shape rather than letting everyone reinvent it:

userIntent: {
  text?: string,
  hash?: string,        // e.g., sha256 of original
  redacted?: boolean    // text was modified/truncated
}

If you prefer the simpler-string shape, at least call out a recommended max length and a redaction convention in the SEP — otherwise interop suffers.

4. turnId — confirm it's opaque

No strong opinion on format, but worth stating it's an opaque string clients MUST NOT parse, with a non-binding recommendation (UUIDv4 / ULID). That keeps validators honest about format assumptions.

Reference implementation: once SEP-0 lands as a draft, I'll publish a field mapping showing how these flow through agent-guard's existing Guard → AuditRecord → ExecutionProof path, and share a working sketch on this thread. That gives the follow-up server-side decision-record SEP a concrete shape to anchor against without locking either side into a specific implementation timeline.

Thanks @XuebinMa — this is very helpful implementation feedback.

I agree with the general direction: the fields that are likely to grow should probably be structured objects rather than bare strings.

A few reactions:

• model as { name, provider?, version? } seems like a low-cost improvement. The common case can still send only name, while deployments with model aliases, gateways, or proxies have somewhere to put the extra attribution.
• turnId should be explicitly opaque. I agree clients and servers should not parse semantics out of it. A non-normative UUIDv4 / ULID recommendation sounds reasonable.
• userIntent as an object also seems better than a bare string if we want privacy modes to interoperate. Something like { text?, hash?, redacted? } lets a client provide raw text, redacted text, or only a reference/hash depending on deployment policy.

The one place I would be cautious is invocationReason.kind.

I agree that pure free-form text is hard to filter in SIEM/policy pipelines. But if SEP-0 starts by standardizing too much taxonomy, it may turn into a broader policy/audit ontology discussion and make the first step harder to land.

My current preference would be:

"invocationReason": {
  "kind": "user_request",
  "text": "Need to inspect table schema before generating SQL"
}

with kind optional and extensible, and with only a very small initial recommended set, if any. The normative core would still be that this is client/AI-asserted input-audit metadata, not authorization evidence.

So the shape I am leaning toward for the SEP-0 draft is roughly:

{
  "_meta": {
    "invocationReason": {
      "kind": "user_request",
      "text": "Need to inspect table schema before generating SQL"
    },
    "model": {
      "name": "example-model",
      "provider": "example-provider"
    },
    "userIntent": {
      "text": "Show me 10 employees",
      "redacted": false
    },
    "turnId": "opaque-client-generated-id"
  }
}

All fields optional. All client-asserted. Servers may ignore, redact, transform, or store them according to policy. Servers must not use invocationReason or userIntent as authorization evidence.

That keeps SEP-0 focused on the interoperability gap — a standard place to carry AI/client input-audit context — while leaving room for richer policy, sequencing, and server-side decision records in follow-up SEPs.

Agreed on all of this — the draft shape looks right, and your caution on invocationReason.kind is well taken. Standardizing a taxonomy now would pull SEP-0 into an audit-ontology discussion it doesn't need; an optional kind with a minimal-to-empty recommended set is the right call, since the enum is extensible and follow-up SEPs can add values at zero cost.

One low-cost hook worth a sentence in the SEP-0 text: state explicitly that kind is an open vocabulary — clients MAY send values outside any recommended set, and servers MUST treat unrecognized kind values as valid (falling back to text). That keeps audit/SIEM consumers from hard-failing on values a future SEP introduces, without SEP-0 committing to the taxonomy itself.

Otherwise this looks ready to draft — happy to review once SEP-0 is up.

Thanks @XuebinMa — agreed. I will include that explicitly.

For SEP-0, invocationReason.kind should be an open vocabulary: clients MAY send values outside any recommended set, and servers MUST NOT reject an invocation only because kind is unrecognized. Consumers can fall back to invocationReason.text.

That keeps the first proposal focused on the transport location and field shape, while leaving taxonomy expansion to future SEPs or implementation-specific policy.

+1 to the structured kind shape for invocationReason. From running per-agent bearer-token audit across a memory-hub-style coordinator + research agent for ~5 months, two notes from the implementation side:

1. kind should distinguish unattended vs interactive at the same level, not nested inside the enum. In our setup the same agent slug fires both on a 2-hour systemd timer and during interactive SSH sessions. The audit weight of those is very different — an interactive call has a present human supervising the loop in near-real-time; an unattended scheduled call has the human looking at the trail asynchronously, sometimes hours later. We model this as a flag (unattended: bool) at the same level as the kind enum rather than inside it, because the cross-product gets large quickly (interactive retry, scheduled retry, interactive replay) and the supervision distinction is the one policy engines actually want to branch on. Keeps the kind enum small.

2. model.name alone is fragile in multi-provider setups. Two suggestions:

• model.provider alongside model.name. claude-sonnet-4-6 via Anthropic direct vs the same string surfaced through an OpenRouter shim is operationally different (different rate limits, different failure modes, different cost ledgers).
• An optional model.cost_class (primary | fallback | local) so SIEM can correlate degradation with provider state rather than chasing per-model strings.

3. On userIntent. Strongly agree it should remain optional. We have writer agents that legitimately have no userIntent — they fire on cron with no human turn — and forcing a value invites garbage data. The proposals "when safe to provide" handles this, but Id suggest making it explicit in the spec text that empty or absent is expected for unattended invocations, not a degenerate case. Helps downstream parsers not treat absence as a warning.

4. On turnId. Wed also want a longer-lived agent-instance identifier alongside it. The two cover different join keys: user-intent-level grouping (turnId) and agent-instance-level grouping (call it sessionId or agentRunId). Both come up reconstructing audit trails post-incident — the user turn tells you what the human wanted, the agent run tells you which process did what. Probably best as a follow-up field rather than SEP-0 scope, but worth keeping a seam open per the forward-compat language already discussed.

Thanks — this is useful implementation feedback.

I agree that absent userIntent must be treated as normal for unattended or scheduled invocations, not as malformed audit data. I will make that explicit in the SEP-0 text.

model.provider already fits the current draft shape, so that one is in.

For unattended: I agree the supervision distinction is real and the cross-product argument against nesting it inside kind is sound. If it is added in a future SEP, it should sit alongside kind as a sibling flag rather than inside the enum, for exactly the reason you described. I would still keep it out of SEP-0 to hold the scope to minimum input-audit context.

For agentRunId / sessionId: agreed the join key is distinct from turnId. The forward-compat note already discussed with @XuebinMa ("turnId MAY be combined with additional correlation fields defined by future SEPs") is meant to keep exactly this seam open, so a follow-up SEP can layer it in without re-litigating turnId semantics.

I am less sure about standardizing model.cost_class in SEP-0. provider identifies where the invocation actually came from at the protocol layer; cost_class feels closer to operator-side classification than audit context, so I would leave it to deployment policy rather than the SEP.

@hangum the open-vocabulary kind language is exactly right — thanks for folding it in cleanly.

@Zawwarsami16 the agent-run vs. user-turn join-key distinction matches what we ended up with in agent-guard: the Context type already carries agent_id and session_id for exactly the post-incident reconstruction case you described — agent-instance grouping kept separate from the per-call/per-turn ID. +1 to deferring it to follow-up SEP; a second independent implementation converging on the same shape should make that follow-up easier to ground when it opens.

Thanks @XuebinMa — agreed. It is useful to see another implementation converge on the same separation between user-turn correlation and longer-lived agent/session correlation.

I will keep SEP-0 focused on the minimum input-audit context and leave agent-run/session correlation for follow-up work.

Thanks for sharing the implementation data point.

I agree this belongs to the follow-up server-side decision-record layer rather than SEP-0. The content-addressed action_ref approach is useful prior art for the stable tool-call identity discussion.

For SEP-0 I will keep the scope limited to client-asserted input-audit context (invocationReason, model, optional userIntent, and turnId). The server-authoritative decision record, stable tool-call identity, and tamper-evident audit bundle should be handled separately.

The split in this thread feels right to me: client-asserted input audit should stay separate from the server-authoritative decision record.

invocationReason can explain why the client asked, but it should not authorize the tool call. The adjacent object is a decision record that binds the exact server, tool, target, actor, and params hash, then returns allow, revise, human_review, or stop before the runtime proceeds.

We have a small synthetic local proof of that pattern here:

https://github.com/neurarelay/relay-action-card/blob/main/docs/mcp-risk-gate.md

No real MCP server, no downstream execution, no provider claim. Just a concrete data point for the follow-up decision/output-audit layer.

Open question: should that future decision record link to input audit through turnId plus stable tool-call identity, or stay host/server-owned and reference MCP context externally?

Thanks @rpelevin and @chopmob-cloud — both are useful follow-up data points.

For SEP-0 I would avoid defining the server-authoritative decision record. The linkage question is important, but I think it belongs in the follow-up SEP: whether a decision record directly references turnId plus a stable tool-call identity, or remains host/server-owned and references MCP context externally.

My current leaning is to keep SEP-0 forward-compatible by defining turnId as input-audit correlation only, and leave the exact decision-record linkage model to the follow-up.

An implementation pass against live or prototype MCP server paths would be very helpful once the SEP-0 draft is open. The feedback I would most want is whether the client-asserted input-audit field semantics (invocationReason, model, optional userIntent, and turnId) are clear enough to implement consistently.

Thanks everyone for the feedback on this discussion.

I opened the SEP draft as PR #2817:
#2817

The PR currently defines the minimum client-asserted input-audit context we discussed:

• invocationReason — why the AI/client made the MCP request
• model — which model produced the invocation
• userIntent — optional user-level intent, when safe to provide
• turnId — user-turn correlation, with optional response echo of only turnId

It keeps server-side decision records, stable tool-call identity, agent/session correlation, approval lifecycle, and taxonomy work out of scope for follow-up SEPs.

Tagging the main participants from this thread for visibility: @armorer-labs @XuebinMa @Zawwarsami16 @chopmob-cloud @rpelevin

If you have time, review on the PR would be very helpful — especially whether the field semantics are clear enough to implement consistently.

Answering the implementability question directly, from wiring these four fields into a non-MCP-native runtime (agent-guard): the shape is implementable as-is. The spots where an implementer currently has to guess are below — all small, each fixable with roughly one sentence of spec text.

invocationReason {kind, text} — clear, with two gaps:

• Is text required whenever the object is present, or can a client send kind alone? An open kind vocabulary only degrades gracefully if text is reliably there as the fallback, so I'd make text REQUIRED when invocationReason is present (servers fall back to text for an unrecognized kind).
• Retry scope: when one logical tool call is retried N times within a turn, does each attempt re-emit invocationReason? I'd state it's per-emitted-request (so retries each carry one) and explicitly leave attempt ordering to the follow-up tool-call-identity work — otherwise implementers will overload invocationReason to encode sequence.

model {name, provider?, version?} — semantics are clear (the model that produced this invocation, distinct from host/client clientInfo). One interop risk: if name is fully free-form, cross-server audit joins break on cosmetic differences (claude-opus-4-8 vs Claude Opus 4.8). Non-normative guidance to prefer the provider's canonical model-id string would be enough — no registry needed. For multi-model agents (router + worker), one line clarifying that model is the model that emitted this call, not the orchestrator, would help.

userIntent {text?, hash?, redacted?} — the optionality and modes are clear. Two field-relationship questions an implementer hits:

• If hash is present, what is hashed — text, or a private transcript the client chose not to send? Those carry different audit meaning; I'd define hash as a client-chosen reference whose preimage is not assumed available server-side.
• redacted: does true mean "the text here is a redacted form" or "intent existed but was withheld"? Worth pinning, since servers may treat the two differently in review.

turnId — clear and implementable as a correlation key; opaque + UUIDv4/ULID-non-normative is the right call. The one thing I'd guard against in the text: don't let SEP-0 imply turnId conveys ordering or call identity. It correlates calls to a turn; it does not order them. That keeps SEP-0 forward-compatible with the follow-up exactly as you framed it.

On the linkage question @rpelevin raised — agreed it's follow-up scope. Defining turnId as input-audit correlation only in SEP-0 is the right boundary; whether the eventual decision record references turnId + a stable tool-call identity or stays host/server-owned is precisely the follow-up's job, and SEP-0 stays clean either way.

Happy to do an implementation pass against the SEP-0 draft once it's posted.

Thanks @XuebinMa — this is exactly the kind of implementability feedback I was hoping for.

A few points are already reflected in PR #2817:

• invocationReason.text is now REQUIRED when invocationReason is present, so consumers have a fallback when any future/implementation-specific classification is unknown.
• userIntent.hash is not in the core schema anymore. The PR leaves hash/reference forms to a future revision or deployment policy, so the current SEP does not need to define a hash preimage yet.
• turnId is explicitly opaque and not an idempotency key or JSON-RPC request id.

The remaining clarifications you called out all seem reasonable and small enough to add to the PR text:

• invocationReason is per emitted MCP request; retries should carry their own request-level rationale, while retry ordering/attempt identity stays out of scope for this SEP.
• model.name should preferably use the provider canonical model identifier when available.
• In multi-model systems, model identifies the model that produced this MCP request, not necessarily the orchestrator/router.
• redacted: true without userIntent.text means the client is signaling that user intent existed but was withheld.
• turnId correlates requests to a user turn, but does not imply ordering and does not identify a stable tool-call attempt.

I will add those as small clarifying edits to #2817 rather than expanding the scope. The boundary remains the same: SEP-0 defines client-asserted input-audit context; ordering, stable tool-call identity, retry chains, and server-side decision records remain follow-up work.

Thanks @chopmob-cloud — this is a useful implementation data point.

I agree with that split: turnId should not be the primary identity for a server-side decision record. In SEP-0 / PR #2817, turnId is only client-asserted user-turn correlation metadata. A server-owned decision record can still use its own stable invocation identity, such as a content-addressed action_ref, and store turnId alongside it when present for user-turn aggregation.

That keeps the SEP-0 boundary clean:

• per-invocation / server decision identity: follow-up SEP
• per-user-turn correlation: turnId in this SEP

The action_ref pattern is useful prior art for the follow-up decision-record / stable tool-call identity work.

Thanks @chopmob-cloud — that reference is helpful.

I will keep SEP-2817 focused on the client-asserted input-audit context, and treat the action_ref / compliance receipt work as useful prior art for the follow-up server-side decision-record / stable invocation identity SEP.

Looking forward to your PR review.

The follow-up that came out of this thread, a server-side signed record of what the tool call actually did, is what I have been building as an open SEP (2828). It is a signed, hash-chained record the server emits per tool call, with the outcome bound back to the decision that authorized it: an instance anchor (Check A) plus a content digest over the signed decision (Check B). Check B adopts the outcome-to-decision-digest idea XuebinMa raised here, so the two efforts line up rather than fork.

For an audit standard, the property that counts is that the record is verifiable without trusting the emitter. The conformance vectors are published, and a second independent implementation (Assay, by Rul1an) reproduced them from a clean checkout with no shared code. There is a stdlib-only checker in the repo so anyone can run them.

SEP-2828: #2828

I would value review from people here, especially on the pairing rules and the supersession tie-break.