Context Signals: Verifiable AI Inputs

What context signals are

Inputs and outputs describe what a model processed. Context signals describe the conditions under which it operated. They are the difference between knowing what happened and knowing why the environment was configured the way it was.

Every AI execution occurs within an environment that shapes the result: available tools, permission boundaries, loaded memory, active constraints. These conditions are typically implicit and ephemeral. Context signals make them explicit, structured, and preserved.

Examples include:

• Tool availability. Which tools were registered and accessible during execution.
• Permissions scope. What the agent was authorized to do at execution time.
• Memory state. What prior context, conversation history, or retrieval results were loaded.
• Session metadata. Identifiers linking the execution to a broader workflow or user session.
• Runtime configuration. Environment flags, feature toggles, or constraint parameters active during execution.
• Execution constraints. Token limits, timeout thresholds, or cost boundaries that bounded the output.

What context signals are not

Context signals occupy a specific position in a Certified Execution Record. They are not inputs, outputs, or model parameters. Those have their own fields. Context signals capture execution conditions, not the content the model directly processed.

• They are not logs. Logs are unstructured, mutable, and system-dependent. Context signals are structured fields sealed into the cryptographic envelope.
• They are not telemetry. Telemetry measures system performance. Context signals record the conditions that influenced the result.
• They are not optional annotations. When present in a CER, they are hashed into the certificateHash. Altering them breaks the record.

How context signals are captured and bound

The execution layer collects context signals at runtime and includes them in the CER bundle before hash computation. Once the certificateHash is computed, they become inseparable from the record.

Like all CER fields, context signals follow deterministic canonicalization rules. Values are normalized to a stable byte sequence before hashing, so the same environment always produces the same hash contribution regardless of field ordering or serialization format.

If a context signal is modified after sealing, the hash changes and verification fails. There is no way to silently alter what was recorded.

How context signals relate to Certified Execution Records

A Certified Execution Record captures inputs, parameters, outputs, and tool calls. Context signals extend that coverage to the execution environment itself.

Without context signals, a CER proves what the model received and returned. With them, it also proves the operational conditions that shaped the result. This distinction is central to certified decisions, where understanding the decision environment is as important as understanding the decision itself.

Context signals are defined in the AI Execution Integrity specification as optional but hash-protected fields within the CER snapshot structure.

How context signals support auditability

Auditors and compliance reviewers need to understand not just what an AI system decided, but under what conditions. Context signals provide that evidence in a structured, machine-readable format that cannot be retroactively altered.

• Permission audits. Confirm that an agent operated within its authorized scope at execution time.
• Environment reconstruction. Reconstruct exactly what tools, memory, and constraints were active when a decision was produced.
• Compliance evidence. Demonstrate to regulators that AI executions occurred under documented, verifiable conditions. See standards alignment for framework mapping.

Because context signals are sealed into the record, they provide evidence that traditional logs cannot match: structured, portable, and resistant to post-hoc modification.

Context signals in agent workflows

Agent execution workflows involve multiple steps where conditions shift between each decision. Tools may be added or revoked. Permissions may narrow. Memory accumulates.

Context signals capture these per-step conditions, creating a verifiable record of how the agent's operating environment evolved across the workflow. For multi-step decision chains, this is what connects individual steps into an auditable sequence: not just what the agent decided, but the specific conditions each decision was made under.