Not the answer. The decision.
Somebody used AI to decide something. Two years later a regulator, an auditor, a reinsurer or a court asks why. What can you actually hand them? A model that no longer exists, a prompt nobody kept, and a confident sentence is not a defence. Primer is the layer that produces the record: every determination cites the rule it applied, is sealed against the hardware in the machine, and can be checked years later by somebody who does not trust you.
Nobody is worried about whether the AI sounds clever. They are worried about the day somebody asks them to justify what it decided — and they discover the reasoning was never written down, the model has been replaced twice since, and the only record is a chat log.
A family requests an informal hearing. Federal rule already requires a written decision stating your reasons, on the evidence. Can you show which rule you applied, and that it has not changed since?
A claim was denied. Under ERISA the member can demand every record considered in that decision, whether or not it was relied on. Can you produce it?
A finding is challenged a year later. Which version of the rules were you applying that day, and can you show they have not been edited since?
An examiner reviews files closed years ago, or a reinsurer asks why a risk was priced that way. "The model said so" ends the meeting badly.
What every one of these has in common: the decision has to survive the tool that made it. Models get deprecated, vendors change, prompts get lost. The obligation does not expire when the technology does.
Primer is not a chatbot and not a wrapper around one. It sits underneath whatever AI you use, and it is what actually makes the call.
A determination comes from a lookup against your authoritative reference data — the codes, forms and manuals your industry actually runs on. Not from a model's opinion, and not from something that looked similar.
No rule enters without a citation stored beside it. If a determination cannot be written to the record, no verdict is returned at all — an unrecorded decision is not evidence, and handing one over would be worse than saying nothing.
Every determination is written to an append-only record, hash-chained so a later edit breaks the links, and sealed against a key that was born inside the machine's security chip and cannot be copied out.
Each determination records the exact state of your rulebook at the moment it was made. When the codes change next year, an old decision is still judged against the rules that applied then, not against today's.
The model is never in the decision path. The components that produce a verdict import the standard library and nothing else — no model, no embedding, no similarity score. The AI can help a human draft a rule, and a human must supply its citation before it is accepted. After that, the AI can be swapped, upgraded or switched off entirely and every past determination still reproduces exactly.
These categories are not competitors so much as different jobs. Most of them are worth having. None of them leaves you with something you can hand to an examiner.
| Chat memory & retrieval |
Guardrails & filters |
Eval & observability |
Primer | |
|---|---|---|---|---|
| What it is for | Better answers | Blocking bad output | Measuring quality | Proving the decision |
| Where a verdict comes from | The model | The model, filtered | The model | A lookup against your authority |
| Model in the decision path | Yes | Yes | Yes | No |
| Cites the rule it applied | Sometimes, as a link | No | No | Always, or it refuses |
| Record of the decision | Chat history | Filter logs | Metrics & traces | Append-only, hash-chained |
| Detects a later edit | No | No | No | Yes, and names the file |
| Rooted in hardware | No | No | No | Yes, key non-exportable |
| Third party can verify without you | No | No | No | Yes, one command |
| Swap the model | Answers change | Answers change | Baselines reset | Determinations unchanged |
| Old decision, new rulebook | Re-answered with today's | n/a | n/a | Judged against the rules in force then |
Categories, not named vendors — a fair comparison to a specific product depends on how it is configured, and we would rather be argued with about the rows than about the labels.
Working Primer Cores are running today on public federal reference data, sealed to hardware and independently witnessed. Nothing below asks you to take our word for anything — every claim on this page is one you can check yourself, which is the only kind worth making.
Every sealed root is timestamped by a public certificate authority — the same artifact used for code signing, recognised under Federal Rules of Evidence 902(13) and 902(14). Verifying one needs no account, no API key and no trust in us:
openssl ts -verify -token_in -digest <root> -in <token>.der -CAfile <ca-bundle>
It fails closed. A token witnessing a different record, or one whose signature has been altered by a single byte, is rejected with the reason stated.
Rewrite a verdict and the content hash breaks. Delete an entry and the chain link breaks. Edit a sealed rule and the verifier names the file. Each of those is a test that runs on every record.
Code sets change every year. Primer stages the new set, re-runs every known case against both versions, and reports which outcomes moved — before anything is sealed. Rewording one description once flipped four coverage outcomes with no error anywhere.
Primer's own test results are not typed into a document. They are produced by running every suite and every Core, and appended to a history that is never rewritten. A regression shows up as a dated entry, not as a number somebody forgot to update.
ERISA 29 CFR 2560.503-1, CMS coverage determinations, ICD-10-CM, HCPCS. Public sources mean a Core can ship without a licence negotiation, and anyone can check the rule against its citation.
A Primer Core is a cartridge: your authoritative reference data plus the sealed record built against it. The Core is the authority. The model is disposable. Change domain and you change the Core, not the machinery — the sealing, the record, the hardware root and the verification are identical whether the subject is a diagnosis code or a property roll.
Eligibility, rent calculation, terminations — each one appealable, each one needing the rule you applied.
Determinations that carry their own citation and survive an appeal years later.
Findings that can prove which version of the rules produced them.
If somebody may ask you to justify it later, it belongs in a Core.
Public authority moves on a schedule. Diagnosis codes turn over annually. HOTMA sections 102 and 104 become enforceable for public housing authorities on 1 January 2027, changing how income is calculated and reviewed. The day after a change like that, an organisation holds determinations made under two different rulebooks, and an appeal on an old one has to be judged under the rules that applied then.
Primer stages a proposed rule set, re-runs every known case against both the current and the proposed authority, and reports which outcomes moved — before anything is sealed. In testing, rewording a single code description flipped four coverage outcomes from payable to denied, with no error raised anywhere. A seal proves the authority changed. Only this shows what the change did.
Every determination also records the state of the rulebook at the moment it was made, so a decision from last year is still judged against last year's rules rather than today's.
Some of these are choices we made on purpose and would not reverse. The rest are on the roadmap with a direction. Ask any vendor for both lists.
Primer proves which rule was applied and that it has not changed. Whether that rule is right stays with the professional whose name is on it. We are not in the business of overruling your subject matter expert, and a vendor who claims to be should worry you.
A human authors every rule and supplies its citation. What Primer removes is reconstructing a decision months later from memory and a spreadsheet — not the decision itself, and not the person who makes it.
Language models are confidently wrong, and every one of them will be replaced. Keeping the model out of the decision path is the reason a determination made today still reproduces after the model it was drafted alongside no longer exists.
Three Cores run today on public federal data. A housing Core is the same architecture pointed at 24 CFR — identical sealing, record and verification. In development now, with HOTMA's January 2027 compliance date as the target.
The hardware root runs on Apple's Secure Enclave today and is verified across machines. TPM and PKCS#11 token support is the next platform layer, and the interface above it does not change.
A record can already be fingerprinted so a truncated copy cannot agree with one held elsewhere. Scheduling that export off-machine automatically is the next step, and it is the difference between tamper-evident and tamper-proof.
The useful conversation is not a demo. It is you describing a determination your organisation makes, and us being specific about whether a Core can carry it — including when the answer is no.
Project Black Box LLC · Texas DIR certified · Method and results published on Zenodo