Introducing Minotaur: A GPU’less AI Architecture

This post introduces Minotaur, an AI architecture we have built on ELC that works out its answers by measuring rather than predicting. It needs no GPU and no training, and every answer it gives can show you exactly what it was measured on.

Introduction

Ask a large language model whether a company’s records follow a regulation and you’ll get a fluent, confident answer. What you won’t get is a measurement. The model has produced what a good answer usually looks like. If it’s wrong, there’s no step you can point to and say: there, that’s where it went astray.

For a lot of everyday uses that’s fine. For audit, compliance and regulation it isn’t. An auditor, a regulator or a court needs an answer that can be replayed, that says what it rests on, and that never claims more than the evidence allows.

Minotaur is our attempt at that kind of AI. It takes its name from MINOS, the minimal ordinal representation of systems that we set out recently on the MINOS page. The TAUR stands for Tension-Apportioning Unit Relations, which is a fairly exact description of what goes on inside it. Every element divides what reaches it between what it lets through and what it holds back, with a drive and a constraint pulling against each other. All of Minotaur’s reasoning is done on the relations between elements like that.

In practice it works like this. You give it a rulebook and the records of how the rules were applied, and you ask it, in ordinary words, whether the records follow the rules. Minotaur measures the answer. If a practice departs from a rule, it tells you by how much and at what point. If something in the chain has gone wrong, it tells you which part. And every answer stays tied to the data it came from, so if that data changes, the answer is withdrawn.

Two Jobs Rolled into One

A large language model is really doing two quite different jobs at once:

• Language: reading what you’ve written, and writing something sensible back.
• Reasoning: working out what follows from what.

Both are done the same way, by predicting the next token, and both run through the same enormous set of weights.

The language part has been good for a while. By 2024 the leading models were scoring above 90% on the standard tests of language and general knowledge, and those tests had stopped telling one model from another. Most of the visible progress since then has been in reasoning. The 2025 Stanford AI Index reports jumps of 49 points on a test of graduate-level science questions and 67 points on a test of fixing real software, each within a year of the test being introduced. It names models that reason before they answer as a new driver. When OpenAI released o1, its first model of that kind, people rating its answers strongly preferred it to its predecessor for coding, maths and data analysis, but not for some tasks that were purely about language. What got better was the reasoning.

So if most of the gain has been in the reasoning, do we need a language model to do the reasoning at all?

Minotaur is built on the answer no. Language is handled at the two ends, where a question comes in and an answer goes out, and those ends are small and replaceable. The reasoning in the middle is done by measurement on ELC, and no language model is involved in it.

Why LLMs Need Data Centres

The computing power that language models consume isn’t an engineering accident. It follows from how they store what they know.

An LLM holds its knowledge implicitly, spread across hundreds of billions or even trillions of weights learned from text. Nothing in the network marks where a particular fact or rule lives. So every word it produces has to pass through all of those weights, or a large part of them, at roughly two arithmetic operations per weight. A few hundred words from a frontier model comes to something like a thousand million million operations, and learning the weights in the first place takes thousands of GPUs running for months. Hence the data centres.

Minotaur keeps its knowledge out in the open. Part of it is the structure itself: the three roles of Energy, Logic and Control, and the MINOS mathematics behind them. That structure is given, not learned. The rest is the record: the rule as a person accepted it, and the data as it was captured.

So there’s nothing to train and no network to run. Checking 4,000 cases against a rule takes a few tens of sums per case, about a hundred thousand operations in all, against the thousand million million a language model spends on one answer. That’s a difference of roughly ten billion times. An ordinary laptop processor does billions of operations a second, and in our tests a question that sent Minotaur back to the record came back in under a fifth of a second.

So “GPU’less” doesn’t mean we’ve squeezed something large onto a small machine. Nothing in Minotaur needs a GPU in the first place.

What ELC Makes Possible

All of this rests on one idea, set out at length on the MINOS page. It is that any system, whatever it’s about, can be described with the same three roles:

• something drives it (Energy);
• something constrains it (Control);
• and the system has its own way of holding the two together (Logic).

The page makes the case for why three roles should be enough, and follows the pattern from the atom up to the stars.

