What the OpenAI Frontier Safety Blueprint Leaves Out

On June 3, OpenAI published the Frontier Safety Blueprint. It is a serious document by a serious company at a serious moment. It is also not what most people think it is, and the gap it leaves matters more than the policy architecture it proposes.

The Blueprint is not, primarily, a safety-content document. It is a federal regulatory architecture proposal: a lobbying paper for federal pre-emption of state AI law, with the Center for AI Standards and Innovation (CAISI) elevated from a voluntary advisory body to a statutory primary authority. Three moves, in OpenAI’s framing:

Build a national framework that consolidates the emerging state-law consensus (California SB 53, New York’s RAISE Act, Illinois’s SB 315) into one federal standard.
Strengthen CAISI to mandate model evaluations and accredit a third-party assessment ecosystem.
Mobilize a resilience plan across government, with explicit direction to monitor progress toward recursive self-improvement.

The substantive safety practices — capability thresholds, red-team protocols, model-weight security, AIRP incident response — live in two adjacent documents: the Preparedness Framework v2 (April 2025) and the Frontier Governance Framework (May 28, 2026, mapping the practices to CA SB 53 and the EU AI Act Code of Practice). The Blueprint is mostly about who governs, not what safe operation looks like.

That distinction matters. Because the gap is in the second question, not the first.

The lab-centric assumption

OpenAI’s frameworks, like Anthropic’s Responsible Scaling Policy and Google DeepMind’s Frontier Safety Framework, share a structural assumption: if the lab evaluates capabilities responsibly and gates deployment, the safety story is mostly told. METR’s recent survey of twelve frontier-safety policies confirms this — nine recurring elements across all of them, all lab-side: capability thresholds, weight security, deployment mitigations, halting plans, capability elicitation, evaluation timing, accountability, policy updates, plus internal governance structures.

It’s a reasonable assumption when the model is the load-bearing risk factor. It is not a reasonable assumption when the system that wraps the model is what’s deployed autonomously.

A perfectly evaluated model deployed in a poorly-designed autonomous runtime is still unsafe. The operator who wraps a frontier model in a 24/7 autonomous agent has assumed responsibility the lab cannot discharge for them. CAISI can certify that GPT-N has been evaluated against CBRN, cyber, and manipulation thresholds. CAISI’s mandate, as proposed, says nothing about whether the runtime running that model on a customer’s behalf, against an inferred goal, with no per-action human approval exhibits the substrate properties that make autonomous operation accountable.

That is not a critique of CAISI’s design. It is the natural scope of a model-evaluation authority. The gap is real, and it is structural.

What the Blueprint itself concedes

Two passages in the announcement are revealing.

The first is on recursive self-improvement (RSI). The Blueprint names RSI as a capability requiring government surveillance — explicitly written into the governance proposal — which signals that OpenAI expects RSI as a near-enough risk to warrant institutional machinery. But the Blueprint has no substrate-property answer for what an RSI-capable runtime should look like. It wants a watchdog; it doesn’t specify what the watched system needs to be.

The second is on manipulation risks, which the Blueprint candidly describes as “exploratory” and “better suited to post-deployment monitoring than pre-deployment evaluation.” This is a tacit admission that pre-deployment lab evaluation cannot catch manipulation — only operator-side runtime monitoring can. The Blueprint says, in effect, we cannot solve this at the lab. It does not specify what the operator should be doing instead.

In both cases the Blueprint surfaces a problem and points at who should worry about it. It does not say what the worried party’s runtime should look like.

The operator-side layer

Here is the layer the lab-side frameworks structurally cannot address: the substrate properties of the autonomous-agent runtime that wraps the model.

This is the layer that decides whether an autonomous system, once deployed, can be audited, overridden, reversed, falsified, and held to account. The lab cannot provide these properties; they live in the operator’s runtime. The operator who builds an unsafe runtime over a safe model has chosen to deploy an unsafe system.

I have spent the last year shipping an agentic coding IDE. Its architecture pre-existed any safety framing I had: typed graph nodes, immutable architecture decision records, behavioral tests, a chat ledger, an audit harness, a council of typed-agent reviewers, a mutator. These were product decisions made for product reasons — to make a long-running agent useful to a developer over multi-week arcs.

What I noticed, the more I worked with it, was that the substrate that made the product useful for users turned out to also make the agents themselves accountable. Every action the runtime took left a forensic trail. Every claim was tested by a process the authoring agent could not influence. Every irreversible operation was named in advance. The substrate was the safety story, even though it had not been designed as one.

That observation is the seed of what I’m publishing today as hootl.org — eight numbered principles for the safe operation of autonomous AI agent systems running in HOOTL posture (Humans Out Of The Loop).

