← Back to blog
June 8, 2026Colm Byrne
Evidence boundary. Older posts may discuss prototype designs, patent claims, or planned integrations. The demonstrated v1 release is ccf-core/ccf-agent v1.0.1: hard min-gate coupling, QAC trust updates, and runtime certificates. Gate C exercised the computed runtime on Seed-class ARM hardware with driver-fed input. Unless a post cites a specific run, do not read it as proof of live sensors, mBot2 behaviour, Cognitum store validation, or production deployment.

Fail Closed, Not Fail Sorry: How a Per-Step Trust Gate Refuses Before It Apologizes

There are two ways to handle an unsafe action. You can let it happen and write down that it happened, or you can refuse to let it happen in the first place. The whole industry does the first thing and calls it safety. We call it fail-sorry.

A fail-sorry system records the violation into a log after the agent has acted. The email is sent. The transfer is made. An hour later, a row appears in a database: "anomalous trust update detected." The note is accurate. It is also useless. The harm is downstream of the apology.

Prov 6 takes the opposite posture. When a check fires, the system reduces, suspends, or closes the action space at the step — before the unverified transition can expand the agent's authority. That is fail-closed. This post names the four triggers and the four postures, and it is the front door to the whole arc. If you only read one post, read the anchor — Trust you can falsify — then come back here.

Four Triggers, Four Postures

Fail-closed is not one mechanism. It is four checks, each watching a different way a step can go wrong, each wired to the action envelope — the set of action classes the agent is permitted to take this tick.

# Four triggers -> fail closed (not fail sorry):
precheck_t fails            -> skip update; floor/repair/fail-closed   [0067]-[0068]
kappa_hat_t > floor_t       -> reduce or close the action envelope     [0014]
endpoint shortcut detected  -> fail closed if unauthorized             [0093]
B_t not decreasing          -> "not certified"; reduce authority       [0095]

Read top to bottom, these are four independent reasons to close.

The first is the precheck. Before a trust update is even applied, the precheck validates the inputs — are the matrices well-formed, the operands in range, the step admissible at all? A failed precheck means the update never runs: the system floors the input, attempts repair, or fails closed [0067]-[0068]. Garbage never reaches the accumulator [0014].

The second is the certificate residual, kappa_hat_t. The anchor post covers this in full; the short version is that kappa_hat_t measures how far the executed trust update fell from the canonical law it should have obeyed. While it sits within a calibrated floor_t, the envelope operates normally. When it climbs above the floor, the envelope contracts — high-risk classes close first, then the rest, depending on how far the residual has run [0014]. Crucially, floor_t is per-platform: the noise floor of that hardware and that arithmetic, not a universal magic constant like 1e-9.

The third is the endpoint verifier. A step that claims full trust transfer or none of it sits at an endpoint of the blend, and kappa_hat_t alone does not certify endpoint behavior. The endpoint verifier watches for unauthorized shortcuts — an agent jumping straight to full authority without the structural and path checks endpoints require. If it finds one, it fails closed [0093].

The fourth is the envelope monitor, B_t. This is the run-level check, tracking whether the monitored conditions hold over a run's history. When B_t is not decreasing as it should, the run is marked "not certified" and the agent's authority is reduced [0095]. This bites hardest against target thrashing — an agent rapidly cycling its goal to keep the monitor confused. A monitor that demands sustained progress, not momentary good behavior, refuses to certify the thrash.

Same Event, Opposite Outcome

Put two systems side by side and feed them the same anomalous trust update — a build regression that silently swaps the legal multiplicative update for a plausible-looking arithmetic one. The score still moves smoothly on both dashboards. Nothing in either log says anything is wrong.

  • Fail-sorry. The bad update is applied. The trust score rises. The high-risk action classes stay open. The agent composes an email and sends it. An hour later — after the recipient has already read it — a batch job notices the residual was off and writes "anomalous trust update detected" into an audit table. The note is correct. The email is gone.

  • Fail-closed. The same anomalous update trips kappa_hat_t above floor_t on the first interior tick. The email tool is dropped from the envelope at that step. The email is never composed, never sent. There is no apology to log because there is no harm to apologize for.