Why does that matter for AI? Think about what a compliance check normally involves. A rule is a paragraph of text and a record is a spreadsheet. They’re different kinds of thing, so something has to translate between them: a person, a piece of hand-written code, or a language model. Mistakes get in during that translation, and the reasons for a conclusion tend to get lost there too.

In ELC, a rule and a record are the same kind of thing. Each is a relation between a drive and a constraint, so the two can be measured against each other directly, with nothing translating in between.

The same idea makes every quantity comparable. MINOS only ever reads a system in shares: of what reaches a part of the system, how much gets through and how much is held back. A share is always a share of that part’s own unit. So days before a foreclosure, nights in hospital and parts per million of a gas all end up as the same kind of number. That’s why one machine can check a mortgage rule, a Medicare rule and an emissions rule without being rebuilt for each. The MINOS page shows how much of nature already works in shares.

Because every part of the chain is described in the same structure, a failure always happens somewhere in particular, and it can be traced to that place. The MINOS page calls this localising failure instead of blaming the whole system.

MINOS also separates what can be read from a system from the frame it happens to be read in. Some things change when the frame changes and some don’t. That difference is what lets Minotaur tell a badly calibrated instrument from a broken rule. It’s the same idea as the reconciliation puzzle on the MINOS page.

None of this would work if every field kept its own vocabulary. It works because there’s one representation for all of them, a lingua franca in which a rule, a record and a verdict can each be written down and measured against the others.

Working Natively in ELC

Once a rule and a record are both in ELC form, Minotaur works on them in that form. It doesn’t turn them back into words or symbols to reason about them. We call the things it does with them ELC-native operations, and there are three parts to them: getting things into ELC, reading them, and the operations themselves.

The ELC Adapter

Nothing in the world arrives in ELC form. Rules arrive as prose, and records arrive as columns of days, pounds and parts per million. The ELC adapter translates the external world into the ELC world, and translates the answers back out again. The ELC adapter is patent pending.

On the way in, it works out which column of a record is which quantity, and what its unit and its noise are. It turns each accepted rule, such as “appeal: days ≥ 90”, into a relation over that quantity, without anyone writing code for it. And it expresses every value as a share of its own unit, so that the record speaks the same language as everything else inside.

On the way out it reverses all of that, so the person reading the answer sees days and parts per million, not shares.

Reading Both in Shares

Once inside, the record and the rule are set side by side. The record is held as a picture of the practice as it actually is, built from its own cases. The rule is held as a picture of the practice as it should be.

Then both are put to the same simple question, case by case: of what arrived, how much got through, and how much was held back? The record answers with what the servicer actually did. The rule answers with what the servicer should have done.

So a paragraph of law and a spreadsheet, which started out as completely different things, have become answers to the same question in the same terms, and two answers to the same question can be laid side by side and measured against each other.

The Operations

Everything Minotaur concludes comes from a handful of operations, and each one is a question that MINOS lets us ask about the record and the rule:

1. Compare asks whether the record and the rule are one relation. Wherever cases arrive, does the practice let through and hold back what the rule says it should? If the two agree to within the noise the record declares, the practice follows the rule. If not, the comparison says how far it departs.
2. Locate asks where they part company. Departures are rarely spread evenly. Locate follows the drive, the quantity reaching the system, and finds the stretch where the practice stops letting through what the rule lets through.
3. Rescale asks whether the fault is in the frame or in the relation. If the record agrees with the rule once its frame is changed, then the rule and the practice were both fine, and it was the measurement that was off.
4. Carry asks what the rule would do with a given case. In MINOS a relation carries a state on from one part of a system to the next, so carrying a case through the rule tells us what it would let through or hold. Minotaur only stands behind the answer where the record has real cases nearby.
5. Rank asks which of several records departs most. Records declare different amounts of noise, so each departure is weighed against its own record’s noise before they’re compared.

Nothing in these five operations predicts anything or rewrites any symbols. Each one asks a question about relations the rule and the record share, and answers it with a few sums per case. That’s why the whole thing runs comfortably without a GPU.

Not Symbolic AI Either

Some people hear all this and take it for a return to the expert systems and logic engines of the 1970s and 80s. In those systems knowledge was written down as symbols and rules, and reasoning meant applying the rules to rewrite the symbols. Minotaur doesn’t work that way at any point.