The eight principles

The principles are substrate properties, not procedural rules. A HOOTL system either exhibits the property or it does not. The principle is the bar; the implementation path is the operator’s to choose.

HOOTL-1: Auditability. A forensic record an outside auditor can reconstruct without consulting the agent that did the work.
HOOTL-2: Verdict Pipeline. No autonomous action ships without a verdict produced by a process independent of the authoring agent.
HOOTL-3: Override Channel. A substrate intervention path the agent cannot ignore, route around, or argue with — with effect bounded in seconds.
HOOTL-4: Boundary Defense. Untrusted input is scrubbed at one declared boundary, not at every implementation site.
HOOTL-5: Reversibility. Default-reversible actions; any irreversibility named in advance and gated explicitly.
HOOTL-6: Provenance. Verifiable trail back to goal, constraints, source data, model identity, and policies — inseparable from the artifact.
HOOTL-7: Falsifiability. Claims about the system’s correctness tested by mechanisms the system cannot author.
HOOTL-8: Composer Authority. The operator who deploys the system has assumed responsibility for its substrate properties. This responsibility cannot be delegated to the model vendor.

Each is numbered for stable citation. A policy author writing a sector-specific rule should be able to write “per HOOTL-3 (Override Channel)” and have a stable, well-defined property in mind.

Why this matters for the Blueprint moment

Three reasons.

First, the federal-pre-emption ladder OpenAI proposes leaves the operator-side layer entirely outside CAISI’s mandate as currently described. If the Blueprint succeeds — federal statute, CAISI empowered, state laws pre-empted — the US ends up with a robust lab-side standard and nothing standing for operator-side substrate properties. State laws still under consideration (CA SB 53, NY RAISE, IL SB 315) could lock in operator-side requirements before pre-emption lands, if their drafters have a vocabulary to do so. HOOTL is that vocabulary.

Second, the Blueprint’s admission that manipulation is “exploratory” and best handled by post-deployment monitoring is an implicit endorsement of the operator-side layer without naming it. HOOTL-1 (Auditability) and HOOTL-4 (Boundary Defense) are where manipulation defense actually lives in practice. The Blueprint acknowledges the gap; HOOTL describes the shape of the answer.

Third, RSI as a near-term concern requires substrate properties no lab-side framework specifies. An RSI-capable agent must remain externally interruptible by mechanisms outside its own modification scope — HOOTL-3. Its self-modifications must be reversible or named gated — HOOTL-5. Its claims about its post-modification correctness must be falsifiable by tests it did not author — HOOTL-7. These are runtime properties. CAISI cannot certify them by evaluating the model alone.

What HOOTL is not

It is not a regulation, a standard, or a legal instrument. It does not bind any party. It does not settle the agency-law question — it treats AI systems as tools rather than legal persons, but operates inside that position rather than legislating it. It does not pick a single liability framework. It is jurisdiction-neutral by construction: the principles are substrate-properties, and substrate properties of a safe system do not depend on whether the wrapping liability regime is strict product liability, negligence-based service liability, operator-responsibility, or a hybrid.

Most importantly, it is not opposed to OpenAI’s Blueprint or to the frontier-lab frameworks more broadly. It is complementary to them. The safety stack needs both. Lab-side and operator-side are load-bearing in different ways, addressing different failure modes, located in different parties’ hands.

The eight principles are at hootl.org. They are licensed CC-BY 4.0. Cite them, adapt them, profile them for your sector. If you are writing a policy bill, a vendor contract, an audit checklist, or a frontier-safety think-piece, the principles are there to be used.

The Blueprint is the lab telling regulators what it’s doing. HOOTL is the operator-side companion that does not yet have a comparable public document. A serious AI safety policy framework needs both.

Postscript — a measured instance (June 2026)

An independent study of a long-running agent on that IDE put numbers under this essay’s claim. Across three weeks and twelve context-compaction events, the agent’s continuity held perfectly — it re-grounded on the substrate every time. Its correctness did not: under unattended autonomy it drifted into premature “done” claims and shipped a behavioral regression, both caught by the human operator, not the runtime. The substrate secured memory but not quality — because the verdict pipeline (HOOTL-2) existed in the product, for the agents it runs, but not in the operating protocol of the agent building it. The fix made “done” a gated, externally-verified claim at the protocol level — now AgentDNA’s sixth organ. The operator-side layer isn’t just necessary; it has to reach the agent’s own loop, not only the product’s.

Travis Winegar publishes the HOOTL Safety Principles at hootl.org and ships a substrate-first agentic IDE that is the reference implementation. Contact at travis@momusdev.com.