A diff on every release, automatically

An audit is true about one model at one moment. It reads a specific set of weights, attests what the finetune did, and hands you a signed dossier you can stand behind. Then you ship version two — a new finetune, a fresh data mix, a different base — and the dossier is now describing a model you no longer run. Nothing in it was wrong. It just quietly stopped being about the thing in production.

The staleness problem is structural

This is not a diligence failure; it is the shape of the work. Models version like code, but unlike code you cannot read a diff by eye. When someone changes a function you can see the change in the pull request. When someone reruns a finetune, the "diff" is a new field of weights, and whatever moved between v1 and v2 is invisible unless something reads it. So the audit you paid for slowly becomes a historical document, and the gap between "what we last verified" and "what we are serving" widens with every release.

A one-time audit answers what did this model do? The question you actually live with is what changed since the last one we trusted?

A diff on every version

Monitoring is designed to close that gap by running detection on each new model version against the last, automatically, and attesting what changed. Not a fresh audit from zero every time — a diff: the delta between the version you already attested and the one you are about to ship.

• What moved — the behaviors and dispositions that changed between versions, read from the weights rather than sampled from outputs.
• What held — the parts that did not move, so an unchanged guarantee stays an attested guarantee and not an assumption.
• A witness on the delta — each change carries the same replayable reproduction discipline as a first-time finding.
• A current record — the record stays synced to what you actually serve, so "when did we last verify this?" always has a recent answer.

The effect is that your audit never silently expires. Every release either confirms nothing concerning moved, or flags exactly what did — before it reaches production, not after.

What the attestation says

A monitoring attestation is deliberately narrow: it states the two versions compared, what changed between them, what did not, and the coverage ceiling of the read. It does not re-litigate the entire model on every release — it tells you the difference, which is the thing you can actually act on. Where a version change reads clean, it attests clean; where it can't read something, it abstains and says so, rather than rubber-stamping the release to look smooth.

Staged — and honest about it

Monitoring is on the roadmap and not yet launched. This entry describes what it is designed to do so you can plan for it; it is not a surface you can enable today. Do not build a release gate around it as if it were live.

What is open now is the one-time read that Monitoring automates: bring a model to Audit and Protora attests what the finetune did, with a witness on every finding. When Monitoring launches it will inherit the same limits the single audit already states — assurance and provenance, bounded to a declared coverage, no talk of a "provably clean" model, no promise that every backdoor gets caught, and confined to open-weight models you can read. It complements your release pipeline and your observability; it replaces neither. Track it on the product map; this page will mark it live when it is.