AI Inference / Agent Run

Authoritative run identifier

Which identifier authoritatively names this run, which system issued it, how it behaves under retries and asynchronous retrieval, and which vendor-native identifiers are kept alongside it. OpenTelemetry marks gen_ai.response.id as Required only for fetch_response operations, Anthropic returns a msg_ prefixed message id, and Amazon Bedrock records a requestId; none of these is a governed global identifier, so the adopting Dimension must state its priority order.

1. Which system is the master of record for this run's identifier, and what is the exact literal form of that identifier? identity
2. When the executing provider returns no run identifier, what identifier does the adopting Dimension mint, and how is uniqueness guaranteed? identity
3. Does the identifier stay stable across retries, streaming resumption and later asynchronous result retrieval, or does each attempt receive a new one? constraint
4. Which vendor-native identifiers are retained beside the authoritative identifier, and what is each one good for? interoperability

Trace, conversation and parent-run correlation

The keys that place the run inside a wider execution graph: W3C trace-id and span-id, gen_ai.conversation.id for session grouping, and the parent-run edge for delegated executions. These are correlation, not identity: trace-ids may be unsampled or absent, and a conversation groups many runs.

1. Which trace identifier and span identifier bind this run into the surrounding distributed trace, and in which propagation format? relationship
2. Which conversation, session or thread identifier groups this run with the runs that preceded and followed it? relationship
3. How are correlation keys preserved when the run crosses a process, vendor or network boundary? interoperability
4. What is recorded when the trace is not sampled, telemetry is dropped, or no conversation exists for this operation type? exception

Operation type and invocation mode

Which operation the run represents and how it was invoked. OpenTelemetry enumerates chat, embeddings, retrieval, fetch_response, create_agent, invoke_agent, invoke_workflow, plan and execute_tool; the run must also record whether execution was synchronous, streaming, batched or asynchronously retrieved, because that changes where the run's temporal boundaries lie.

1. Which operation type does this run represent, drawn from a closed and versioned code list? classification
2. Was the run synchronous, streaming, batched or asynchronously retrieved, and where exactly do its temporal boundaries fall? process
3. Does this run represent a single model call or an agentic loop that may contain many model and tool calls? composition

Regulatory and oversight classification

Whether the AI system executing this run falls into a regulated class, which minimum log content that triggers, and what level of human oversight is mandated. EU AI Act Article 12 obligations attach only to high-risk systems, and the Article 12(3) minimum log set applies only to Annex III point 1(a) remote biometric identification, so over-application is a real modelling error.

1. Under which regulatory regime and which risk category is the AI system performing this run classified, and by whose determination? classification
2. Does the applicable regime impose a minimum log content set for runs of this class, and is every mandated element actually present? requirement
3. What degree of human oversight must be exercised over runs of this class before their effects take hold? authority
4. Which jurisdictions' obligations apply to this run, given where it executed and where its effects land? spatial

Input messages, system instructions and payload handling

What was sent to the model - system instructions, chat history, prompt variables and attachments - and under what capture rule. OpenTelemetry marks gen_ai.input.messages and gen_ai.system_instructions as opt-in with explicit sensitive-data warnings, and Bedrock externalises any body over 100 KB to object storage, so the run record must distinguish inline content from a reference plus digest.

1. What exactly was presented to the model as system instructions, chat history, prompt variables and attachments? composition
2. Is verbatim input content captured, and under which opt-in, truncation, filtering or sampling rule was that decided? privacy
3. Where content is too large or is binary, how is it externalised and referenced back from the run record? constraint
4. How can the exact input be reconstructed later if the referenced payload store has since changed? validation

Input segment provenance and trust level

For each segment of the model's context, where it came from and how far it may be trusted. MCP states that tool annotations and tool results must be treated as untrusted unless the server is trusted, and directs clients to validate tool results before passing them to the model; a run record that flattens user text, retrieved documents and tool output into one undifferentiated context loses the evidence needed to investigate an injection.