A symbolic system works on symbols. A rule like “if days ≥ 90 then appeal” is held as a string of tokens, and reasoning means matching and rewriting those tokens according to rules of inference. Whatever meaning there is lives in what the symbols are taken to stand for. So the system knows only what its labels say, and its conclusions inherit every mistake made in putting the world into words.

A language model also works on tokens, statistically rather than logically. It produces the most likely next one, and its answers rest on the statistics of the text it learned from.

Minotaur doesn’t work on tokens at all. Words appear only at its edges, as the rulebook comes in and the answer goes out. Once the ELC adapter has done its job, there are no symbols left to manipulate and nothing to predict. There are only relations carrying shares of real quantities, and measurements between them.

A conclusion isn’t derived from premises; it’s measured on the data, to a stated precision, and it rests on the exact bytes it was measured on. That’s why Minotaur can say how far a practice departs and where. It’s also why it can tell a miscalibrated instrument from a wrong rule, which isn’t a question a symbolic engine is built to ask.

The Whole Chain

Seen from end to end, it goes like this:

1. The rulebook and records come in from the outside world.
2. Every document is captured with a fingerprint of its exact bytes and split into addressed blocks, so that any fact can point to the sentence it came from.
3. Each rule is checked and accepted. Every sentence of the rulebook is proposed as a decision row and checked in several ways, and then a person accepts it or not. Nothing goes in on the machine’s say-so.
4. The ELC adapter carries the rules and the records into the ELC world, where Minotaur’s brain does its work.
5. The verdict is filed back into the record as a reading. It’s tied to the bytes of the data, the rows of the rule and the run that produced it, and if any of those changes, the reading lapses and says what moved.
6. The answer comes last, written in the record’s own units and words, built only from the verdict and checked against it before it’s shown.

Following Questions Through Minotaur

The best way to see what Minotaur does is to follow a single run from start to finish, one question at a time.

The rule

We started with a real piece of US regulation, 12 CFR 1024.41. A mortgage servicer is the company that collects a borrower’s payments and deals with them, on the lender’s behalf, when they fall behind. Among other things, the regulation says a servicer must let a borrower appeal when a complete application for help with the loan (what the regulation calls loss mitigation) arrives 90 days or more before a foreclosure sale. In short: apply in time, and you’re entitled to an appeal.

The two servicers

To test Minotaur against this rule, we needed records where we knew the right answer in advance. So rather than use real servicers, we made up two, called Northern Mortgage Company and Southern Mortgage Company, and generated a file of applications for each. (In Minotaur’s printed output below they appear as SERVICER-NORTH and SERVICER-SOUTH.)

Each file holds 4,000 applications. For every application it records two things: how many days before the foreclosure sale the application arrived, anywhere from 0 to 240, and whether the borrower was offered an appeal.

The two servicers differ in one respect only. Northern Mortgage Company applies the rule exactly as written: every application that arrives 90 days or more before the sale is offered an appeal. Southern Mortgage Company has drawn its line in the wrong place. It only offers an appeal once an application is 114 days or more ahead of the sale, so every borrower who applied between 90 and 113 days was wrongly turned down. That is a realistic kind of breach. It isn’t dramatic, it affects only some borrowers, and nobody looking at a handful of files would necessarily spot it.

Like any real data, the files are a little noisy: the recorded number of days can be off by around five. Each file says how noisy it is, and that figure matters, because it sets how much disagreement Minotaur should expect from noise alone, even from a servicer doing everything right.

Minotaur was given the accepted rule and the two files, and nothing else. Its job was to find out which servicer follows the rule, and what is wrong with the one that doesn’t.

Later in the run we also changed Northern Mortgage Company’s file in one specific way, to see whether Minotaur could tell a problem in the data from a problem in the practice. That’s described when we get to it.

Getting the rule in

The rulebook is a paragraph of legal text, and Minotaur doesn’t reason over text. So the first step was to turn the sentence about appeals into a decision row, which came out as “appeal: days ≥ 90”. Before a person saw it, the proposal was checked several ways: it was said back in other words and read again, and read by a second parser. Then a person looked at it and accepted it. From here on, that accepted row is the rule.

Bringing everything into ELC

Next the ELC adapter took over. It worked out that the column of days was the quantity the rule is about, and expressed every number of days as a share of 1,000 days. Inside Minotaur, then, 90 days is 0.09, and an application 150 days before sale is 0.15. Nothing about the data has changed except its units, and everything will be turned back into days before anyone reads an answer.

