Give the same problem to ten capable people working independently, and a striking number of them will arrive at recognisably the same idea within weeks of each other. This is not a coincidence and it is not plagiarism. It is what happens when smart people read the same papers, hit the same constraints, and reason from the same starting point. Call it the well: the shared body of prior knowledge, technique and observation that every capable mind in a field is drinking from.

If an idea is reachable by reasoning from public information, it is, by definition, reachable by more than one person. We tested this claim on ourselves directly: a dozen ideas we were genuinely excited about, each one independently checked by an outside adversary whose only job was to try to kill it. Every single one had already occurred to someone else, usually years earlier, usually documented somewhere the idea’s own builder had never read. The ideas were good. They were also, almost without exception, not new.

None of this makes the ideas worthless. It means the idea itself was never where the value was going to live. What survives contact with an adversarial check is not “did I think of it,” but what is not in the well: a position nobody else occupies, a dataset nobody else can generate, a proof only your specific method can produce, an engineering depth that took years to accumulate and cannot be reasoned into existence over a weekend.

This has a direct, practical consequence for how we evaluate our own work. Excitement about an idea is not evidence that it is defensible, so we don’t treat it as evidence. Every candidate direction goes through the same outside check the field report on this site describes, and the ones that survive are, by construction, the ones where the value was never the idea in the first place. Novelty doesn’t live in the water everyone is drinking from. It lives at the edges nobody else is standing on, which is a much smaller, much more useful place to go looking.

The practice

Every builder is structurally the worst possible judge of their own idea’s novelty. This is not a character flaw, it is a selection effect: an idea survives long enough to reach a founder’s attention specifically because that founder found it exciting, and excitement is not evidence of originality, only of unfamiliarity to the one person in the room least likely to have already seen it somewhere else. So we don’t ask the builder to grade the builder’s own work. We ask someone whose only incentive is to kill it.

Why builders fail this test by default

The failure mode is not stupidity, it is structure. Building something requires sustained belief in it, and sustained belief is hard to maintain while simultaneously searching, in earnest, for the specific fact that would prove the belief wrong. Nobody sets out to skip the search. It happens because a team that has spent months building genuinely stops seeing the version of the search that would hurt, and starts, without noticing, running the version that confirms what they already believe. An external reviewer with zero investment in the outcome doesn’t have that problem. They have no months of work to protect.

What we did

We took twelve ideas, drawn from a dozen different domains, each one something a team inside the lab was genuinely excited to build, and put every one of them in front of an independent adversarial reviewer with a single instruction: find the reason this already exists, or the reason it won’t work, and do not stop looking until you either find it or run out of places to look.

How the review actually works

The reviewer receives only the idea and its stated justification, deliberately withheld from the internal reasoning that produced it, so the review starts from the same position a competent outsider encountering the idea cold would start from. Their mandate has exactly one success condition: find the disqualifying fact, or exhaust the search. An idea that survives is marked SURVIVE. One with a real but non-fatal prior-art overlap is marked SKETCH, worth revisiting once the overlap is understood, not worth resourcing as-is. One that already exists, or fails for a concrete reason, is marked KILL.

What happened

Every one of the twelve had already cleared its own internal gate. The teams building them were confident, for good reason: the ideas were coherent, and nothing about the review process up to that point had surfaced a disqualifying problem.

The outside check killed or sketched all twelve. Not most. All. And it did so, almost without exception, on prior art the builder had no way of seeing from inside the process that produced the idea. In several cases the disqualifying prior art wasn’t obscure: it was published, sometimes years earlier, sometimes by a well known lab, using different vocabulary for the same underlying mechanism. In a smaller number of cases the idea hadn’t been published anywhere, but the reviewer identified a specific, near-term reason it would fail once it left the whiteboard, the kind of failure visible only to someone actively trying to find one.

The lesson

Enthusiasm is not evidence, and internal confidence measures the wrong thing: it measures how thoroughly a team has convinced itself, not how thoroughly the world has already covered the same ground. A thing is novel only when someone whose entire job is to want it to fail, tries, and can’t. That is a much higher bar than “our team likes this,” and it is the only bar that actually correlates with the thing being worth building.

What changed

This is no longer a one-off exercise; it is a standing gate. Every candidate direction inside the lab now goes through the same adversarial check before it receives real resourcing, on the same terms: an outside reviewer, motivated only to kill it, given as long as it takes. Most of what gets proposed does not survive. What does survive has already been tested against exactly the kind of scrutiny it will eventually face from the outside world anyway, just earlier, and cheaper, than finding out after the fact.

This is the same claim the fragment on this site makes about the well: capable minds converge, so the idea was rarely going to be the moat. This report is that claim, tested on ourselves, with a number attached. Twelve for twelve.

Every guard in the agentic-security market ships the same shape of product: watch an AI agent’s behaviour, and raise a probabilistic flag when something looks wrong. It is a genuinely useful shape of product. It is also, structurally, an alarm, not a proof, and the difference matters more than it sounds like it should.

What an alarm actually promises