1. For each input segment, what is its origin - end user, retrieved document, tool result, upstream agent or system operator? provenance
2. Which input segments were treated as untrusted data that must never be interpreted as instructions? security
3. How is a suspected prompt-injection or untrusted-instruction attempt recorded against the run? event

Model, provider and endpoint binding

Which model was requested, which model actually answered, and through which provider, endpoint and region. OpenTelemetry keeps gen_ai.request.model and gen_ai.response.model separate precisely because a gateway or alias may resolve to a different model, and Bedrock records both a modelId and the serving region.

1. Which model was requested and which model identifier actually produced the response? identity
2. Which provider, endpoint address and serving region handled the run? spatial
3. Which model version, snapshot or inference profile is recorded so a later reader knows which weights answered? provenance

Decoding parameters and reproducibility limits

Which sampling and decoding parameters were in force and what actually prevents an identical re-execution. Anthropic marks temperature, top_p and top_k as deprecated for newer models, so a model that assumes these are always present and always determinative will mis-record reproducibility. The run references an immutable configuration snapshot rather than restating its content.

1. Which sampling and decoding parameters were actually transmitted and honoured for this run? constraint
2. Can this run be re-executed to produce an identical result, and what specifically prevents bit-identical reproduction? validation
3. How is a parameter recorded when the provider has deprecated, capped or silently ignored it for the selected model? exception
4. Which configuration snapshot does the run reference, and is that snapshot immutable and content-addressed? provenance

Capability surface and granted scopes

Which tools, resources and data sources the model could reach at each point in the run, and under which authorization scopes. MCP requires tool sets to be deterministic per authorization but permits them to change over time via list-changed notifications, and requires RFC 8707 resource indicators binding tokens to a specific server, so the surface is a time-varying, scope-bounded fact rather than a static list.

1. Which tools, resources and data sources were offered to the model at run start, and in which order were they presented? composition
2. Which authorization scopes and resource indicators bounded what the run could reach? authority
3. Did the available capability set change during the run, and how is each change point recorded? state

Executing agent and exact configuration references

Invoke and create agent spans record gen_ai.agent.id, name, description and version. For hosted agents the id should be the provider-assigned stable identifier (Bedrock ARN, GCP registry id, OpenAI assistant id). In-memory instance ids are not recommended. PROV associates the activity with an agent and optionally a plan. OpenInference records agent.name. The run also records the configuration identifiers needed for reproducibility (prompt version, tool definitions version, policy version, decoding profile) as references to WM-AI-005 rather than embedding the configuration catalogue.

1. Which stable executing agent identifier, name and version performed this run? relationship
2. Which PROV association, attribution or delegation links this activity to the responsible agent, organisation or human overseer? provenance
3. Which exact configuration identifiers were in force for prompts, tools, decoding, routing and safety policy? relationship
4. Which organisation, deployer or system owner is accountable for this execution? ownership

Step decomposition and deliberation capture

The ordered, nested set of steps making up the run, and the treatment of intermediate reasoning. OpenTelemetry defines plan spans for task decomposition and counts inference_calls and tool_calls per agent invocation; Anthropic returns thinking blocks as first-class content. Reasoning content is high-sensitivity and often subject to a shorter retention rule than the final output, so its capture policy must be recorded rather than assumed.

1. How is the run decomposed into ordered steps, and what identifies each step uniquely within the run? composition
2. What parent-child relationships hold between orchestration steps, model-call steps and tool-call steps? relationship
3. Are intermediate reasoning or planning outputs captured, and under which disclosure and retention rule? retention
4. How many model calls and tool calls did the run make, and were any iteration limits reached? measurement

Tool call record and effect character

For each tool invocation: what was called, with what arguments, what came back, whether it failed, and what side-effect character the tool declared. MCP separates protocol errors (JSON-RPC error) from tool execution errors (isError true in the result) and warns that annotations are untrusted unless the server is trusted, so the record must keep the declaration and the trust judgement apart. Retries, timeouts and multi-round-trip input-required flows must be linked to one logical call.

