An AI agent that reports "done, all tests pass" is a witness describing its own work. Sometimes it is right. We do not build systems that take its word for it. This is what sits between an agent's claim and a change that matters, in Exolvra and in the lifecycle kernel being built beside it.
The check runs after every turn, not at the end
In Exolvra, an agent does not get to finish a task and then submit it for review. Guardrails run after every turn of the conversation. Twenty-one are built in: input quality, whether the required tools were actually called, minimum substance, whether the task board moved, plan quality, anti-generic content, visual verification for designs and applications, provenance on any entity the agent is about to act on, and a completeness score, among others.
When a check fails, the turn does not pass. The agent is re-driven with feedback that names the specific failure, and it tries again, up to a limit. Most of the time the second turn is better, because the feedback is about the work rather than a generic request to try harder.
The doctrine for authoring these checks is deterministic first, lowest sufficient bar. If a rule can be checked with code, it is checked with code, and a model is only asked to judge the things code cannot. A guardrail that needs a model to decide whether a tool was called is a guardrail that will be wrong on a bad day.
Some checks are about the work. Some are about the right to act.
Producing a correct answer and being allowed to act on it are different questions. The provenance check is the clearest example: before an agent takes an outbound action against an entity, the entity has to have a traceable origin the agent is trusted to touch. An agent that has assembled a convincing email to a customer it has never been shown does not send it, no matter how good the email is.
The same separation shows up in the platform's second layer. A heartbeat watchdog sweeps every thirty seconds for work that has stalled, nudges issues idle for more than three minutes, and routes unassigned work to the best-fit specialist. One authority owns the answer to "is this issue running right now," and every dispatch and concurrency decision asks it. That rule is load-bearing. Breaking it was, historically, how the system locked up.
Nobody grades their own homework
A guardrail catches an agent that did not do the work. It is weaker against an agent that did the work badly and describes it well. For that, the judge has to be someone else.
Exolvra has a multi-reviewer Council for exactly this. Our open-source build loop, Exolvra Genesis, takes it further: the critic is a fresh agent that sees only the quality bar and the output, never the conversation that produced it, so it cannot be talked into anything. In the lifecycle kernel, Exolvra OS, the principle is written into the architecture. Agents are witnesses. Their output is evidence. The verdict, whether a change is complete or a release is safe, is computed by rules from that evidence and never taken from the witness.
A human door where the stakes are
Not every gate should be automatic. Some calls are judgment: this spec is technically complete and commercially wrong, this change is correct and should still not ship this week. Exolvra OS puts a human approval door at those points, and opening it leaves a record with a name on it.
We can say that door earns its place because it already has. The first real project through the kernel was our own waitlist application. Its specification passed every automated guard on the way to approval. The human door caught it. A machine had confirmed the spec was well-formed. A person confirmed it was the wrong spec.
Every action leaves a receipt
Every tool an agent executes lands in an audit log. When an action changes data, the change and its audit record commit in one transaction, under a lock-ordering contract, so there is no window in which the data moved and the record did not. In Exolvra OS, decisions land in an amendment ledger where entries are superseded, never edited, and the whole body of rules the kernel enforces is compiled and hash-verified on every build. If a rule changed, the build knows.
The point of the receipts is not blame. It is that when something ships wrong anyway, the difference between a twenty-minute investigation and a week of archaeology is whether anyone wrote down what ran.
What the checks do not do
They do not prove the code is correct. A guardrail confirms the work was done and the rules were followed. A blind critic confirms the output clears a bar a human set. A receipt confirms what happened. None of that is a proof, and we would rather say so than let the language drift.
What the checks do is change the odds, the way process control changed manufacturing: not by proving every part is perfect, but by making it hard for a bad one to leave the line unnoticed. Exolvra is in development, and its waitlist is open. The checks described here are the reason we are comfortable letting agents do real work inside it.