An alarm tells you that, based on a model of normal behaviour, a particular action looked unusual enough to flag. It does not tell you the action was impossible. It tells you it was improbable. That distinction is invisible on a good day and catastrophic on a bad one: an alarm-based system is only as good as the behaviours it happened to have seen before, and an agent under prompt injection, or one simply operating at the edge of a case nobody anticipated, does not have to look unusual to do real damage. It only has to be unmonitored for the one action that matters.

What KERN does instead

KERN starts from a different question: not “does this look wrong,” but “can this happen at all, given exactly what this agent mesh is allowed to touch.” It compiles the mesh’s declared tools, its data labels, and its authority boundaries into a finite, bounded system, small enough that “for every possible input” becomes a question with a computable answer rather than a hope. A monotone fixpoint computation then settles the actual question: can a protected label ever reach a forbidden sink, under any sequence of actions the mesh is capable of taking. The output is not a confidence score. It is either a proof that the boundary holds, or a concrete counterexample: the exact path an attacker could take, shown, not asserted.

That proof becomes a portable certificate, and this is the part that actually changes who can trust it. A confidence score is only as credible as the vendor issuing it; you either believe them or you don’t. A certificate is different: an outsider, an auditor, an insurer, a counterparty agent that had no part in building the mesh, can re-run the proof themselves, in an air-gapped room if they want to, and get the same answer, because the answer never depended on trusting KERN in the first place. It depended on trusting the math, which anyone can check.

What this looks like when it is tested

Run a live prompt-injection exfiltration attempt against a mesh KERN has certified, and the attempt is caught at the boundary before it happens, not flagged after the fact, with the specific unauthorised route shown as the reason it was blocked. Try to present a forged certificate, and it is rejected outright, because a forged certificate does not re-derive to the same proof a real one does. Neither outcome depends on the attempt looking suspicious. It depends on the attempt being, or not being, actually possible under the mesh’s declared boundaries.

Proof extends to arithmetic, not just routing

For agents that move money, “the data didn’t leak” is necessary but not sufficient. KERN’s value predicates prove the arithmetic too: that a keeper agent can never withdraw more than a position actually holds, for every input, not just the ones a test suite happened to cover. That is the same kind of guarantee auditors already expect from formal verification in other domains, discharged here as a proof rather than a fuzzing campaign that merely failed, so far, to find a counterexample.

Why this is the harder path, on purpose

Proof is a smaller claim than it sounds like at first. KERN’s guarantee holds over the mesh as declared: the tools, labels and boundaries it was actually given, not code it never saw and not a mesh operating outside its stated bounds. That is a real limitation, and we say so rather than paper over it, because a proof that quietly overclaims is worse than an alarm that honestly doesn’t know: at least the alarm isn’t lying about what it covers. Multi-step running invariants and live on-chain label capture are on the roadmap precisely because they are not solved yet.

Who this is actually for

An alarm is enough if the person reading it built the system and trusts their own judgment about what “looks wrong” means. A proof is what you need the moment someone else has to trust an agent they didn’t build: an insurer pricing the risk of a mesh they’ll never audit line by line, an auditor who has to sign off on a system engineered by a team they don’t work with, a counterparty agent that has to decide, automatically, whether to transact with a system it has never met. A certificate that re-runs in their hands, not ours, is the only shape of answer that actually works for them.

Imagine an autonomous procurement agent authorises a two million pound payment. Six months later, the transaction is investigated. The prompt has changed. The model has changed. The APIs it called have changed. The system prompt in effect at the moment of the decision may no longer exist anywhere, in any form.

Traditional logs tell you what happened. They rarely prove why it happened, and the gap between those two claims is exactly what matters once an AI system is making decisions with real consequences attached.

The problem

Most AI accountability today is retrospective. When something needs explaining, we reconstruct events after the fact, from logs, from version history, from whatever happened to still be running. That reconstruction is expensive, frequently incomplete, and sometimes flatly impossible: the evidence a real investigation needs tends to disappear faster than the consequences that make the investigation necessary in the first place.

Our observation

ACTA starts from a different assumption: the important artifact was never the model. It is the decision. Models get retrained, fine-tuned and replaced on a timescale of weeks. The decision a system made, at a specific moment, using specific inputs and a specific policy, is a fixed historical fact the instant it happens, whether or not anyone thought to record it properly.

Our approach

Every execution produces a signed attestation describing:

• the identity involved
• the authority exercised
• the evidence used
• the policy evaluated
• the outcome produced
• the cryptographic signature proving the record has not been altered since it was written

That record becomes immutable the moment it is created. Accountability is generated during execution, not reconstructed afterwards from whatever logs happened to survive.

Why it matters

The future of AI governance is unlikely to turn on anyone’s ability to fully explain a trillion-parameter model’s internal reasoning. It will turn on something narrower and more tractable: proving what happened, who or what authorised it, under which policy, and whether the record of any of that has since been altered. That is a fundamentally different problem from model interpretability, and it deserves infrastructure built specifically for it, rather than logging bolted onto a system after the fact.

Status: Research note