1. For each tool call, which tool on which server was invoked, with which arguments, and what did it return? process
2. Did the call fail at protocol level or return an execution error, and how is that distinction preserved in the record? exception
3. What side-effect character did the tool declare - read-only, destructive, idempotent, open-world - and was that declaration treated as trusted? security
4. How are retries, timeouts, cancellations and input-required round trips of the same logical call linked together? state

Retrieval and grounding evidence

Which knowledge sources were consulted and which retrieved items entered the model context. OpenTelemetry defines gen_ai.data_source.id for retrieval and grounding, but nothing normative pins the retrieved item to a resolvable version, so the run must record item references with digests and retrieval instants if the grounding is to be re-examined later.

1. Which data sources or knowledge bases were queried to ground this run's output? relationship
2. Which specific retrieved items entered the model context, and can each be re-resolved at the version that was used? evidence
3. How fresh and how authoritative was the retrieved content at the instant it was used? quality

Sub-run and multi-agent delegation

Which sub-runs the run spawned, on whose authority each acted, and how their results roll up. OpenTelemetry provides invoke_workflow for coordinated multi-agent processes but defines no rollup semantics; PROV-O supplies actedOnBehalfOf for the responsibility chain. Unbounded recursion and authority widening across hops are the two failure modes the record has to make visible.

1. Which sub-runs or delegated agent invocations did this run spawn, and in which order? composition
2. On whose authority did each sub-agent act, and was the granted authority narrowed at every delegation hop? authority
3. How are the cost, failure and output of a sub-run rolled up into the parent without double counting? measurement
4. What terminates a delegation chain, and what prevents unbounded recursion or fan-out? constraint

Run state machine and termination outcome

The legal states of a run and how it ended. OpenTelemetry records gen_ai.response.finish_reasons as an array and a Stable error.type when an operation ends in error; Anthropic returns stop_reason values end_turn, max_tokens and stop_sequence. A truncated run is neither a clean success nor a failure, and conflating the two destroys audit value.

1. What is the complete set of run states, and which transitions between them are legal? lifecycle
2. In which state did the run terminate, and for what stated reason? state
3. How is a partially completed or truncated run distinguished from an outright failure for audit purposes? classification
4. Which low-cardinality error type is recorded when the run ends in error, and where does the full diagnostic live? exception

Temporal semantics and latency measures

Every instant on the run, in a single governed format, with event time kept apart from observation, ingestion and billing-bucket time. RFC 3339 requires an explicit numeric offset or Z and reserves -00:00 for an unknown local offset. Anthropic's usage reporting is bucketed with a stated freshness lag, so cost timestamps are demonstrably not the same clock as execution timestamps.

1. What are the run's start and end instants, and in which format and offset are they expressed? temporal
2. How is the instant at which the run occurred distinguished from the instants at which it was observed, ingested and billed? provenance
3. Which latency measures are recorded, and from whose vantage point are they measured? measurement
4. Which clock source produced these instants, and what skew is tolerated before ordering becomes unreliable? constraint

Retries, cancellation, compaction and fetch-without-inference

Rare but specified endings: automatic retries folded into one logical span; cancellation or timeout; gen_ai.conversation.compacted indicating the effective context is a compacted view of a prior conversation and must not be set to false; and fetch_response, which loads a previously generated response by identifier without performing inference and must not report token usage. These cases are easy to omit from naive chat-only schemas.

1. Were transient automatic retries folded into this logical run, and how many attempts occurred? process
2. Was the run cancelled or terminated by timeout before a model finish reason was produced? lifecycle
3. Was the effective conversation context a compacted view of a prior conversation, and was the compacted attribute left unset rather than set to false when unknown? constraint
4. Is this a fetch of a stored response without inference, and were token usage attributes and metrics omitted as required? classification

Output content, structure and evidence

The content blocks the run produced, whether they validated against a declared schema, and how they are digested and referenced. MCP requires servers to make structured results conform to a declared outputSchema and clients to validate them; Bedrock externalises outputs above 100 KB. Which parts a human actually saw is a distinct and audit-relevant fact.

1. Which content blocks did the run produce, in which modalities and in which order? composition
2. Was the output schema-constrained, and did it validate against the declared output schema? validation
3. How is the output stored, digested and referenced so a later reader can prove what was actually returned? evidence
4. Which parts of the output were presented to a human, and which were consumed only by downstream machinery? access

