An alarm during training, not after

Staged, not shipped. Drift Guard is on the roadmap and not yet launched. This entry describes what it is designed to do, so you can plan for it — not a surface you can turn on today. The Audit that reads a finished model is the part that is open now.

The cost of finding out at the end

A finetune run is a black box with a bill attached. You launch it, you burn the GPU budget, you get weights back, and only then — if you check at all — do you learn what the training actually did to the model. If it drifted somewhere you did not want it to go, you find out at the most expensive possible moment: after the compute is spent, and often after the model is already on its way to being shipped.

The behavior that matters here is rarely the loss curve. Loss can fall beautifully while the model quietly acquires a behavior you did not intend — a bias from a slice of the data, a softened refusal policy, a lean that no training metric was watching for. The run looks healthy right up until you read the result and discover what "healthy" was hiding.

An alarm while the run is still cheap to stop

Drift Guard is designed to sit inside the run instead of waiting at the end. Checkpoint by checkpoint, it reads the model as it trains and watches for movement toward the wrong behavior — the same kind of read Protora performs on a finished finetune, applied continuously as the weights evolve. When a checkpoint drifts toward a behavior you flagged as unwanted, it alarms.

The value is entirely in the timing. An alarm at checkpoint 400 of 2000 is a decision you can still act on cheaply: pause, inspect, adjust the data, kill the run. The same finding delivered after the model ships is an incident. Same read, wildly different cost, decided by when you get it.

What it watches for

The guard is aimed at the drift you would otherwise only catch by luck:

• Behavior drift — the model leaning toward something your training was not meant to install, surfaced from the checkpoint rather than sampled from its outputs.
• Guardrail erosion — refusal behavior weakening across checkpoints, read directly rather than probed for.
• A training-time record — a per-checkpoint log of how the model moved, so the run itself leaves behind evidence, not just a final artifact.

Each alarm is designed to carry the same replayable witness discipline as a finished-model finding: a reproduction, not an assertion. And where a checkpoint reads clean, it says so plainly rather than inventing a concern to look vigilant.

What "staged" means here — read this before you plan around it

Drift Guard is not available today. It is a planned surface, and this entry exists so you can shape your training pipeline knowing it is coming — not so you can switch it on this afternoon. Do not plan a release around it as if it were live.

What is live is the read on a finished model: bring a finetune to Audit and Protora reads what it became, with a witness on every finding. Drift Guard extends that same read backward into the run itself. When it launches it will carry the same honest limits the finished-model read already states: assurance against drift and accidental or planted misalignment, backed by a provenance record, held to a stated coverage, making no claim to catch every backdoor, and confined to open-weight, self-hosted training you can actually read. Track it on the Drift Guard page; the roadmap moves the guard from staged to live, and this entry will say so when it does.