Fail-closed governed autonomy

The trap in "human in the loop"

The common answer to agent safety is a human in the loop: let the model do what it wants, but have a person approve each action. It feels safe, and for low volumes it can be. But it does not scale, and worse, it quietly degrades. A person asked to approve the two-hundredth routine action of the day approves it without reading it. The loop is still there on the org chart and gone in practice. Safety that depends on sustained human attention is safety with a half-life.

The deeper issue is that "human in the loop" puts the human in the wrong place. It asks them to be the safety mechanism, catching bad actions one at a time, forever. What you actually want is for the unsafe action to be impossible to take in the first place, with the human setting the rules rather than serving as the last line of a rubber stamp.

Propose and dispose: a hard line

Fibric draws a structural line through the middle of every action. On one side, the language model proposes: it reasons over the operational picture and produces a validated plan, a structured description of what it wants to do. On the other side, a deterministic executor disposes: it is the only thing that can turn a proposal into a real action, and it does so only if the proposal passes every check.

This is not a stylistic choice. The model is powerful and non-deterministic; you cannot prove what it will say next. The executor is narrow and deterministic; you can prove exactly what it will and will not do. By making the executor the sole path to a real effect, the unpredictable part of the system is structurally unable to act on its own. It can only ask.

Fail-closed, not fail-open

The word that does the most work here is fail-closed. A fail-open system, when something is unclear, a check times out, a policy is ambiguous, a signal is missing, proceeds anyway. A fail-closed system stops. On Fibric, the absence of a clear, affirmative "this is allowed" is treated as "this is not allowed." Uncertainty resolves toward inaction, never toward action.

This is the same principle that governs a safe deadbolt or a circuit breaker: when in doubt, deny. It costs you something, an action that was actually fine will sometimes be held because the system could not confirm it was fine. We think that trade is correct for a system acting on the physical world, where the cost of a wrong action is almost always higher than the cost of a held one. You can always review and release a held action. You cannot un-send a message.

Policy as a veto you own

The policies that gate the executor are yours to set, and they are deterministic. A policy is not a suggestion the model might weigh; it is a hard check the executor runs, and any policy that does not pass fails the plan. "Never message a customer outside business hours." "Never place a hold above this value without confirmation." "Never act on data tagged as a fallback." These are not prompts. They are rules, evaluated outside the model, that the model cannot talk its way around.

This matters because it makes governance independent of the model's behavior. You do not have to trust that the model learned your rules or that a clever input will not jailbreak them. The rules live in the deterministic layer. Even a perfectly adversarial proposal hits the same wall as an honest one.

What governance gives back: the receipt

Because every action passes through one deterministic gate, every action produces one consistent record. The receipt shows the proposal, the policies it was checked against, the decision, and the effect, or the veto. This is the practical payoff of the architecture: autonomy you can audit after the fact, not just authorize before it. When a person does want to look, the answer to "why did it do that" is always there, and so is the answer to "why did it refuse."

The honest limit

Fail-closed governed autonomy does not make the model correct. It makes the model contained. A flawed proposal that nonetheless satisfies every policy will still execute, which is why the grounding work in our other notes, real-data-only inputs and verified root cause, matters just as much. Governance bounds what can happen; grounding improves what is proposed in the first place. You need both. What this architecture guarantees is narrower and, we think, more important: nothing your policy forbids will ever happen, no matter what the model wants.

Related: Point and go · Neuro-symbolic root-cause