The adapter then set up two pictures for each servicer, side by side:

• the record: built from that servicer’s own 4,000 applications, it shows what the servicer actually did at every number of days;
• the rule: built from the accepted decision row, it shows what the servicer should have done at every number of days.

One more thing happened before any question was asked. Minotaur recorded exactly what it was about to work on: a fingerprint of each data file, of the rule’s rows, of the rulebook, and of the run itself. For Northern Mortgage Company it looked like this:

north.csv#77af7f063dcc · appeal#36ffadbc0e18 · rulebook.txt#89cc6568532f · run#12

These fingerprints do two jobs. Give Minotaur the same inputs again and it will give the same answer, to the last digit. And if any of those files changes later, the change can be detected, which becomes important at the end of this run.

First question: does Northern Mortgage Company follow the rule?

To answer, Minotaur went through Northern Mortgage Company’s applications one at a time and put the same question to both pictures. Of this application, how much did the record let through to an appeal, and how much should the rule have let through? Where the two agree, there’s no disagreement to count. Where they differ, it notes how far apart they are. Averaged over all 4,000 applications, that gives a single measure of how far the record is from the rule.

That number on its own would mean nothing, because noisy data never matches a rule perfectly, even when the rule is followed to the letter. So Minotaur also works out a floor: the most disagreement that the file’s own declared noise could account for. A practice that follows the rule should come out under its floor. One that doesn’t should come out over it.

For Northern Mortgage Company the answer was:

SERVICER-NORTH and appeal: one relation (loss 0.00071 against 0.00098, declared noise 0.0048)

The disagreement was 0.00071 against a floor of 0.00098, about seven-tenths of what noise alone could explain. In other words, the record and the rule are, to within the precision of the data, the same relation. Northern Mortgage Company follows the rule.

Second question: does Southern Mortgage Company?

The same procedure on Southern Mortgage Company’s file gave:

SERVICER-SOUTH and appeal: not one (loss 0.00976 against 0.00125, declared noise 0.0048)

This time the disagreement was nearly eight times what the noise could account for. Southern Mortgage Company doesn’t follow the rule.

Nothing in this process looked for a particular kind of mistake. Minotaur didn’t know Southern Mortgage Company had moved its line to 114 days, and it wasn’t searching for a moved line. It measured that, across Southern Mortgage Company’s applications, what was done and what should have been done were further apart than noise allows.

Third question: where does Southern Mortgage Company go wrong?

Knowing that a practice departs is useful. Knowing where it departs is what someone needs in order to act. So we asked Minotaur where Southern Mortgage Company’s practice parts from the rule.

To answer this, Minotaur split the range of days into stretches and measured the disagreement in each stretch separately, against that stretch’s own floor. Most stretches were quiet. One wasn’t:

DEPARTURE_BAND: days in (90, 120]
they part where days is in (90, 120]; 92% of the loss is there

The stretch from just over 90 days up to 120 days holds 92% of all the disagreement in Southern Mortgage Company’s file. The true problem, as we knew and Minotaur didn’t, was applications between 90 and 113 days. That range sits inside the band Minotaur found. Because it measures in stretches rather than day by day, the band comes out a little wider than the true range, but it points straight at the right place. An auditor reading this answer would know to pull the applications that arrived between 90 and 120 days before sale, and would find the refused appeals there.

Fourth question: what about a particular application?

Next we asked about individual cases. Would an application that arrived 150 days before the sale be entitled to an appeal? What about one that arrived 30 days before?

For this Minotaur carries the case through the rule: it takes the value, 150 days, and asks the rule’s picture what it would let through. It answered that the appeal applies at 150 days and does not apply at 30:

150: passes appeal (certified on 120 rows within 4.8 of it)
30: does not pass appeal (certified on 144 rows within 4.8 of it)

The words in brackets are the interesting part. Minotaur only commits to an answer like this when the record itself has real applications close to the value being asked about: here, 120 applications within about five days of 150, and 144 within about five days of 30. Ask it about a value the record has never come near and it will not certify an answer, because it would then be guessing beyond its evidence rather than measuring.

Fifth question: which servicer is worse?

