Admissibility Engineering: Why Your AI Doesn't Actually Know Anything

Your AI sounds confident. It's wrong. And you can't tell the difference. Here's the discipline that fixes that — not with guardrails, but by making the AI prove it.

The Susan Problem

Susan processes invoices every Tuesday. She works in accounting. She's been doing this for six years. She emails Jim in procurement every week about PO mismatches. She hates when people don't fill in the cost center field. She takes a chocolate break at 4pm on Wednesdays.

Your AI system doesn't know any of this.

It doesn't know what an invoice IS — not in the way that matters. It can generate text about invoices. It can sound like it understands. But if you ask it to automate Susan's workflow, it will hallucinate a process that looks plausible but has never existed. It will say "the invoice is sent to the approver" when actually Susan routes it to Jim first because of the PO check. It will skip the cost center validation because it doesn't know that's the thing Susan cares about most.

The AI doesn't know. It performs knowing.

What Everyone Gets Wrong

The industry thinks this is a context problem. Give the AI more context. RAG. Vector databases. Stuff the prompt with Susan's procedures manual.

It's not a context problem.

You can inject 50 pages of SOPs into the context window. The AI will read them. And then it will still say something that contradicts page 23 because reading is not the same as understanding compositionally.

RAG gives the AI words about Susan. It does not give the AI a validated model of Susan's world that it cannot contradict.

That is the difference.

What Admissibility Engineering Actually Is

Admissibility engineering is the discipline of making AI reason correctly — not just fluently.

The core idea: every claim the AI makes must be admissible — it must chain back to validated observations through a composition of parts that each individually check out.

Not "the AI said it." Not "it sounds right." Not "it's in the context window." The claim must be provably composed of validated parts.

If Susan is an accountant, and an accountant processes invoices, and invoices require PO validation, and PO validation goes through Jim — then the AI can say "Susan's invoices go through Jim for PO validation." That claim is admissible because every piece of its composition is validated.

But if the AI says "Susan's invoices go directly to the CFO for approval" — that claim is inadmissible. Not because it sounds wrong. Because the composition doesn't close. There is no validated path from Susan's invoices to the CFO. The system catches it. Immediately.

Not a Database. Not RAG. Compositional Validation.

We are not building a database about Susan. We are not building a knowledge graph that stores facts. We are not doing RAG.

We are constraining the way the AI can talk about Susan.

When the AI says something about Susan's work, the system checks: does this claim decompose into parts that are each individually validated? Does each part actually instantiate the universal it claims to be? Does the composition hold at every depth?

If yes: the claim is admissible. The AI can proceed.

If no: the system tells the AI exactly where the composition breaks. "You said X, but X requires Y, and Y has never been observed. Observe Y first."

The AI doesn't get to be wrong about Susan. Not because we wrote guardrails. Because the structure of validated observations literally prevents the wrong composition from being admitted.

How It Gets Built: Towering

You don't start with a complete model of Susan's world. You start with nothing.

Day one: "Susan processes invoices on Tuesday."

The system says: "What's an invoice? What's a Susan? What does 'processes' mean here?"

Those are real questions. The system genuinely doesn't know. Every undefined reference makes the observation SOUP — an unvalidated claim that can't be composed into anything useful yet.

So you observe more. Over days. Over weeks. Susan processes invoices. Invoices have PO numbers. PO numbers come from procurement. Jim is in procurement. Susan emails Jim when POs don't match. Cost center fields must be filled.

Each observation is a layer. Each layer must be verified before the next one can be trusted. This is Towering — the discipline of building complexity where each layer provides verifiable completion signals before the next layer is constructed.

After a month of observations from Susan and her team, the system doesn't just have facts about Susan. It has a validated compositional model that the AI must respect. Susan is an accountant who does X, Y, Z with these specific dependencies, in this specific order, with these specific people, and anything the AI says about Susan's workflow must decompose into this verified structure or it gets caught.

The Moment It Becomes Useful

When the validated model reaches critical mass — all parts typed, all dependencies mapped, all roles clear — the system can compile it into automation.

Not "generate a Zapier workflow." Not "write a script that probably works." Compile a validated process into running code that is provably correct because every part of its composition has been individually verified.

The AI can automate Susan's invoice process not because it was told how. Because it KNOWS how — in the admissibility sense. Every step chains. Every dependency resolves. Every role is clear. The automation is the proof that the model is correct.

This is Crowning — the moment the system stops being something you maintain and starts being something that maintains you.

Why Nobody Else Does This

Because it's not prompt engineering. It's not a wrapper around ChatGPT. It's not a SaaS that adds a "check my work" button.

It requires:

• A formal ontology that knows what types of things exist and what they require
• A validation engine that checks every claim against that ontology — recursively, at every depth
• A progressive typing system that moves observations from unverified strings to validated compositions
• A mereological checker that doesn't just check "does this property exist?" but "does this property's value actually instantiate the universal it claims to be, in the context of this specific composition?"
• A system that tells the AI exactly what's wrong and exactly how to fix it — not "error 500" but "you said X is a Y, but Y requires Z, and Z has never been observed"

We call this system SOMA. It's the first system that does all of this. There is no competitor because this discipline didn't exist until we named it and built the infrastructure.

What This Means for You

If you're building AI systems that need to be RIGHT — not just fluent — you need admissibility engineering.

If you're running a business where AI mistakes cost real money — wrong processes automated, wrong data acted on, wrong claims presented to customers — you need formal compositional validation.

If you're tired of AI that sounds smart but can't prove anything it says — welcome. We built this for you.

The AI doesn't get to perform knowing anymore. It has to actually know. And when it doesn't know, the system tells it exactly what to learn next.

That's admissibility engineering.