Frequently asked questions

Common questions about HOOTL — its relationship to other frameworks, licensing, sector adoption, and how to contribute.

Is this anti-OpenAI?

No. The OpenAI Frontier Safety Blueprint is a serious document; the Preparedness Framework and Frontier Governance Framework do real work. HOOTL is complementary — it addresses the operator-side layer that lab-side frameworks structurally cannot. A serious AI safety policy framework needs both. The launch essay ("What the OpenAI Frontier Safety Blueprint Leaves Out") makes the case explicitly.

How does this relate to the NIST AI Risk Management Framework?

NIST AI RMF is one of the foundational vocabularies HOOTL draws from. The bibliography of the Principles cites NIST AI RMF, OECD AI Principles, the EU AI Act, and the Belmont Report as the tradition HOOTL stands in. NIST AI RMF is broader (covering governance and management functions across all AI systems); HOOTL is narrower and more specific (eight numbered substrate-property primitives for HOOTL-posture systems specifically). The two are designed to compose.

How does HOOTL relate to the EU AI Act?

The EU AI Act addresses many operator obligations in regulated sectors, but lacks codified vocabulary for the substrate properties of an autonomous-agent runtime as a system. HOOTL is designed to plug into that gap. The principles are jurisdiction-neutral by construction — they describe technical and operational characteristics that hold across strict-liability, negligence-based, operator-responsibility, and hybrid regimes.

Can I cite or adapt the principles in my own work?

Yes, without permission. The spec is licensed CC-BY 4.0 — attribution required, commercial use permitted, adaptation permitted. Cite "Winegar, T. (2026). Principles of HOOTL Safety (v1.0). hootl.org." In-text citation pattern is "per HOOTL-3 (Override Channel)".

Can I profile HOOTL for my sector?

Yes — this is one of the explicit intended uses. Healthcare, finance, critical infrastructure, defense, government, transportation, and energy all have specific operator-side requirements that the eight principles are shaped to accommodate. A sector profile would typically map each principle onto sector-specific failure modes, name the artifacts the sector already produces that satisfy or fail to satisfy each principle, and add sector-specific guardrails. We're actively interested in collaborating on such profiles — email if you're working on one.

Why a new framework when there are already so many?

The existing frontier-safety frameworks (OpenAI Preparedness, Anthropic RSP, Google DeepMind FSF) are all lab-side. METR's "Common Elements" survey across twelve frameworks confirms this — nine recurring elements across all of them, all lab-side. Operator-side substrate properties are not absent because they're unimportant; they're absent because the existing frameworks are structurally positioned to address model release, not runtime deployment. HOOTL fills the layer that isn't otherwise served.

Is HOOTL a standard, a specification, or a regulation?

None of those. HOOTL is a concepts document — a stable, citable vocabulary of substrate properties that policy authors, vendors, auditors, and operators can use in their own work. The principles are properties of safe systems; jurisdictions remain free to wrap them with whatever liability framework is appropriate to local doctrine. This is the same shape the Belmont Report (1979) took for research ethics — a set of principles that became citable load-bearing language in other parties' rules.

What does "operator-side" mean exactly?

The lab is the party that trains and releases a frontier model. The operator is the party that deploys a model in a system that runs autonomously. The two are usually different parties. The lab's safety responsibility ends at release. The operator's begins there. HOOTL describes what the operator-side runtime needs to be for autonomous deployment to be accountable, regardless of which lab released the underlying model.

How does HOOTL relate to AgentDNA and AgenticMD?

They're three frameworks I've been developing this year that share a single thesis (substrate is truth) at three different layers. AgenticMD is markup discipline for agent-consumed documentation. AgentDNA is a substrate-first agent operating framework. HOOTL is substrate-property safety principles for autonomous-agent systems. An agentic IDE I build is the reference implementation of all three. See About for the framework family lineage.

The three cross-check each other in practice: AgentDNA's newest organ — the completion gate — is the agent-protocol expression of HOOTL-2 (Verdict Pipeline) and HOOTL-7 (Falsifiability). The same property appears as a safety principle at the HOOTL layer and an operating organ at the AgentDNA layer.

I think HOOTL-X is wrong, missing, or should be reworded.

Open an issue at github.com/traviswinegar/hootl or email travis@momusdev.com. The framework is versioned (currently v1.0); subsequent versions can add, refine, or rephrase principles. The numbering scheme is explicitly stable across versions, so citations don't break when prose evolves.

How do I propose a HOOTL-9?

Same as above — open an issue with the proposed property, the failure mode it addresses, and a brief argument for why it isn't already covered by the existing eight. Substrate-property additions are the kind of contribution most likely to land in v1.1 or v2.0.

Is there a reference implementation I can study?

The framework was extracted from a working agentic IDE. Its substrate (graph DB, ADR cluster, behavioral tests, audit harness, council reviewer, mutator) all pre-existed the framework — the framework names the substrate properties that those concrete systems exhibit. The reference implementation itself isn't public; the framework is the abstraction you can adopt anywhere.

Question not answered here? Email it, or open an issue on GitHub. Common ones land here.