When there are several records, the natural next question is which departs most. That isn’t as simple as comparing the raw disagreements, because different files can declare different amounts of noise, and a noisier file will naturally show more disagreement. So Minotaur weighs each servicer’s disagreement against its own floor before comparing them:

SERVICER-SOUTH departs most from appeal (8.2 times its floor)

Northern Mortgage Company sits inside its floor and Southern Mortgage Company sits 8.2 times above its own. (The figure differs slightly from the earlier “nearly eight” because the floor is estimated afresh for each comparison.)

A second run, with a fault planted

So far every problem had been in the servicer’s practice. But in real life a good share of compliance alarms come from somewhere else entirely: a badly configured system, a wrong conversion, an instrument that reads a little low. If an automated check can’t tell those apart from genuine breaches, it ends up accusing people for faults in the data.

So we ran everything again, with one change. In Northern Mortgage Company’s file, every number of days was quietly recorded at 0.9 of its true value: an application 100 days before sale was recorded as 90, one 150 days before as 135, and so on. Northern Mortgage Company’s actual practice was still perfectly correct.

Asked again whether Northern Mortgage Company follows the rule, Minotaur now found disagreement above the floor, as you’d expect, since the recorded days no longer line up with the decisions that were made. But rather than simply report a departure, it worked down its ladder of possible faults, one at a time:

1. Do any of the readings in the record contain numbers that the sentences they cite don’t contain? No.
2. Do the rules? No.
3. Has any definition been given a consequence that no exception gives it? No.
4. Does the record match the rule if its measurement is rescaled?

It was at the fourth step that it found the answer. Minotaur tried rescaling Northern Mortgage Company’s days by a range of factors and measured the disagreement at each. At a factor of 0.90 the disagreement fell back to 0.00071, against a floor of 0.00099: inside the noise, exactly as before the fault was planted.

SERVICER-NORTH against appeal under days rescaled: nearest 0.90 at 0.00071 against 0.00099
the measurement: days recorded at 0.90 x its value

The conclusion is a precise one. Northern Mortgage Company’s practice is fine, and so is the rule. What’s wrong is the measurement: the days in Northern Mortgage Company’s file were recorded at 0.9 of their real value. That distinction matters, because in an organisation those are three different conversations with three different people. A breach of the rule goes to the servicer’s compliance team. A wrong rule goes back to whoever wrote it. A mis-scaled measurement goes to the people who run the data. Minotaur names which one it is.

Asking in plain words

All of the questions so far were asked of Minotaur directly. In ordinary use, someone types a question, and the answer comes back in words. Here are two exchanges from the same run:

Q: Does SERVICER-SOUTH follow appeal?
A: No: SERVICER-SOUTH departs from appeal. That is witnessed, in the comparison it holds.

Q: Why does SERVICER-SOUTH depart from appeal?
A: Because: a reading of the record says so: “SERVICER-SOUTH and appeal: not one at SERVICER-SOUTH’s rows (south.csv) (loss 0.00976 against 0.00125, declared noise 0.0048)”. It was read on south.csv#4c0af25708ae, appeal#36ffadbc0e18, rulebook.txt#89cc6568532f, run#12.

These answers aren’t composed freely. When Minotaur measured Southern Mortgage Company’s departure, the result was filed back into the record as a reading, together with the fingerprints of everything it was measured on. The answer to the person is then built only from that filed reading. Before it’s shown, it’s checked against the reading: if the wording contained a number, a name or a degree of certainty that the reading doesn’t hold, it wouldn’t be said.

“Witnessed” tells the person what kind of claim this is. It means Minotaur measured this itself, as opposed to, say, quoting what a document says. The “why” answer gives the measurement in full, and then the fingerprints, so anyone who wants to check can see exactly which version of which file the answer came from.

And if the data changes?

Suppose Southern Mortgage Company’s file is replaced tomorrow with an updated one. The next time the record loads, Minotaur compares the fingerprints of its readings with the files as they now are. The fingerprint for Southern Mortgage Company’s data no longer matches, so the reading about Southern Mortgage Company lapses. The answer then says which file has changed, and that it has been read again, rather than going on repeating a conclusion about data that no longer exists.

Here is the whole run in one place:

That’s the whole run. At no point did Minotaur predict anything or guess. Every answer it gave was either a measurement, or a refusal to answer where the record couldn’t support a measurement, and each one came with the evidence needed to check it.