Generated asset provenance and AI disclosure

For media assets the run produced, whether a signed content-provenance manifest is attached and what it asserts. C2PA 2.2 binds assertions and a claim through a claim signature with a hard binding to the content, and the c2pa.actions assertion carries a digitalSourceType disclosing generative-AI involvement. No normative C2PA field carries a run identifier, so the binding back to this model is an adopting-Dimension convention.

1. For each media asset produced, is a signed provenance manifest attached, and which assertions does it carry? provenance
2. Is the asset marked as AI-generated using a recognised digital source type, and does that marking survive downstream processing? interoperability
3. How is the manifest bound back to this run and to the ingredients that were consumed to create the asset? relationship

Principals, credentials and delegation of rights

Which principal initiated the run and whose credentials were presented to each downstream resource. MCP requires tokens to be validated as issued specifically for the receiving server and forbids servers accepting or transiting foreign tokens; Bedrock records identity.arn for the calling principal. The record captures who and with what scope, never the credential material itself.

1. Which principal initiated this run, and whose credentials were presented against each downstream resource? authority
2. Which scopes were granted, and was each access token bound to the specific resource it was used against? security
3. Where the agent acted on behalf of a person or organisation, how is that on-behalf-of chain recorded? provenance
4. How is an end user identified in the run record without persisting direct personal identifiers? privacy

Human oversight, approval and intervention

Human decisions taken inside the run. MCP states there SHOULD always be a human able to deny tool invocations and that clients should show tool inputs before calling; EU AI Act Article 12(3)(d) requires identifying the natural persons involved in verifying results for Annex III point 1(a) systems. The record must capture what the decider was shown, not only what they decided.

1. Which actions in this run required explicit human approval before they could execute? decision
2. Who approved or denied each gated action, at what instant, and what information were they shown at the time? evidence
3. Was the run paused, stopped or overridden by a human, and what effect did that have on the trajectory? event
4. How is a missing but required approval detected, escalated and recorded as a non-conformity? exception

Provenance attribution, ownership and accountability

How the run maps onto a formal provenance model and who is answerable. PROV-O types the run as an Activity with used and wasGeneratedBy edges to its inputs and outputs and wasAssociatedWith to its agent. Separately, EU AI Act Article 19 puts the log-keeping duty on the provider for logs under their control, which differs from the deployer who is answerable for effects, so record owner and accountable party are two distinct fields.

1. Which provenance classes and properties does this run map to, and what are the resolvable IRIs for its activity and agents? provenance
2. Who owns the run record, and who is the accountable deployer answerable for the run's effects? ownership
3. Which outputs were derived from which inputs and retrieved items, and is that derivation edge explicit rather than inferred? relationship
4. Under which tenant, workspace, project or cost centre is this run attributed? classification

Token and resource consumption

What the run consumed. OpenTelemetry defines gen_ai.client.token.usage with token types input and output only, while providers report a richer set including cache-creation, cache-read and reasoning tokens, plus server-side tool use. Provider-reported counts and locally computed counts routinely disagree, so the reconciliation rule must be explicit.

1. How many input, output, cache-read, cache-creation and reasoning tokens did the run consume? measurement
2. Which non-token resources were consumed, and how is that set enumerated for this operation type? composition
3. How are provider-reported counts reconciled with locally computed counts when the two disagree? validation
4. Into which measurement time bucket is usage assigned when the run spans a bucket boundary? temporal

Cost attribution and reconciliation

What the run cost and how confident that figure is. No GenAI telemetry standard defines a cost metric, and authoritative cost is published as daily aggregates in a single currency with a data-freshness lag and known exclusions such as priority-tier pricing. Per-run cost is therefore an estimate until reconciled, and the record must say which it is.

1. What monetary cost is attributed to this run, in which currency and against which price basis? measurement
2. Is the recorded cost a local estimate or an authoritative billed amount, and how is that status flagged and later upgraded? provenance
3. To which API key, workspace, service tier and cost centre is this run's cost charged? ownership
4. How are sub-run costs and cached-token savings allocated so that nothing is counted twice? constraint

