The front page says it in one breath. This is the whole argument — what a database actually is, what changed two years ago, why the rules have to move down into the data, and an honest look at who covers what. Read it if you want to check the reasoning, not just the claim. Back to the short version ←
Five boxes. Everything after this page is explaining one of them.
Almost nobody outside software has had this explained, and the whole argument rests on it. It takes two minutes.
A database is a set of tables, and a table is a list with fixed columns. That's it. Each column has a name and a type — text, a number, a date. Each row is one thing: one invoice, one check, one patient.
invoices| id | customer_id | amount | invoice_date | approved_by |
|---|---|---|---|---|
| 1041 | 77 | 12,500.00 | 2026-08-14 | — |
| 1042 | 77 | 3,200.00 | 2026-08-19 | dmotheral |
| 1043 | 91 | 860.00 | 2026-08-22 | — |
customers| id | name | state |
|---|---|---|
| 77 | Bar Nine Operating | TX |
| 91 | Crestline Partners | OK |
Tables point at each other with keys. The customer_id column on an invoice holds the id of a row in the customers table. That's the entire mechanism behind "this invoice belongs to that customer." Nothing more clever is happening.
The database will enforce a few things about shape. That amount has to be a number. That id has to be unique. That a customer_id must match a real customer — if you ask it to check, which you have to ask for explicitly.
And that's where it stops. The database has no opinion about what an invoice is. It doesn't know that invoice 1041 has no approval and shouldn't be paid. It doesn't know who is allowed to approve one, or that an invoice over a certain amount needs two people, or that this amount is supposed to tie to a statement that arrived last week. Those are the real rules of the business, and none of them are in the picture above. The database would cheerfully accept an invoice that breaks every one of them.
An application is the software people actually click. The screen with the invoice form on it. Between the person and the tables sits code, and that code is where the business's judgment was written down: check the amount is positive, check this user has approval rights, refuse to submit without a purchase order, send the email when it's approved, show the accountant a different screen than the field tech.
It's worth being clear that the screen is not the data. The application asks the database for rows, arranges them into something readable, and shows you that. Change a number on screen and the app decides whether to write it back — and under what conditions.
So the division has always been: the database stores, the application decides. Shapes below, meaning above.
For forty years the application was the only door to the data. If the rule was in the app, the rule was enforced, because nothing else could get in. Putting the meaning in code was faster to build and easier to change, and nothing was lost.
The moment there's a second door, the rule isn't there. A report run straight against the tables. A spreadsheet connected directly. A vendor integration. A second app built by a different team. Each one either re-implements the rule slightly differently or skips it — and the data holds still for all of them.
Everything about how software has been built for forty years rests on the left-hand column. The right-hand column is new, and it is now the fastest-growing thing touching every company's database.
None of this is a complaint about reasoning models. The unpredictability is what makes them useful — it is the same property that lets one read a statement nobody wrote a parser for. You do not want it to be a program. You want it to be exactly what it is, inside something that can tell it no.
And moving the rules down is not a new idea. It is an old database idea that stopped mattering when applications became the only client, and started mattering again the moment they stopped being.
This era doesn't make databases matter less. It makes them matter more, in the places that were allowed to get sloppy — constraints, permissions, where a number came from, who approved it. Every shortcut pushed up into application code is now a hole a model walks through. You write less application software and far more rules as data.
The hard part isn't the technology. Somebody has to write down how the company actually works — which rules, whose approval, what may never happen. That model is specific to each business, it grows every time the business runs, and no model vendor can ship it, because it isn't theirs to ship.
Everything above describes a choice we made. This section is about why we think it stops being a choice — and it doesn't rest on any prediction about how good AI gets. It rests on three things that are already true.
Every business is pointing something at its own data right now: an assistant, an agent, a copilot inside a tool they already pay for, a vendor's integration, somebody's script. That count goes up every quarter and it has never once gone down. Nobody is planning to have fewer things reach their data next year.
Write "only a manager may approve over $10,000" into an application and you've protected one door. Ten doors means writing it ten times, in ten places, by ten people, at ten different moments — and being right every time. That is not a discipline problem. It's multiplication, and multiplication always wins.
Whoever holds the money, the records, or the duty is still the one who answers for them. No regulator, client, endowment or court has ever accepted "the software did it," and none of them will accept "the model did it" either. The obligation stays exactly where it was while the number of things acting on your behalf goes up.
If the doors multiply and the duty doesn't move, the rule has to live somewhere every door must pass regardless of who built it or when. There is exactly one such place: the data itself. Written once, enforced identically, for a person, a program, or a model that didn't exist when the rule was written.
Conventionally you sign in once and carry that access for the session. That worked because a program's next action is predictable from its last one. A reasoning model's isn't — it's non-deterministic by construction, so permission granted at the start of an hour tells you nothing about what it will attempt in minute forty. The only honest place to check is the moment of the act, every time, for people and machines identically.
Every business has rules that were never enforced anywhere — the ones everybody just knows. That was survivable when only trained people and predictable programs touched the data; the knowledge lived in the staff. An actor with credentials and no knowledge of your company walks straight through every one of them, confidently, and produces a clean-looking result. Unwritten rules have quietly become unenforced ones.
The durable job stops being doing the task and becomes defining what may happen — writing the company down. What a thing is, what makes it valid, who decides, what may never occur. That's the part no vendor can do for you and no model can infer, and it's the part that keeps its value as the tools underneath keep changing. It is also, not coincidentally, the only asset in this whole picture that compounds.
None of which means everyone needs this today. If nobody audits you and nothing you hold belongs to somebody else, a spreadsheet is fine and you should keep it. This argument binds the firms who will be asked to prove something — and that set is growing for the same reason the doors are.
One thing in the middle, four steps around it, always in the same direction. Tap any part.
Not just what the business holds, but what makes each thing valid, who may act on it, what may never happen, and where every number came from — kept as data next to the facts rather than in software, a document, or somebody's head. Because they sit together, a new tool cannot decide whether to honour a rule; it cannot reach anything except through a door that carries it. Your own spreadsheet and reporting tools read from here.
Say it in one breath: an act is checked against the record before it happens, what happened lands somewhere we can't edit, reading that turns failures into new rules, and those rules go back into the record the AI is held by. Each piece exists somewhere in the industry. The circle closing is the part that doesn't.
It's the inward pull — the one that keeps an orbiting body in orbit instead of flying off. And it's the exact shape of the diagram above: something in the middle, everything held to it, with the pressure always pointing in.
The failure mode this is built against is the opposite force. Every new tool added to a business flies outward with its own copy of the rules, its own interpretation of "customer," its own quiet exception. Five doors, five versions, everything drifting away from anything that could be called the truth. A model with database credentials is the strongest outward force yet invented, because it can make new doors faster than anyone can install rules on them.
The record supplies the pull the other way. Not by slowing anything down — an orbit is fast. By making every act curve back toward the center whether it wants to or not.
And that's the part worth sitting with: centripetal force doesn't stop motion, it permits it. Without it the object doesn't orbit — it leaves. Same with a gate. One that only stops is friction. One that pulls you back to the center is what lets you go fast without flying apart.
The more doors you add, the harder it pulls in. That's the name, and it's the whole design.
Getting from a source nobody can read to a claim somebody will check is eight stages. Every kind of tool below is genuinely good at part of it, and each stops somewhere specific. Including us — our two weak stages are marked the same way as everyone else's.
It is nearly empty. Almost everything above logs an act, permits it, reminds you about it, or scores it afterwards. That is not a criticism — it is what each was built to do, at a time when the only thing touching the data was a program that did as it was told.
It is emptier still. The most capable platforms hold your data as the price of holding your decisions. That is a reasonable trade for some buyers. It is a bad one for anybody who will be asked to prove something without a vendor's help.
And read our own row honestly: we claim the most stages and two of them are amber. What we do with the record is thin outside one industry, and the verified outside copy has not had its first full run. Test stage four and stage eight first. They are the ones that matter, and they are the ones we will not be vague about.
Before anything gets built, we read the execution logs of what you already run — metadata and error streams, no customer records. Four classes turn up nearly every time, and none of them appear on any dashboard.
And their own ledger said so the whole time. Nobody was reading the ledger, because the board above it was green.
Scheduled work nobody owns, touching data nobody realises it touches.
The class an error log cannot see, because nothing errored. It just stopped.
Filed one at a time as bad luck for months, never counted as one thing, so never fixed as one thing.
The honest limit: our detector for the third class covers one pipeline today. The general version gets built on your estate, and findings are reported as system-found and ticketed — never as who dropped what.
Move the sliders. Nothing is sent anywhere and nothing is stored — this is arithmetic in your browser.
The figures above are yours, not ours — we don't see them. Any sample data shown elsewhere on this site is made up.
A rule that exists only as writing is a request. Somebody reads it, or doesn't, and when it gets skipped the output still looks correct. A rule with machinery behind it is enforced — it returns a refusal and the work stops, the same way for a person, a program, or a model that didn't exist when the rule was written.
Everything written down about your business gets built that way: a constraint, a permission, a check at the moment of the act. And the system keeps a live count of how many of its rules have machinery behind them versus how many are still only words. So "is this actually enforced?" is a question with an answer on a screen, not an assurance in a contract.
None of it runs on exotic technology. It's ordinary database software used the way it was always meant to be used. The difference is entirely in what has been turned into a refusal.
We're a small operation and you'd be early. What you'd be buying is the thing that makes the eventual answer trustworthy — from people who built the meter that would catch them.
A system that can be trusted to tell you when it's wrong is worth more than one that's confidently right most of the time.