A brake is not a heading
The debate over AI risk argues about who sets the brakes. For those who use these tools every day the question is simpler and less comfortable: is what I’m using governable, do I know its territory, and do I know where it’s heading?
On September 10, 2026, IBTimes published “AI Researcher Warns Humanity Could Be at Risk by 2030”. Jacob Coxon, after three years researching model pretraining at OpenAI and Anthropic, left Anthropic with this line: “Neither company is acting responsibly. They are racing straight to self-improving superintelligence and gambling with our lives.” Evan Hubinger, also from Anthropic, agreed and admitted: “we do not yet have a plan to solve alignment for superintelligence and are not clearly on track to.”
The response the piece records centers on one question: who brakes. A law to ban superintelligence and pause the rest of advanced development “until a federal regulator creates safety rules”. Another for a kill switch. A special session in Congress. And, against it, the Treasury secretary: the United States can’t pause “because the Chinese won’t pause”.
All of that is legitimate and probably necessary. But notice who shows up: companies, lawmakers, a future regulator, a rival country. A few people, arguing over who’s responsible, who holds the key, and who presses the button.
Meanwhile, every day more people use these tools to work. An organization coordinates projects with agents that open changes, draft decisions and close tasks. A team maintains servers with an agent that changes configurations. Someone writes a book with an agent that proposes notes and citations. For all those people, who don’t sign laws or train models, the useful question is a different one, and it’s common sense:
Is what I’m using governable? Do I know its territory? Do I know where it’s heading, and what needs adjusting when it changes?
This article is for that majority. It doesn’t argue whether AI is dangerous. It tells why ontoref decided what it decided in the face of those three questions. ontoref is a protocol: a way for a project to declare what it is, what it has decided and where it’s heading, so that people and agents can check it. It works for any project, and it specializes through domains: purpose-built extensions for a specific use and context. There are domains for project governance, infrastructure, authoring works, citable sources and a person’s professional life, among others. This article stops at three of them, in this order: project governance, infrastructure and authoring.
It’s not who governs, it’s whether it lets itself be governed
You can put the wisest, most responsible person in the world in charge of something. If what they’re running doesn’t say what it is, doesn’t let you see what it does, and doesn’t allow itself to be checked, there is no possible government. There will be authority, there will be ownership, there will be someone to blame. There will be no government.
ontoref separates those things on purpose, and it puts that in writing in its glossary. It distinguishes three words that everyday use blends together:
| Word | What it names | The question it answers |
|---|---|---|
| Governance | The arrangement: the boundaries, who is a member and what gets published. | How is it organized? |
| Government | The exercise: who acts and under what procedures. | Who acts, and how? |
| Governability | The capacity: “whether a subject admits government at all”. | Does it let itself be governed? |
And it declares that governability is a property of the protocol, not of any particular domain: it has to come before any arrangement and any exercise. Without it, the other two stay merely formal.
This isn’t a new idea. In 1970, Roger C. Conant and W. Ross Ashby proved a theorem whose title says it all: “Every Good Regulator of a System Must Be a Model of That System”. Every good regulator of a system has to be a model of that system. According to the authors themselves, the theorem changes the status of model-making “from optional to compulsory”. Put plainly: you can’t govern what isn’t described. That’s why the first thing ontoref asks is that the project describe itself. And recent writing on agent harnesses uses the same word: Birgitta Böckeler writes that technology and architecture decisions “determine how governable the codebase will be”.
And ontoref isn’t built as a body that commands, but so that anyone can check it. One of its invariant principles puts it this way: any actor, human or agent, can verify that a part is coherent with what’s declared without having knowledge of the whole. You don’t have to be the expert, or the owner, or the one who got there first. And in the ladder it uses to order what can be checked, the fifth rung (Accreditation) closes with a line that sums up the decision: “named responsibility, not a principle of authority”.
This isn’t a declaration of good intentions: it can be checked. You can ask ontoref which rules govern any file in a project. And it also answers the opposite, the uncomfortable part: which rules it can’t point at anywhere. It doesn’t hide them, it names them. A governable system is one that tells you where it isn’t.
To check it: what it looks like in the tool
ontoref governs <path> answers which architecture decisions (the ADRs) govern a file and through what route. ontoref governs coverage runs the reverse count over ontoref itself:
CONSTRAINT ROUTING COVERAGE
accepted ADRs 104
constraints 468
routable 441
declared non-path 21 ← say what they are; not a blind spot
STALE TYPED 0 ← declared a path, none of them resolves
UNTYPED 6 ← neither addressable nor declared. THIS is the blind spot.
of which ungated 6 ← the real blind spot: nothing addresses them AND nothing checks them
Of 468 constraints, 6 can’t be pointed at any file and no check looks at them. The tool doesn’t resolve it: it names it.
What isn’t written, someone invents
There’s a second commonsense point that the public debate barely touches.
You don’t give a compiler architecture instructions in prose. You don’t write “please try to make this safe.” A programming language has syntax, semantics and grammar: what doesn’t fit doesn’t get in. With AI agents we do the opposite. We write to them in natural language, often in one language that later gets translated, a good-intentions prose: be careful, don’t make things up, respect the conventions. That prose may or may not be read, and when it is read, it’s interpreted. The ground is, at best, shifting.
And there are also gaps. Every work, every system and every project assumes things that are written down nowhere. A person new to a team asks questions or makes mistakes slowly. An agent doesn’t stop: it fills what’s missing with something plausible in order to complete the task, with the inertia of answering fast and pleasing. It can’t produce anything coherent without filling the gap. The result is drift, divergence and, sometimes, hallucination over premises nobody checked.
We saw it up close a few days ago. An agent had the rule right in front of it and still filled a gap with an invented reference and attributed to the author words the author never said. The full case is in “Moving the rule is not enough” and its case file 2/26. One thing about it matters: the letter of the rule didn’t name the place where the agent wrote, and the reason behind the rule did cover it.
Two decisions of ontoref come out of that:
Decision 1 Decisions are written as typed data, not as prose
Every architecture decision is a file that gets validated, with constraints marked as hard or soft and, when possible, an associated check. What doesn’t fit the type doesn’t get in, same as with a compiler.
Decision 2 A rule holds where it runs, not where it’s read
The case left three questions for any rule: where does it run? does it check meaning or just a spelling? has anyone seen it reject what it forbids and accept what it allows? A rule that doesn’t pass those three is an intention, not a mechanism.
Braking is not steering
The guardrails and harnesses that wrap around agents do something necessary: they limit, filter and cut off. They act in the negative, preventing the undesirable. It’s the same thing the laws in the news propose, at a different scale.
That form of regulating, the kind that reacts once the error has already happened, has also had a name for half a century. Conant and Ashby called it “a primitive and demonstrably inferior method of regulation”, because with it “its success can only be partial”.
But a car with very good brakes and no steering wheel doesn’t get anywhere. What’s missing is the positive mode: remembering why and what for something is done, confirming that what’s running is still what was declared, and verifying knowing what’s been looked at and what hasn’t. The why and the what-for are the foundations of the what, the how, the when and the where. It isn’t about going slower, nor only about setting the rules of the game, although that too. It’s about not losing the heading while moving forward.
Chris Argyris explained it in 1977 with a thermostat. Correcting the temperature when it drifts is single-loop learning. If the thermostat could ask itself “whether it should be set at 68 degrees”, it would be able to question the goals too: that’s what Argyris called double-loop learning. Remembering why is that second loop.
ontoref orders what can be checked about a project into a ladder of seven rungs. Each one stands on the previous one, and each one is a question anyone understands:
| Rung | The question it asks | |
|---|---|---|
| 1 | Reason for being | Is what the project says it is still true, or is it a sentence nobody has re-read? |
| 2 | Reflection | What the project knows about itself — does it run and leave a trace, or is it only written down? |
| 3 | Categories and relations | Is it stated in a closed vocabulary a machine can validate? |
| 4 | Territory and criterion | Is it declared how far what’s governed reaches, and what measures that it still does? |
| 5 | Accreditation | Is the evidence of what was done verified, or only the report of whoever did it? |
| 6 | Observability | Is there a question that returns the distance between what’s declared and what’s there? |
| 7 | Knowledge lineage | Is it recorded where what the project knows comes from? |
Each rung, with what it presupposes, what checks it and why it matters, is explained in detail in the ladder and its rungs. The same walk, with each command’s real output, is in the mechanism slides.
Each rung declares conditions a machine can check: that a file exists, that a pattern appears. Passing those conditions is necessary, but not sufficient. That’s why, when ontoref reviews the whole ladder, under each rung it shows, alongside what’s met, the question no check can answer. And it closes with a line that leaves no room for doubt: no rung is taken as holding.
The machine confirms what it can. The question that decides stays, every time, in front of a person. There’s no binary pass-or-fail recipe; as David J. Snowden and Mary E. Boone point out, “best practice is, by definition, past practice”. There are more states: it holds, it fails, it couldn’t be checked (and then the tool says which part it couldn’t look at), and a question is left for someone’s judgment. Summing up the ladder with a score, seven out of seven, would be exactly the mistake ontoref forbids itself from making.
To check it: what it looks like in the tool
The review is ontoref ladder audit. Here’s how the first rung (Reason for being) comes out; the ? not read line is the question no check answers:
[Pass ] ladder reason-for-being:conditions
2 of 2 necessary condition(s) met — necessary, never sufficient: this is a verdict about the conditions, not about the rung
+ read: FileExists .ontoref/ontology/core.ncl [exists]
+ read: FileExists .ontoref/ontology/state.ncl [exists]
? not read: what settles the rung: Whether what the file answers is still the project's actual reason for being, or a sentence that stopped being true and nobody re-read. …
And here’s how the full review closes:
No rung is reported as HOLDING. Every verdict above is about a rung's
necessary conditions; what would settle the rung itself is the line
marked `? not read` under it, and no check answers that one.
Today the fourteen conditions across the seven rungs hold: eleven check that a file exists and three look for a pattern. Presenting the result as “N of 7 rungs passing” is named an anti-pattern in ADR-111.
And there’s one more reason not to turn it into a score. The same measure can be a lot on one plane and nothing on another. Generalized out of context, it polarizes or ranks. That’s why the ladder’s overview carries no figures: each measure is read within the plane where it’s used.
Three domains where it plays out
This isn’t theory. These are three cases that already happened and were measured, one per domain. In all three, the same thing happens: something looked fine, and it wasn’t.
Project governance: whoever declares the rules is also inside them
The first is ontoref’s own domain: how a set of projects is organized and under what procedures action is taken on them.
The first case is the most uncomfortable one. On August 24, 2026, it was measured that ontoref’s own repository type appeared in no domain. The tool that hands out rules to other projects was the only project with no domain of its own. It was outside its own government. That measurement is what the project governance domain came out of. There’s no exception for whoever writes the rules, and it’s the most direct application of “named responsibility, not a principle of authority”.
The second is more discreet. That domain declares seven procedures. Measured on August 14, 2026, one of them, governed delivery, had run twice in six weeks, while another ran twenty-six times, and both were equally present on disk. A check that only looks at what’s declared doesn’t distinguish a dormant procedure from an abandoned one. What got written down: that measurement is noted under the second rung (Reflection), and every review of the ladder prints it again. Seeing it doesn’t make the procedure get used. But without seeing it there’s nothing to decide.
To check it: the measurement, as every review prints it
Under the second rung (Reflection), ontoref ladder audit prints on every run:
measured 2026-08-14, governed-delivery ran twice in six weeks while generate-article ran twenty-six times, and both were equally present on disk.
Infrastructure: a silence
In the infrastructure domain (provisioning), a project suffered this on June 29, 2026. The component that connects the storage disks looked for the data in one directory, and the system that runs the services stored it in another. Every service that stores data wrote to the system disk instead of its volume. The image registry’s data was lost, the disk filled up, and the system started evicting services in a cascade. The case’s record sums it up in one line: no component reported a failure at any point; the failure was the silence.
What was declared said one thing and the territory did another. Nobody was lying. Nobody was looking.
What got written down. A check came out of the incident, and the check itself also had to be corrected. Its first version only looked at components that declared the directory. It passed green over a configuration that had another instance of the same failure, because the component that declared nothing slipped past it. The current version:
- fails if it finds nothing to check, because a green with no subject is the first step of the incident;
- has two halves: one compares what’s declared and the other looks at what the system actually runs;
- when it can’t reach the running system, it answers “unknown”, not “correct”;
- states its own limit: if everything declared is wrong in the same way, this half passes and the other fails.
Read against the ladder, and again this is a reading of my own, what weighs here is the fourth rung (Territory and criterion), a criterion that looks at all of its territory, and the sixth (Observability), a green that says what it has covered.
To check it: the case as it was recorded
The volume controller worked with /var/lib/kubelet, kubeadm’s default directory, while the Kubernetes distribution (k0s) stored the kubelet at /var/lib/data/k0s/kubelet. The case’s record, in the original:
No component reported a failure at any point — the failure mode IS the silence.
The check that came out of it declares its limit in these words:
A workspace where BOTH are wrong in the same way passes here and fails live.
Its declared half, run on September 14, 2026, finished with exit code 0: the three volume components declare /var/lib/data/k0s/kubelet.
Authoring: a citation that looks right
In the authoring (knowledge works) domain (its identifier is librosys), the unit is the work as a coherent whole: a book, for example.
An authoring project that uses it declares three content quality gates: that the glossary doesn’t define the same word two different ways, that no section is left without an exercise, a reflection or a concept, and that each step picks back up the concept from the one before. All three check coherence and completeness. None checks where a piece of data an agent inserts comes from.
A citation promises that the reader can go to the source. A citation that doesn’t resolve to anything passes review precisely because it looks correct. It’s the gap filled with something plausible, and here it does more damage than in a technical document: it attributes, quotes and speaks in the author’s name.
What got written down. The domain recorded the question without treating it as resolved: no gate today rejects a citation an agent inserted that doesn’t lead to a preserved or accessible source. And it wrote next to it what it would take to close it: a gate that checks the capability and not the form, and that someone has seen it reject a bad citation and accept a good one before trusting it. The model exists on the other side: ontoref already records where what it knows comes from, keeping custody of its sources separate from judgment about them (ADR-080). Read against the ladder, it’s the seventh rung’s (Knowledge lineage) question carried into a work. This is a reading of my own: ontoref doesn’t yet order the rungs by domain.
A territory that changes
The three cases have something in common: in none of them did a written rule fail. What failed was that the map and the terrain drifted apart without anyone noticing. A tool that hands out rules wasn’t inside them. A declared procedure barely ran. The declared directory wasn’t the one in use.
Knowing the territory isn’t making a map once. Projects change, tools change, and agents accelerate the changes. A map nobody re-reads stops describing the terrain without warning. Conant and Ashby foresaw this too: when the system changes, the regulator has to change with it, and regulating something that varies over time needs “a time-varying model”. Argyris found it in people: few know that they don’t use the theories they claim to follow, and so end up “prisoners of their own theories”. That’s why the answers in the three cases weren’t more rules, but ways of looking again: a domain created when the measurement called for it, a measurement every review reprints, a check with a half that looks at what’s actually running.
ontoref carries that idea to the whole project. It doesn’t just declare what a project is, but where it’s heading. Every dimension has a current state and a desired state, and the transition between them declares what blocks it and what drives it. Today, in ontoref itself, three of its dimensions have reached their desired state: protocol maturity, self-description coverage and ecosystem integration. The fourth, operational mode, is not a goal but a mode: it switches between local and daemon depending on whether the daemon is running, and what remains is keeping it up as a service. The heading is written down, you can ask what point it’s at, and you can adjust it when the ground shifts. That’s what makes it possible to transform and evolve without getting lost: not a fixed destination, but a distance that can be measured.
To check it: ontoref’s own declared heading
ontoref describe state shows each dimension with its current state and its desired one:
FSM Dimensions 4 total
protocol-maturity ✓ reached
Protocol Maturity horizon: Months
current: protocol-stable desired: protocol-stable
self-description-coverage ✓ reached
Self-Description Coverage horizon: Weeks
current: fully-self-described desired: fully-self-described
ecosystem-integration ✓ reached
Ecosystem Integration horizon: Months
current: multi-project desired: multi-project
operational-mode → in progress
Operational Mode horizon: Continuous
current: local desired: daemon
The fourth shows «in progress» because its state is detected when the command runs: with no daemon running, it reads local. Its transition also declares what blocks it and what would drive it.
A stance, not a mechanism
What follows has no command. It’s the ethical part, and it’s worth saying so plainly.
We’re facing new paradigms that call for different roles and different safety mechanics. But the roles we see in the debate aren’t new: the world’s savior, the one who doesn’t want to get their hands dirty, the smartest and fastest one, capable of solving any calculation no matter what it costs to get there. Add to that the polarization of truth, simplification so as not to feel fear, the inertia of wanting more and the faster the better, and the drive to be the protagonist.
There will always be risks and mistakes. But the risk isn’t borne only by a few, and the benefit shouldn’t belong only to a few either. If checking is left in the hands of whoever holds authority, most people can only trust or distrust. If what’s used is governable, anyone can check their part. Behind what we do there are ontological foundations and an ethics that shows up in every step: in a way of being and of using. That’s what gives a project its color, dimension and evolution, and it’s what makes proposals like ontoref stronger.
Do we know what the achievements are?
The risk is high, but so is what’s being aimed for. Do we know what those achievements are, and how to hold and validate the heading precisely, recognizably and unambiguously?
The honest answer has three parts.
What’s known. Each rung’s necessary conditions are known, and today they hold. The question no machine answers is known, because it’s written down. It’s known which rules the tool can’t answer for, because it names them.
What isn’t claimed. No rung is taken as holding, because verifying is always local and partial. Nor is there yet a way to order the rungs by the plane of each domain, and it isn’t pretended that there is.
What can already be pointed to. In all three cases there’s something written down that wasn’t there before: a tool that stopped being outside its own rules, a silence turned into a check that says what it doesn’t see, and a citation with no provenance turned into a question with a closing criterion.
A brake is triggered once. A heading is held by asking: why we started, whether what’s running is still what we declared, how much of this green has really been looked at. Those questions don’t belong to a few. ontoref doesn’t answer them for anyone: it puts them in front, in order, for whoever wants to ask them, and when it finds a gap it leaves it written down where it can be looked at again.