Permits, not promises: what an assurance kernel does

An assurance kernel is a small piece of software whose only job is to grant, or refuse, permission for an action to execute. It does not plan. It does not perceive. It does not decide what the mission should do next. It takes a proposed action, the current mission state, the current intent, and the applicable constraints, and it returns a permit or a refusal, with a reason attached to either.

That is the whole thing. The mechanism is small on purpose. Its correctness is a matter of proofs and reviews, and small mechanisms are the ones that survive those reviews. Everything else, planners, science algorithms, learned perception, adaptation, sits in front of the kernel, proposing. The kernel is behind them, permitting.

This essay describes what such a kernel actually does, why it is separate from the planners, and what the deterministic record of its decisions gives an accident board.

What a permit is

A permit is a signed record that a specific action, in a specific state, with a specific set of applicable constraints and beliefs, has been evaluated and found acceptable. It carries:

• The proposed action, expressed in the runtime's action vocabulary.
• The mission state and belief snapshot at the moment of evaluation.
• The intent artifact in force at that moment.
• The set of constraints that were checked, and their outcomes.
• The kernel's signature and a monotonic sequence number.

A permit is not permission to do something similar later. It is permission to do that specific thing now. If the vehicle's state changes, the next action requires a new permit. This is not a performance problem in practice; the kernel is fast because it is small, and the vast majority of permits are trivial to grant.

What the kernel actually checks

The check is not one thing. It is a specific sequence, in a specific order, because ordering has consequences for what refusals mean:

1. Authority. Is the proposed action consistent with the current intent artifact? Prohibitions come first: an action inside a prohibited class is refused before anything else is evaluated. This is not the place to be clever.
2. Feasibility. Do the physical constraints of the vehicle, power, thermal, propellant, communication, time, permit the action given the current belief about them?
3. Safety envelopes. Do the pre-computed safety envelopes for the vehicle's current mode allow the action? Envelopes are typically drawn on the ground and updated only through the authority path.
4. Operating-domain contracts. If the action was proposed by a component with an operating-domain contract, a learned classifier, an adaptive controller, is the current belief inside that component's qualified domain?
5. Coordination. Are outstanding coordination contracts with other vehicles compatible with the action?

Any refusal short-circuits the rest. Every check writes its outcome to the record whether or not it was reached, which turns out to be crucial for the review process. An accident board wants to know not only why a permit was refused, but which checks it never got to.

Why the kernel is independent

The kernel is not part of the planner. It is not part of the perception stack. It is not co-located with them, not written by the same team, and not verified together. This is deliberate.

The reason is that a mechanism which grants permission cannot inherit trust from the mechanism it is checking. If the same code path proposes and permits, a bug in the proposer that produces a bad action also produces a bad permit for that action. The kernel exists so that a bug in a proposer does not extend into a bug in the trust boundary.

This is a very old idea. It is why fire control on a warship is separate from navigation. It is why a reactor's safety instrumentation is on separate wiring from the control system. It is why aviation split flight envelope protection from primary flight control. The novelty here is not the pattern; the novelty is applying it to autonomy.

Standards, as design targets

The kernel is designed against DO-178C at Design Assurance Level A for its safety-critical path, NPR 7150.2 Class A software processes, and ECSS-E-ST-40C for European partners. These are not marketing badges. They are the shape a small, separately verified mechanism has to take to pass the reviews the industry actually runs.

Design targets, not achievement claims. We say what we are aiming at and what remains to be done. When the kernel has been audited to those standards on a specific target, it will say so, on a specific page, with a specific auditor, and with the artifacts available for review.

Deterministic replay

A kernel that only grants permits does not, by itself, help an accident board. A kernel that records every decision, in a form that can be replayed exactly, does.

The property is: given the record of inputs the kernel received and the version of the kernel that was running, the same permits and refusals can be reproduced bit for bit. This lets the board answer the specific question they always want to ask, which is not "was the autonomy good?" but "given what the vehicle believed at that moment, was the decision correct?"

Determinism is not free. It requires that the belief state be captured with sufficient fidelity, that timing be recorded, that the kernel's own state, including any tunable parameters, be part of the record, and that the runtime run without hidden nondeterministic sources. It is engineering work, not magic. The technique is borrowed from deterministic simulation platforms and adapted to real vehicles, where determinism at the record level is possible even when the physical world is not.

The Antithesis engineering essays on deterministic hypervisors are a good outside reference for the flavor of the technique. The mission software version is different in detail, but the discipline is the same.

What this buys, concretely

Four things, in order of how often they matter:

Reviewability. A permit and its record are what a design review can inspect. The reviewer does not have to trust that a learned component behaved; they can see what the kernel checked and why it granted.

Composability. Because the kernel checks contracts, not particular components, a new proposer can be added to the runtime without changing the kernel. If the new proposer's contract is well-formed, it inherits the same trust properties everything else has.

Accident survivability. When something goes wrong, the record is what remains. It is more useful, in every case, than a post-hoc reconstruction from telemetry, because the state that produced the decision is part of the record.

Certification. A small, separately verified kernel is the mechanism that makes a large autonomy stack certifiable. The certification does not have to reach into every learned model. It has to reach into the kernel and into the contracts.

What the kernel is not

It is not a filter that catches bad behavior after the fact. It is not a classifier trained on examples of unsafe plans. It is not a large model asked to check the output of a smaller one. It is not clever. It is small, and separate, and boring, and it is where the trust boundary lives.

If the field takes one thing from the current wave of "AI safety" language and applies it to mission autonomy, it should be this: assurance is a property of the mechanism that grants execution, not a property of the mechanisms that propose it. Permits, not promises.

Barycenter Systems is building a mission autonomy runtime. If this problem is yours too, write to us.