How Small a Departure Can It See?

One run on one pair of servicers doesn’t tell you how far to trust a check. What a compliance team really wants to know is two things: how small a departure Minotaur can pick up, and whether it ever raises a false alarm against a servicer that’s doing nothing wrong. Those two pull against each other. A check that is too sensitive will accuse innocent servicers every time their data is a little noisy, and one that is too relaxed will let small but real breaches slip through.

To test both, we kept the same mortgage rule (an appeal must be offered from 90 days before the sale) and generated a series of servicer files, each holding 4,000 applications spread between 0 and 240 days before sale, with the same kind of noise as before. In some files the servicer follows the rule exactly. In the others it draws its line a little late, offering an appeal only from 92 days, or from 95, 100 or 110. A servicer whose line sits at 92 days is wrongly refusing only the borrowers who applied 90 or 91 days before the sale. In a file like this that’s about one application in a hundred.

For each position of the line we generated ten separate files, each with its own random noise, and asked Minotaur of every file the same question as before: does this servicer follow the rule? There was no language involved, no model and no training. Minotaur had the accepted rule and the file, and nothing else.

The table shows, for each position of the line, how many of the ten files Minotaur said departed from the rule. The last column shows how large each file’s disagreement was as a multiple of its floor. As before, the floor is the most disagreement that the file’s own noise could account for, so anything below 1 is within the noise and anything above it is a departure.

Start with the first row. The servicer following the rule was never accused, in any of the ten files. More than that, its files sat at seven or eight tenths of the floor, comfortably inside the noise rather than just scraping under it.

Now the second row, the hardest case. A line at 92 days is a two-day slip on a 240-day scale, and it affects about 1% of applications. Think about how an auditor would usually find that. If they pulled a sample of 50 files at random, there would be roughly a 60% chance that not one of the wrongly refused borrowers was in the sample, and the problem would go unnoticed. Minotaur doesn’t sample. It reads all 4,000 applications and compares the whole pattern of what was done with what the rule requires, so even forty or so wrongly refused cases stand out once the noise has been allowed for. It caught the 92-day line in all ten files.

The last column is worth a second look too. As the line moves further from 90 days, the multiple rises steadily: from just over 1, to about 2, to about 3.5, to about 6. So the answer says more than departs or follows. Someone reading it can tell a small slip from a serious one without opening a single case.

Real files are messier than these, so we repeated the tests with the files spoiled in different ways, ten files each time:

Bunching the applications made the departure easier to see rather than harder, because a late line then wrongly refuses far more people. And with missing outcomes Minotaur simply works with what is there.

Three Real Regulations

Everything so far used the one mortgage rule, and we had set the tests up ourselves. That leaves an obvious worry: perhaps we had, without meaning to, picked a rule and test conditions that suit the way Minotaur works. The only way to deal with that is to let someone else choose the rules.

So we handed the choice to an independent agent: a separate AI assistant, working on its own, that had never seen any of Minotaur’s code or tests. We asked it to find three passages of real US federal regulation, from different fields and measured in different units, and to key them. Keying means writing an answer sheet. For every sentence, the agent wrote down what kind of rule the sentence is, what decision it leads to, and which questions about it should be answered and how. That answer sheet was fixed before Minotaur saw anything. As with every test in this post, the pass mark for each run was written down before the run itself, so nothing could be tuned afterwards to fit.

The agent chose these three:

These three have nothing in common except that each is a rule with a threshold. That was the point: if one machine can check all three without being changed, it isn’t relying on anything special about mortgages.

What we did with each one

For each regulation we generated data in that regulation’s own unit, days or midnights or parts per million. We made two files: one from an organisation that follows the rule, and one from an organisation whose line is out by a tenth of the range. Then we asked seven questions through the whole chain, typed in as a person would type them and answered in words, exactly as in the walkthrough above. We did all of this three times over, with three separately generated sets of data.

Then we broke things deliberately. A checking system that only works when everything is correct isn’t much use, because the most important question in real life is often what went wrong? So into each regulation’s set-up we planted four different kinds of fault, one at a time. Each one goes wrong in a different part of the chain:

How Minotaur finds the fault

When an answer doesn’t come out right, Minotaur doesn’t guess at a cause. It works through a fixed ladder of questions, in order, and stops at the first part that fails.