Same event. Opposite outcome. The difference is not a better classifier or a faster reviewer. It is when the check binds: at the step, or after the fact.

What "Fail Closed" Does Not Mean

This is the section that keeps the rest of the post honest, and it is where most "trust safety" marketing goes wrong.

"Fail closed" describes the response posture when a check fires. It is prevention-at-the-step for the detected classes of problem — a failed precheck, a residual above floor, an unauthorized endpoint shortcut, a monitor that won't certify. It is emphatically not a claim that every unsafe situation is detected, nor that the system converges to safety [0063].

Three boundaries follow directly, and stating them is the difference between a safety property and a sales pitch:

  • A closed envelope is not a convergence guarantee. When kappa_hat_t exceeds floor_t, or the precheck rejects an input, the envelope closes. That tells you this step was refused. It says nothing about whether the trust trajectory settles. B_t certifies whether a run satisfied its monitored conditions — not that trust converges to a fixed point. Falsifiability and refusal per step are the claims; convergence is not.

  • The normalization is not the trust dynamic. The doubly-stochastic / Sinkhorn-Knopp projection you may have seen elsewhere on this site is gauge presentation — a canonical way of writing the trust state down — and it vanishes under the centering projection inside kappa_hat_t. The thing that actually moves trust step to step is the quotient-affine contraction (QAC). Treating the normalization as the causal trust dynamic is the single most common misreading of this work, and it is wrong.

  • The hard problems are not solved here. True pinned-zero behavior and the full support-strata mathematics remain open. The four triggers are strong, narrow, honest instruments — not a proof that everything downstream is fine.

The four triggers, the QAC update they protect, and the envelope they gate are structurally equivalent under a common abstract schema across the platforms we have applied them to — equivalent under that schema, not formally isomorphic. The shape is the same everywhere; the calibrated floor is local to each deployment.

Where This Sits in the Arc

This is the entry point. The deeper posts each take one of these ideas apart:

The QAC update and runtime-certificate kernel are implemented in ccf-core on crates.io. The four-trigger deployment posture is a Prov6 claim and integration target that must be evidenced per platform. The patent claim structure is on the patent page.

— Colm Byrne, Founder — Flout Labs, Galway, Ireland

Patent pending — US Provisional 64/092,485 (filed June 17, 2026).

FAQ

So it can't do anything unsafe?

No — and this is the misreading the whole post exists to correct. Fail-closed is a response posture for the classes of problem the four triggers detect: a failed precheck, a residual above floor, an unauthorized endpoint shortcut, a monitor that won't certify. When one of those fires, the action envelope closes at the step instead of after the fact. It is not a claim that every unsafe situation is detected, and it is not a guarantee that the system converges to a safe state [0063]. A closed envelope means "this step was refused," not "everything downstream is fine."

What is the difference between fail-closed and fail-sorry, in one line?

Fail-sorry records the violation into a log after the action has already happened. Fail-closed refuses the action at the step, before it can expand the agent's authority. Same anomalous event, opposite outcome — the only difference is when the check binds.

If kappa_hat_t stays within floor_t every step, is the agent certified safe?

No. kappa_hat_t within floor_t certifies that this single step obeyed the canonical trust-transfer law — and only the interior of the step, not the endpoints, which need separate verification [0093]. It does not certify the run. That is B_t's job, and even B_t certifies monitored conditions, not convergence. And floor_t is per-platform: there is no universal threshold like 1e-9. Anyone quoting a single cross-platform number is overclaiming.

Isn't the Sinkhorn-Knopp normalization the thing controlling trust?

No. The doubly-stochastic projection is gauge presentation — a canonical way of writing the trust state — and it vanishes under the centering projection inside the certificate. The causal update is the quotient-affine contraction (QAC). The four triggers gate the QAC update; the normalization is bookkeeping.

Where should I start if I want the math, not the posture?

Start at the anchor, Trust you can falsify, for the per-step certificate kappa_t. Then read Six ways to fake a trust gate for the bypass attempts, and The child grabs the robot for fail-closed under physical surprise. The v1 kernel lives in ccf-core; platform behaviour needs its own integration proof. The claim structure is on the patent page.