Every company runs on decisions

Approve or decline. Escalate or handle it. Refund or refuse. Strip away the software and the org chart, and making decisions is what a company does all day.

• Your operational know-how is your most valuable asset. Which evidence counts, which exception beats which rule, and when to ask a human. It took years to build up.
• Almost none of it is written down. It lives in policy documents, in past precedents, and in the heads of senior staff.
• Now AI is taking over the work. But this institutional know-how is the exact thing software teams struggle to hand it.

When AI makes a mistake, nobody can explain why

Company rules, prompt instructions, software code, and the model's own statistical guesses are mashed together into a single black box.

• You cannot isolate the root cause. Was the prompt unclear? Was it a software bug? Did the model hallucinate? From the outside, all three look identical.
• Auditors get outcomes, not policy. You can show regulators what the AI did, but not a clean document proving what it was supposed to do.
• Your logic is locked to one vendor. Switch AI tools or models, and engineers rebuild your business reasoning from scratch.
• You cannot measure improvement. Without a written baseline of rules, there is no way to test whether a prompt change made decisions better or worse.

AI succeeds where the work checks itself

AI works exceptionally well at writing code. Not because coding is easy, but because code comes with an automatic referee.

• Code grades itself. Software compiles or it fails. Automated tests pass or they break. The verdict is instant and clear.
• Business decisions lack a referee. Rules are spread across systems, terms mean different things to different teams, and results take months to evaluate.
• The fix is not just a smarter model. The missing piece is writing business judgment down in a clear format that can be checked automatically.

Search finds information. Judgment makes the call.

Most AI projects focus on search and document retrieval. Connecting AI to your documents matters, but finding information is not the same as making a decision.

• Search retrieves facts. It locates the relevant policy page or customer history, but it has no opinion on what to do next.
• Judgment decides the action. It determines which rule applies, handles exceptions, checks whether the evidence is sufficient, and escalates to a human when it is not.
• Search feeds judgment. Data and documents are inputs to a decision. They do not make the call on their own.

Package business judgment into a single file

A Judgment Pack is a clean, structured file that spells out one business decision completely. No hidden AI prompts, no buried code — just clear, executable logic.

• It states business intent. What is being decided and why, so anyone can verify that the rules match the business goal.
• It handles real-world complexity. Exceptions, missing information, and the point at which a human manager must step in are all written down explicitly.
• The permitted outcomes are named in advance. The file lists every result the business will accept, so anything else an AI produces is visibly outside the set rather than a plausible-looking surprise.
• It reviews like software. Track changes over time, compare versions, and sign off on a policy update in writing.

One file, three different readers

Judgment Pack connects business policy, AI engineering, and compliance review through a single shared artifact — one each of them can actually read.

• Engineering and technology leaders keep institutional knowledge as an asset the company owns — written in a vendor-neutral file rather than inside one vendor's prompt, so changing the tool underneath does not mean rewriting the rules. Whether decisions hold when the model changes is untested, and implementations from outside this project remain an open gate.
• Risk, legal, and compliance teams inspect the exact logic, exception rules, and human escalation triggers before a system goes live — rather than inferring them from behaviour afterwards.
• The policy owner can read the rules that govern their own process without reading code, and argue with a proposed change before it ships rather than after.
• The common thread: the reasoning stops being a property of one tool and becomes a document all three can review.

Checking the format is not the same as business approval

The obvious risk with automated checks is that a “valid” file gets read as a “safe” business decision. The design keeps those two things firmly apart.

• What automated tools check: that the file is correctly formed, and that it hangs together internally — every reference resolves, identifiers are unique, and each field means what the specification says it means.
• What agreement between tools actually is: a requirement the specification places on conforming engines — same inputs, same result — not a check anyone runs against your file. The evidence behind it is a 20-row seed corpus that publishes its own gaps.
• What stays with people: whether the input facts are true, whether someone with authority signed off, and whether the policy is lawful and safe to act on here.
• Validation is not permission. A valid file is well formed and internally consistent. It does not mean the rules are free of contradictions — two rules that disagree are a result the engine reports, not a validation failure — and never that the logic is correct, authorised, or appropriate for a given case.

What the research has shown so far

The work tested whether business reasoning can be lifted out of AI prompts and into a standalone, portable format. Four things came back:

• Logic can be separated from the model. Business rules do not have to live inside a prompt. Moved into a plain file, the exceptions and escalation rules stay explicit rather than implied.
• Separate implementations reach the same result. A second tool, rebuilt from the written specification alone in a different programming language, matches the reference tool on every case — byte for byte, once the specification was amended to pin the one output detail their first run showed it had left open.
• Not everything fits, and the misfits are informative. Encoding real policies surfaced cases the format could not hold — recorded as published negatives rather than smoothed over, and they are what the open proposals are trying to answer.
• Disagreement is the useful signal. Where the two implementations differed, the fault was in the written specification rather than in either program — so the specification got fixed.

Measured across 47 tests on the file format, plus 20 decision scenarios replayed through both engines. One limit, stated plainly: both implementations trace to the same maintainer, and the second was written from reference texts that already carried the first's implementation notes — so the agreement corroborates that the specification is precise rather than independently confirming it. Two genuinely independent implementations is the bar for calling any of this stable, and it is not met.

Verifying the facts before the logic is applied

A Judgment Pack defines how rules are applied. It cannot guarantee the input data is factual — and an AI that can state a fact can also invent one. That gap is handled in a separate layer.

• A gateway fetches the data, not the AI. A configured source is run by the gateway and its result signed on the way in — so a model can still state a made-up number, but it cannot produce a valid receipt for one.
• Records are tamper-evident. A completed session is sealed, so an altered, replayed, or truncated record can be detected rather than passing silently.
• Anyone can verify, and no-one gains the power to forge. Checking needs only a public key — no access to the source systems, and nothing that would let the checker mint a record. The key has to be obtained out of band.

The ceiling is stated up front and does not move: this proves that these exact bytes passed through the gateway and were not altered afterwards — never that a genuinely-named system produced them, and never that the data was right. The source name on a receipt is an operator label, not an authenticated origin. This is a single-operator reference implementation that no runtime consumes yet, and nothing in the specification defines it — which is why the status section still lists it as open.

We publish the results that went against us

“An open standard earns trust by solving real problems simply, and being transparent about what is still unsolved.”

Experiments are written down before they run, the people doing the work do not know which result is hoped for, and failures are published as visibly as successes. Three examples, none of them flattering:

None of this is something you have to take on trust — each is written up in full, method and data, in the public research repository. It is also why this is published as a research preview: to invite independent review and testing before a 1.0, rather than after it.

What works today, and what comes next

Current release: Core 0.2.0-draft. A practical foundation for testing and evaluation — with no stability promises yet, and not something to put in front of a consequential real decision today.

Help build the open standard for AI judgment

This is a vendor-neutral specification with, today, a single maintainer and no independent contributors — which is exactly the problem. At this stage the most useful contribution is criticism. Four kinds of people would move it furthest:

The most valuable thing anyone can send is a case this format handles badly. The roadmap is gated on evidence from outside the project, and that evidence does not exist yet.