Your team’s judgment is an asset you should own

Everyone has access to the same models. How your organization reasons and decides is something you should own.

About

What we believe in

I. The unwritten rules

Organizations doing operational work are not short of rules - they run on published regulation, counterparty requirements, and internal policy - thousands of pages, amended continuously. Most decisions those rules govern are deterministic, there is a right answer and two competent operators should reach it.

But then a real case arrives and applying the rules turns out to be the smallest part of the job.

Reaching the right answer requires knowing things about the world that no policy contains. That one counterparty always conditions on a document the rule does not require. That a form was revised in January and a figure on it now includes an item it previously excluded. That requesting one thing before another gets the request rejected and costs two days. Thousands of facts of this kind - each small, each true, none written anywhere.

They are unwritten because they cannot be written in advance. They are not derivable from policy; they are facts about the environment policy is applied in - counterparties, documents, systems, sequences, each with its own behavior and its own rate of change. Every change produces new particulars, and a particular becomes visible only when a case brings someone into contact with it.

The senior operator is worth more than the junior one for this exact reason: she has met more of the world and retained what it did. Her store is tacit in the strict sense - not withheld, but indexed by situation. Ask her to explain it in the abstract and she cannot, but present her with a case and she will. From the outside, we call this “judgment”: the competent application of a body of knowledge nobody can see.

The most valuable thing organizations produce is not a closed file, case or item. It is the knowledge generated in the act of doing the work - created thousands of times, captured zero times. There was no alternative: judgment was the only container the knowledge would fit in, and that’s what organizations ran on.

II. The industry tried deleting the wrong thing

When Large Language Models arrived, the industry drew a fast conclusion: the operator is the bottleneck, so remove the operator. Then point the model at the file and let it decide. Underneath sat an unexamined assumption - that the knowledge required to do so is written down somewhere, and the model’s task is to retrieve and apply it.

That assumption is inverted. The written part was never the hard part. Policy is available, structured, and largely unambiguous; the model handles it well, which is why the demos felt so extraordinary. The unwritten layer is in no corpus, by construction. So the architecture hands the model the half that is written down and asks it to infer the rest: where it doesn’t know the rule, it produces something plausible instead - the worst possible failure, because plausible guesses look and feel like the real thing.

Then the deeper problem, and the one that decides the matter: a model in the decision path meets a particular, resolves it, discards the resolution and proceeds onto the next case. It “reasons” the thousandth file from the same starting position as the first, at the same cost and the same risk, like a junior operator with severe amnesia. The single mechanism by which anyone gets good at this work is the one thing the existing architecture has no version of.

Memory and retrieval do not close this gap: they recall prior text, but they do not create obligation. A stored note that a counterparty conditions on something is not a rule, and nothing about having read it binds the next decision to honor it.

And because nothing is captured, nothing can be measured. Without an accumulating body of real cases with known-correct outcomes, reliability can only be asserted: a trace shows what the system did, not that it was right, and gives no way to tell an improvement from a regression.

The original error of deleting the operator is categorical. The operator was not the obstacle to systematizing this work. Instead, she was the only place in the world where the missing layer exists.

III. Compiled knowledge

Let’s start from the rejection: sufficient knowledge does not exist yet. The particulars that make this work correct come into being through contact - when a case puts someone in front of a fact that taken in abstraction appears too small, too specific or too complex to comprehend and document. The knowledge that the system needs cannot be found. It has to be manufactured, continuously, out of the work itself.

This was attempted before and failed for reasons that can be named. Expert systems required a knowledge engineer to interview an expert away from the desk and hand-encode her answers into a formal representation. Elicitation was severed from the case that would have prompted it, conducted in a language the expert did not speak, at a cost per rule so high that the world changed faster than the rules could be written. Every part of that constraint has now been lifted. The question can now be asked inside the case, at the moment of contact; the operator answers in her own words; the machine writes the formal artefact. And replaying an entire case history against a proposed change is cheap enough to do on every change - which is what allows a rulebook to reach thousands of interacting rules without collapsing.

Three principles follow:

Built bottom-up, from real cases. The rulebook cannot be specified in advance, because the knowledge it consists of does not exist in advance. It is assembled case by case from the work, and every captured particular becomes both a rule and a test. The accumulated set is the documentation the organization never had - the first comprehensive record of how the work gets done.

Closed by a loop around the work. When the system meets a case its rules do not decide, it asks - in plain language, at the moment the operator is holding the thought. The answer is compiled into explicit, versioned logic and run against every case that came before.

Owned by the people who know. Amendable in natural language, with no engineer in the loop, so the rulebook moves at the speed the world changes.

This promotes the operator rather than replacing her. Cases covered by rules she authored execute without her. What reaches her is the case no one has met before, or where the system’s confidence is below a certain threshold, which is the only part that ever required a person in the first place. And her answer stops evaporating when the file closes: it decides every matching case that follows.

The effects compound: capacity decouples from headcount, knowledge survives turnover, and inconsistency between operators eventually becomes impossible because there’s one artefact and that’s what executes.

hegl is that layer. It works inside the work, decides what it can decide, asks when it cannot, and compiles every answer into tested, versioned code. The model authors; the code decides. Reasoning is spent once, on the case no one has seen before, and everything already understood runs deterministically, traceably, and identically every time.

We do not claim a system that is never wrong. We claim one that can be held to account: every decision traces to a rule, every unknown escalates rather than guesses, every error becomes a test. What was muscle memory becomes an asset the organization owns and compounds with every case it runs.

The model is the commodity. Your knowledge is the asset.

A layer like this was always going to be built. The only questions were who builds it, and to what standard.

the hegl team