open source — proveml

Every claim an AI writes, checked against your data.

AI is genuinely exciting right now. Every few months it writes better, reasons further, picks up more of the work that used to eat your afternoons. You start to feel foolish for not using it.

Then it turns on you. Quietly, in the middle of a perfectly ordinary sentence:

a support reply drafted by AI, after checking

Hi Marta, thanks for reaching out about order 4821. It ships on 14 March, and your warranty runs until 3 June 2027. You are still covered, so the repair is free of charge. The outstanding balance is €1,240.

  • subject the record this reply is about
  • verified the record agrees
  • falsified the record contradicts it
  • a judgment whose rule holds
  • unproven no record to decide either way

Send that as it stands and you have promised a year of warranty you do not owe, and quoted a figure that came from nowhere. Marta will hold you to both, and she will be right to — she was told in writing.

One mail, four kinds of truth, and without the marks they all read the same. That is the part worth sitting with: fluency is uniform, correctness is not.

Note that the three states are not degrees of the same thing. Falsified is the strongest of them: the record actively contradicts the sentence, and no amount of confidence will save it. Verified is weaker than it sounds — it means consistent with what you hold, nothing more. And unproven is not a soft failure but an honest one: there was nothing to decide against. Most systems collapse these last two into silence, which is how a made-up number ends up reading like a checked one.

Every chat window warns you about this — AI can make mistakes, check important info — and none of them tells you how. Check what, against what, by hand, every number, every time? The disclaimer hands you the responsibility and no instrument to carry it.

And it gets worse as the models get better, not better. At 80% correct you stay alert. At 97% you skim, then you stop looking — and the rare wrong number now travels further, through more mails, read by more people who have learned it is usually right. Accuracy without a way to check does not remove the risk. It hides it.

So the check has to become mechanical. Not a second AI grading the first — that is another opinion, and opinions can be talked out of things. A lookup. A comparison. Something that either matches your data or does not.

the disclaimer is not the problem  ·  the missing instrument is

the design goal

Maximum determinism, without caging the model.

The obvious fix is to lock the model down: templates, fixed sentences, dropdowns of approved phrasings. It works, and it throws away the reason you wanted a language model. You get a mail-merge that costs GPU time.

ProveML pulls the two apart. Generation stays fully open — the model writes what it wants, in whatever order, in any language, at any length. Verification stays fully closed — every claim it marks resolves to one path in your data and is checked by string equality or arithmetic, with no model anywhere in that loop.

Open-endedness where it pays, determinism where it counts. The prose is free; the claims are not.

fixed AI the model writes freely, marks claims open-ended the verifier lookup and comparison deterministic the report a status on every claim deterministic data + rules data + rules marked text results what failed, and why fact store one path per field ▾ order:4821.reference → "order 4821" order:4821.shipDate → "14 March" order:4821.warrantyUntil → "3 June 2026" order:4821.warrantyDaysLeft → 308 threshold registry cutoffs you define ▾ IS_IN_WARRANTY: warrantyDaysLeft gt 0

Only one box here can invent anything. The rest look things up. The verifier reads the same data the model was given, so a claim is checked against the source rather than against a second opinion. Failures return as specific corrections — warrantyUntil is 3 June 2026, not 2027 — which an agent can act on without a human in between.

Note what the verifier never does: arithmetic. A rule like “still under warranty” cannot ask what today is — a check that knows the date gives a different answer tomorrow for the same text, and then it is not a proof. Your data layer works out warrantyDaysLeft and stores it; the verifier only compares it to zero. Everything it touches is a value someone can point at.

underneath

Nothing above was styled by hand. This is what the model wrote, and the marks come from checking it:

reply.md
Hi Marta, thanks for reaching out about @[order:4821]{order 4821}.
It ships on %[shipDate]{14 March}, and your warranty runs
until %[warrantyUntil]{3 June 2027}. ?[covered: IS_IN_WARRANTY]{You are still covered},
so the repair is free of charge. The outstanding balance
is %[balance]{€1,240}.

Strip the brackets and you have the mail, word for word. What was added is a path into your records wrapped around the words the reader was going to see anyway. Renderers that do not know ProveML pass them through unchanged; a verifier that does resolves every one against your data. warrantyUntil came back wrong because the order says 2026. balance came back unprovable because orders in this system have no balance field at all — the model filled a plausible gap, which is exactly what models do.

Neither failure needed a human to notice it, and neither needed a second AI to judge it. A lookup was enough.

where the data comes from

From verified to trusted.

Verified means one thing so far: the claim matches your record. It says nothing about whether the record deserved to be believed. That is where verifiable credentials come in.

An SD-JWT credential is signed once by its issuer, over a list of hashes — one per field. The holder then sends only the values they choose; each one hashes back to a line the issuer already signed. One disclosed field, one checkable claim: exactly the granularity ProveML works at.