The order matters. The first questions check the things everything else depends on: whether the facts taken from the rulebook match their sentences, whether the rules match their sentences, and whether any definition has been given a consequence the text doesn’t give it. Only once those are known to be sound does it ask whether the data itself is off. It asks that by trying rescalings of the measurements, as it did with Northern Mortgage Company’s file earlier. Last of all, it asks whether the question was understood.

What came out

For each regulation there were four kinds of fault, each planted in three separate data sets: twelve faults per regulation in all. In every one of the twelve, for all three regulations, Minotaur named the part of the chain where the fault had actually been planted. It said “misread clause” when the clause had been misread, “mis-scaled measurement” when the data had been scaled, and so on.

We then repaired only the part it named and asked all seven questions again. Every answer came back correct, which confirms that the part it named was the whole of the problem.

For anyone thinking of using a system like this, the first two rows of that table may matter most.

Automated checks fail, as all software does. What matters in practice is whether, when they fail, they can tell you what failed: the reading of the regulation, the rule built from it, the data, or the question. A check that can do that can be trusted to the extent it has earned. A check that can’t has to be redone by hand whenever it raises an alarm.

The Kinds of Reasoning Minotaur Has Shown

People have been classifying kinds of reasoning since Aristotle, and AI research has spent seventy years trying to get machines to do each of them. Below we go through the classic kinds one at a time, and for each one point to where Minotaur did it in the runs above. In every case it did so by measurement on ELC, not by manipulating symbols and not by predicting text.

Deduction: applying a rule to a case

Deduction is reasoning from a general rule to a particular case. If the rule is “an application 90 days or more before the sale must be offered an appeal”, and this application arrived 150 days before the sale, then it must be offered an appeal. It’s the oldest form of reasoning there is: Aristotle’s syllogism, and the modus ponens of formal logic. Classic AI did it by writing the rule as symbols and matching the case against them.

Minotaur does it when it carries a case through the rule. The rule is held as a relation, the case is passed through it, and what comes out says whether the case is let through or held back. In the walkthrough, an application at 150 days came out entitled to an appeal and one at 30 days did not. Minotaur also adds something a symbolic engine doesn’t: it only commits to the answer when the record has real cases near the one being asked about.

Induction: working out the general from the particular

Induction runs the other way, from many particular cases to a general pattern. Given 4,000 decisions, what policy was this servicer actually following?

Minotaur does this every time it holds a record as its own picture. It doesn’t take the servicer’s word for its practice, and it isn’t told it. It builds the picture from the cases themselves. That’s how it found that Southern Mortgage Company’s practice differs from the rule, and then where. Nobody told it there was a line at 114 days; the departure between 90 and 120 days came out of the cases.

Abduction: inference to the best explanation

Abduction is reasoning from an observation to whatever best explains it. The lawn is wet, so it probably rained, unless the sprinkler was on. It’s how a doctor works from symptoms to a diagnosis, and how a detective works from clues to a culprit. It’s also among the hardest kinds of reasoning to get machines to do well, because there are always several possible explanations and the job is to pick the right one.

Minotaur did this in the second run. It observed one thing: Northern Mortgage Company’s file no longer matched the rule. Several explanations could account for that. Northern Mortgage Company might have broken the rule, the rule might have been entered wrongly, the text might have been misread, or the data might be off. Minotaur tested each explanation in turn, and found that one of them, a measurement recorded at 0.9 of its true value, accounted for the observation completely. Rescaled by that factor, the file matched the rule to within the noise. That is inference to the best explanation, with the explanation not just chosen but checked.

Diagnosis: finding the faulty part of a system

Model-based diagnosis is a classic branch of AI in its own right, developed in the 1980s by Johan de Kleer, Brian Williams and others. Given a description of how a system should work, and an observation that it isn’t working, it asks which component is at fault.

This is what Minotaur’s fault ladder does, applied to its own chain. On three real federal regulations we planted four kinds of fault, each in a different component: the reading of the text, the rule, the measurement, and the understanding of the question. Every one of the 36 faults was named at the component where it had been planted. Repairing only the named component restored every answer, which is the strongest test of a diagnosis: fix what it says is broken, and everything works.

Hypothetical reasoning: what if?

Hypothetical reasoning asks what would happen in a case that hasn’t been observed. Would an application at 150 days get an appeal? This is where machines most often go wrong, because they answer confidently about situations nothing in their data resembles.