Evaluation results and outcome quality

Assessments bound to the run. OpenTelemetry defines gen_ai.evaluation.result as its own event, capable of being emitted independently of the trace, which means evaluation is frequently asynchronous and arrives after the run has closed. Human feedback is a distinct signal from automated evaluation and must not be merged into the same score field.

1. Which evaluations were performed against this run's output, by which evaluator and at which evaluator version? quality
2. What score, label or verdict did each evaluation produce, and on what scale is it interpretable? measurement
3. Was the evaluation performed inline during the run or asynchronously afterwards, and how late may it still arrive? temporal
4. How is human feedback on the run captured and kept distinguishable from automated evaluation? evidence

Guardrail and policy decisions

Policy checks applied to inputs and outputs, their verdicts, and the policy version in force. A blocked or refused run creates a genuine tension: the record must prove the block occurred without persisting the prohibited content, so the model records decision metadata and digests rather than the content itself.

1. Which policy or guardrail checks were applied to this run's inputs, intermediate steps and outputs? security
2. What did each check decide - allow, transform or block - and what exactly was modified? decision
3. Which policy version was in force at the instant of each decision? provenance
4. How is a blocked or refused run evidenced without persisting the prohibited content itself? privacy

Statutory log content, retention and disposal

The regulated content and lifespan of the record. Article 19 requires providers to keep automatically generated logs under their control for a period appropriate to the intended purpose and at least six months unless other Union or national law provides otherwise, with financial institutions keeping them under sectoral rules. That floor collides with data-minimisation and erasure duties, so the reconciliation rule must be recorded rather than left to the operator.

1. Which regulated minimum log elements must this run's record contain, and is each one demonstrably present? requirement
2. For how long must the record be kept, counted from which start point, and on which legal basis? retention
3. Who holds the logs when provider and deployer differ, and how is the phrase under their control demonstrated? ownership
4. How are erasure requests, legal holds and statutory minimum-retention duties reconciled when they conflict? exception
5. What exactly is destroyed at end of life, and what tombstone remains to prove the record once existed? lifecycle

Record integrity and tamper evidence

How a closed run record is made alteration-evident. C2PA demonstrates the pattern that matters here: assertions gathered into a claim, hashed, and covered by a claim signature verifiable against a trust anchor. A run record without a seal cannot support an accountability claim, and corrections must be recorded as new assertions rather than overwrites.

1. How is the run record sealed at close so that any later alteration becomes detectable? security
2. Which fields become immutable when the run closes, and which may still legitimately be appended afterwards? constraint
3. How is a correction recorded without overwriting the original assertion? lifecycle
4. Who can verify the seal, against which trust anchor, and what happens when verification fails? validation

Access scoping and confidentiality of run content

Separating access to run metadata from access to run content. OpenTelemetry warns explicitly that input messages, output messages, system instructions, prompt variables and tool definitions are likely to contain sensitive and personal data, which makes field-level rather than record-level access control the default position. Residency constraints on the record may differ from those on the inference itself.

1. Who may read run inputs and outputs, as opposed to run metadata and measures only? access
2. Which fields are classified as sensitive, and what masking or truncation applies by default? privacy
3. Which accesses to the run record must themselves be logged, and what does that access log capture? security
4. Which residency or cross-border constraints bind the record, and how do they differ from the constraints on the inference itself? spatial

Export profiles and schema mapping

Projecting the run into external schemas and importing foreign run records without silently mis-stating their origin. Because gen_ai.* attributes are still in Development status, and providers differ in identifiers and usage fields, every mapping is provisional and lossy in known ways; the model records the loss rather than claiming conformance.

1. Into which external schemas can a run record be projected, and which profile governs each projection? interoperability
2. Which fields have no target in a given external schema, and how is that loss declared to the consumer? constraint
3. How are vendor-specific attributes carried without polluting the canonical model? definition
4. How is an imported third-party run record marked as externally asserted rather than locally observed? provenance