The AI safety conversation has been dominated, productively, by questions about what models output. Does the model produce harmful content? Does it refuse appropriate requests? Does it hallucinate? These are important questions and significant engineering effort has gone into addressing them. The runtime integrity question is different, and it has received much less attention: is the execution substrate that wraps the model trustworthy between invocations? Does the governance state remain intact across restarts? Does the audit chain remain unbroken through system failures?
Model safety is about the output of a single inference. Runtime integrity is about the trustworthiness of the system that governs a sequence of inferences over time. They are related problems, but they are not the same problem, and addressing one does not address the other.
The Model-Centric Blind Spot
Most current AI safety thinking treats the model as the primary unit of analysis. A safer model produces safer outputs. Fine-tune the model, add RLHF, implement Constitutional AI principles, run output filtering — all of these interventions target the model. This is the right starting point. It is not the complete picture.
Consider what happens when a production AI system restarts after an infrastructure failure. The model is restored from its checkpoint — identical weights, identical behavior. But what about the governance state? The accumulated audit chain? The policy configuration that was active at the time of failure? The session state that established context for ongoing multi-turn interactions?
In a model-centric safety architecture, these questions are often answered casually: the system prompt re-establishes the policy. The audit log picks up from the last successful write. Each of these answers introduces a continuity gap — a period during which the system's behavior cannot be fully audited.
What Runtime Integrity Requires
Runtime integrity is the property that the execution substrate — the governance configuration, the audit state, the policy enforcement mechanisms — remains consistent, detectable-as-modified, and recoverable across all operating conditions including planned and unplanned restarts. This requires several components that are absent from purely model-centric safety architectures:
- Governance state sealing. The governance configuration — policy rules, enforcement thresholds, charter principles — must be sealed at deployment time with a cryptographic commitment. Any subsequent modification must either produce a new sealed state with a corresponding audit record, or be detectable as an unauthorized modification.
- Chain continuity across restarts. The audit chain must resume deterministically after any interruption. This requires that the last committed chain state — the tail hash of the most recent confirmed audit record — be persisted in a way that survives the restart and is verifiable.
- Startup attestation. At startup, the system should perform a self-attestation: verify that the governance configuration matches the sealed commitment, verify that the audit chain tail matches the persisted tail, and produce a signed startup record that can be independently verified.
- Immutable runtime configuration. The governance configuration must not be modifiable through normal request processing. An attacker who gains the ability to send requests to the system should not be able to modify policy thresholds or change enforcement behavior.
Split-Chain Events and Why They Matter
A split-chain event occurs when the audit chain is interrupted and resumed without a verifiable continuity proof. The canonical causes are:
- System restart after a crash where the tail hash was not persisted
- Migration to new infrastructure without carrying the chain state
- Manual intervention that modified records without updating the chain
- Clock skew during distributed write operations that creates ambiguous ordering
In a financial services context, a split-chain event is approximately equivalent to a gap in the transaction ledger. The records on either side of the gap may be accurate, but the gap itself means the chain cannot be used as a reliable audit instrument: you cannot prove that records were not inserted into or deleted from the period covered by the gap.
Preventing split-chain events requires that chain continuity be a first-class infrastructure concern, not an afterthought. The tail hash is a piece of infrastructure state as critical as the database connection string. Systems that do not treat it as such will produce split chains eventually.
The Immutable Runtime State Model
The full model of runtime integrity treats the following as immutable during operation:
- Charter principles. The set of hard constraints that cannot be overridden by any request, configuration, or operator action. These are compiled into the runtime at deployment and cannot be modified without a new deployment.
- Policy rule set version. The specific version of the domain policy rules active for a given tenant. Version changes require an explicit, audited change event.
- Signing keys. The keys used to sign governance decisions. Key rotation produces an explicit rotation record in the audit chain.
- Chain tail. The hash of the most recently committed audit record. This is read-only at runtime — only the append mechanism can advance it.
Items that can change during operation, but only through audited pathways: tenant policy configurations via the policy management API with change records, and session state reconstructed from persistent storage on restart. Items that can change freely: LLM inference outputs, cached intermediate computations, and connection pool state.
The distinction between these categories is what makes runtime integrity auditable. If everything can change freely, nothing can be audited meaningfully. If the governance-critical state is immutable or change-audited, the system's compliance posture can be established and maintained across time.
Why This Is a Procurement Question
Enterprise buyers evaluating AI systems should add runtime integrity questions to their procurement checklist alongside the standard model safety questions:
- What happens to the governance state across a system restart?
- Can you demonstrate chain continuity across a historical restart event?
- How is the governance configuration sealed and how are modifications detected?
- What constitutes a split-chain event in your system and how is it reported?
These questions distinguish systems that have thought seriously about the full operational lifecycle from systems that have addressed model safety but left the infrastructure substrate unexamined. Model safety is necessary. Runtime integrity is what makes model safety durable.