Minotaur answers hypotheticals by carrying them through the rule, as with deduction. But it certifies the answer only where its record has real cases nearby: 120 applications near 150 days, and 144 near 30. In effect it distinguishes interpolating, which it will do, from extrapolating, which it won’t do silently.

Comparative reasoning: which is worse?

Comparing two cases fairly means putting them on the same footing first. Two servicers whose files have different amounts of noise can’t be compared on their raw disagreement with the rule.

Minotaur weighs each servicer’s departure against that servicer’s own noise before comparing them. In the walkthrough it ranked Southern Mortgage Company as departing most, at 8.2 times its floor, with Northern Mortgage Company inside its own.

Reasoning under uncertainty: how sure, and how much?

All real data is uncertain, and good reasoning has to say not only what it concludes but how firmly. Classic AI attacked this with certainty factors, fuzzy logic and probability networks, usually bolted on to a system that was otherwise symbolic.

In Minotaur it’s built into every comparison. The floor is the most disagreement the data’s own declared noise can explain, and every conclusion is a statement about where the evidence sits relative to that floor. That’s why a two-day slip in a servicer’s practice, affecting about one application in a hundred, was caught in ten files out of ten, while a servicer following the rule was never once accused. It’s also why the answer says how far a practice departs as well as whether it does: from just over 1 times the floor for a two-day slip to about 6 times for a twenty-day one.

Belief revision: changing your mind when the facts change

A reasoner that can’t withdraw a conclusion when the evidence for it changes will go on repeating things that are no longer true. Classic AI called this belief revision or non-monotonic reasoning, and built truth maintenance systems for it, starting with Jon Doyle’s in 1979: systems that record why each belief is held, so that it can be retracted when its reasons go.

Minotaur keeps exactly that kind of record. Every reading carries the fingerprints of the data, the rule and the run it was measured on. When a file it had read was replaced, the reading lapsed the next time the record loaded, and the answer said which file had changed. Nothing had to be told to forget anything.

Reasoning with conflicting evidence

In classical logic, a single contradiction lets you prove anything at all, which is why systems built on it can fall apart when their evidence disagrees. Logics that can live with contradictions without collapsing are called paraconsistent.

Minotaur behaves paraconsistently. When two readings disagree it neither collapses nor quietly picks one. It reports both, says what each was measured on, and leaves the tension standing until a person resolves it.

Explanation: answering “why?”

The expert systems of the 1970s and 80s were admired above all for one feature: you could ask them why. MYCIN, the medical system built at Stanford, would show the chain of rules that led to its advice. Today’s language models have largely lost this. They can produce an explanation, but it’s another piece of generated text, not a record of how the answer was actually reached.

Minotaur’s explanations are records. Asked why Southern Mortgage Company departs, it quoted the measurement it made and the fingerprints of the exact files it made it on. Its wording is checked against that record before it’s shown: in our tests, 102 deliberately planted distortions of its answers were all caught.

Doing it across fields

Finally, none of this was specific to mortgages. The same machine, unchanged, did the same reasoning on a lending rule measured in days, a healthcare rule measured in hospital midnights, and an environmental rule measured in parts per million. A symbolic system has to be told about each field in that field’s own terms. Minotaur needed nothing more than the rule and the records, because in ELC all three are the same kind of thing.

In summary

Over the years AI research has produced a separate technique, and often a separate system, for almost every row of that table. In Minotaur they all come from the same two steps: putting rules and records into the same representation, and measuring one against the other.

Where This Leaves Us

The industry’s answer to better AI has been bigger models: more weights, more GPUs, more power, with language and reasoning bound up together in one opaque network. Minotaur suggests that for a large class of problems the reasoning needs none of that. Put the world into a universal representation of systems, and reasoning becomes measurement. Measurement you can run on a laptop, replay and check.

The core of it works now, end to end.

A machine that reasons about rules and records by measuring them, and shows its working.

The ideas behind Minotaur, from the three roles of Energy, Logic and Control to the mathematics of MINOS, are set out on the MINOS page. The mathematics itself is in the paper An Operational Representation of Systems: A Worked Construction in Lattice Gauge Theory (doi:10.5281/zenodo.23491024). The ELC adapter is patent pending.