Double-entry bookkeeping has been running the world’s accounting for roughly seven hundred years, and almost nobody who benefits from it has ever seen it directly. The TCP handshake happens three times before this sentence reaches you, and it has never once been the subject of a product launch. A ledger sits underneath every bank, ignored for decades, until the one week it is the only thing anyone in the building is looking at. The pattern repeats everywhere: the systems that actually move the world are rarely the ones on the screen. They are the layer underneath it.

The problem with visible software

Visible software gets funded, demoed and reviewed, because it is the thing a person can point at. Invisible infrastructure gets built once, works quietly for years, and gets noticed only at the moment it breaks, at which point the cost of not having built it properly the first time comes due all at once. This creates a predictable bias: organisations overinvest in the interface a person clicks and underinvest in the substrate that interface actually depends on, because the substrate never demos well and never shows up in a screenshot.

Where we’ve made the same bet five times

Every engine we’ve built takes the same side of that bet, and looking at all five together makes the pattern legible in a way that looking at any one of them alone does not.

KERN never appears in an agent’s own interface. It sits beneath the agent mesh, compiling declared tools and data boundaries into a finite system and proving, for every input, what the mesh can and cannot reach. The agent’s user never sees KERN operate. They only see that the agent could not do the thing it was never authorised to do.

AWATUM’s actual object is a graph: facts, rights, obligations, deadlines and authority, evolving underneath whatever plain-language question a person happens to be asking it today. The person interacting with AWATUM sees an answer. The thing doing the actual work, the legal-state graph binding that answer to primary law, is never on screen at all.

VERITY doesn’t read a paper the way a person does. It reads the manuscript’s statistics, its images, its citation graph and its methodology as a structured object, checking each against primary evidence, and hands back a signal only once that invisible pass is complete. The reviewer sees a flagged figure. They don’t see the seven axes of verification that ran underneath it.

ANNEAL runs continuously against an estate nobody is actively watching at any given moment, modelling reachable attack paths in the background between the rare moments a human looks at a dashboard. Its entire value is produced in the interval when nobody is looking, which is exactly the interval visible software has nothing to say about.

CODEC goes furthest in the same direction: it treats the genome, arguably the most invisible infrastructure that exists, not as a sequence to browse but as a running dynamical system, and computes the stable states that system settles into. The phenotype is what you can see. The regulatory dynamics producing it are the actual object of study, and they were never visible to begin with.

Why this is a deliberate bet, not a coincidence

Invisible infrastructure is where the real risk and the real value both concentrate, precisely because it is the layer nobody is checking in real time. A visible interface failing is an inconvenience. An invisible substrate failing silently, for months, before anyone notices, is how bookkeeping fraud, security breaches and scientific retractions actually happen: not because the visible surface lied, but because nothing was watching the layer underneath it.

What this means in practice

Building for the indirect layer means accepting that the work is often unglamorous by design. It rarely produces something you can screenshot. What it produces instead is the thing that keeps working after the interface built on top of it has been redesigned three times: a containment proof that holds regardless of which agent framework calls it, a legal graph that stays correct as the underlying statute changes, a verification pass that runs the same way on every manuscript regardless of who submitted it. The visible software will change. The substrate, if it is built properly the first time, is what everything else gets to assume.

Why it matters to whoever is reading this

If you are evaluating whether to fund, buy from, or join a lab building AI-era infrastructure, the useful question is rarely “what does the demo do.” It is “what is the invisible layer underneath the demo, and has anyone actually proven it holds.” That is the layer we have chosen to build in five separate domains, on purpose, because it is the layer that decides whether the visible thing on top of it can still be trusted six months after the pitch.

For thirty years, the person at the keyboard was the one who acted. Software waited for a click, a keystroke, a confirmed intent, then executed exactly what was asked. The entire discipline of interface design grew up around that fact: reduce friction, clarify affordances, make the right action obvious, because a human being was going to press the button and live with what happened next.

That chain is changing shape. The person at the keyboard is becoming the person who delegates. They describe an outcome, hand it to an agent, and the agent decides which tools to call, which data to touch, and in what order, often without a human reviewing any individual step. The click is still there. It now authorises a chain of decisions rather than a single one.

This changes the actual design question. “Is it usable” assumes the human is the one doing the acting, and asks whether they can do it correctly. It is a question about interface. “Is it containable” assumes the agent is the one doing the acting, and asks whether it can do something the human never intended, given the tools and data it has been handed. It is a question about the boundary of the system, not the clarity of its buttons.

Usability failures are recoverable: a confusing screen wastes a few minutes and gets fixed in the next release. Containment failures are not the same shape of problem. An agent that can route protected data to an undeclared sink, or exceed its authority under some input nobody tested, does not fail gracefully. It fails once, silently, and the cost lands wherever the data or the authority ended up.

This is the problem KERN is built to answer directly: not by watching an agent’s behaviour and raising an alarm when something looks wrong, but by compiling its declared tools, data labels and authority boundaries into a bounded system and proving, for every input, what it can and cannot reach. Usable is still worth having. Containable is now the precondition for shipping anything that acts on your behalf.