Feed those into the fact store and a verified claim stops meaning “our database says so”. It means the issuer signed for it, and the signature holds. So the rendering answers two questions instead of one: does the record agree, and was the record worth agreeing with.

the credential in the wallet
issuer
Acme NV — HR Department
valid until
1 September 2026

what the signature covers

  • Kl8Wm2p… name Alice De Smet
  • 9xQr4vN… employer Acme NV
  • 7bTz1cX… role Staff Engineer
  • mE5oL8k… location Ghent
  • vR3nY7d… Qa9Uf2s… Jt6Ib4w… three more, not disclosed

The issuer signed seven hashes. The holder sent four of the values behind them; the other three stay closed, and the signature holds either way. Salary and employee number were never part of this conversation.

issuer signature sha256:4f2a…9e11

a second credential, no longer in force
issuer
OldCorp BV — HR
valid until
1 January 2025

what the signature covers

  • Wp2Kd8m… name Bob Janssens
  • Rx7Vn3q… employer OldCorp BV

The signature on this one still checks out perfectly. It says what it always said — only it stopped being current eighteen months ago, and a signature cannot tell you that on its own.

issuer signature sha256:b81c…27fa

an HR summary, checked against both credentials

Alice De Smet is employed at Acme NV as a Senior Engineer, based in Ghent. Bob Janssens was employed at OldCorp BV.

  • trusted a live credential agrees
  • falsified the credential contradicts it
  • stale agrees, but the credential has expired

Bob's line is the interesting one, and the second card is why. His claim matches that credential perfectly and the signature verifies — it is simply no longer in force. Cryptography will happily confirm a true statement about a job someone left, which is the sort of thing a fact store cannot notice at all.

This is the format the European identity wallet uses, so these credentials are not hypothetical: they are what employers, schools and public bodies are being built to issue. Signed data is how a claim gets from consistent with a record to someone put their name on it — which is a different sentence entirely when a regulator asks.

sd-jwt adapter  ·  two axes: does it match, and does the signature still hold  ·  working example ships with the package

three constructs, one rule

  • Entities

    @[order:4821]{order 4821} — this text refers to that record. Checked against the stored reference.

  • Facts

    %[shipDate]{14 March} — this value is that field. Checked by exact comparison, units included.

  • Judgments

    ?[covered: IS_IN_WARRANTY]{still covered} — replies also say “still covered” and “critically low”. Those are claims too, so they must name a rule someone defined outside the generation.

  • The boundary

    Everything outside a construct is ordinary prose and is never presented as checked. Knowing where the guarantee stops is part of the guarantee.

what it lets you do

  • Send without rereading

    Every value carries a status before anyone sees it, so your attention goes to the handful that failed instead of the hundred that held.

  • Agents that fix themselves

    A failed check is a specific message — warrantyUntil is 3 June 2026, not 2027 — so the model repairs that one claim and tries again. No human needed for the boring half.

  • Check what you did not write

    Verification is separate from generation, so a document can be checked months later, against the data as it stood, with the same answer every time.

  • Adjectives that mean something

    “Still covered” means what your warranty rule says it means, defined outside the model. The phrase becomes a claim you can check, not a courtesy.

  • Evidence on request

    Audit view puts the checked path beside each claim — order:4821.shipDate — so a reviewer sees which record backs which sentence, without reading any markup.

  • Names stay with you

    The model works with order:4821; real names and addresses are filled in at render time. The claims are checkable, the personal data never left your side.

try it

One command, nothing to set up.

npx proveml demo

It prints a short report in your terminal, the records it was checked against, and the same marks you saw at the top of this page — verified, wrong, unproven — underlined right in the text.

Once you want it on something of your own, give it a file and your data:

npx proveml verify --input report.md --facts facts.json

The exit code is 1 when a claim fails, so this drops into a build the way a test does. Your data goes nowhere: the check runs on your machine, against a file you control.

npm: proveml →  ·  apache-2.0  ·  source opens with the paper

what it does not do

ProveML verifies that claims match your data — not that your data is right. If the source is wrong, the verified claim is confidently wrong. It checks what is inside the markup; prose outside stays unchecked, on purpose — and the marking itself is the model’s work, so a number written without markup passes as prose. Coverage is the one thing the verifier cannot judge for you. And values must match exactly, so a report says 18.5, not “about 18”.

We would rather state that plainly than sell certainty we cannot deliver. It is the same reason the verifier has no model in it: a guarantee you can explain in one sentence is worth more than one you have to trust.

where it runs

ProveML runs under Elixir, our watchful agent: every weekly report it sends is proven before it reaches you. It is the mechanical half of our trusted-AI standard — the part that does not depend on us keeping a promise. The research behind it is written up in a paper, with the benchmarks and experiment artifacts published alongside, and the credential work connects it to the European identity infrastructure we spent years building.

the findings, verified by ProveML itself →  ·  read the paper (pdf) →  ·  trustedagentic.ai →