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.Trust You Can Falsify: A Per-Step Certificate for Safe Autonomy
Most "AI trust" systems give you two things: a score and a story. The score is a number that moves smoothly up and down. The story is the explanation the system tells about why the number moved. Both are assertions. Neither can be wrong in a way you can detect. And an assertion that cannot be checked is not a safety property. It is a hope.
Prov 6 takes the opposite stance. Instead of asserting that a trust update was correct, it produces a certificate you can falsify at every step. The instrument is a single residual, kappa_t, computed each tick. When kappa_t sits within a calibrated floor, that step provably obeyed the canonical trust-transfer law. When it climbs above the floor, the executed update departed from the law -- and the system can prove it, measure it, and respond [0006].
This is the bar for safe autonomy that the rest of this arc builds on. A system that can be proven wrong every tick is safer than one that merely claims to be right. Every other post in this series links back here.
Assertion Versus Falsification
Consider a companion robot whose trust state updates every tick. Suppose a build regression silently swaps the canonical multiplicative trust update for a plausible-looking arithmetic interpolation. The two are nearly indistinguishable on a dashboard. The trust score still rises and falls smoothly. Nothing in the logs says anything is wrong, and a score-and-story system has no way to catch it -- the regression hides inside both the moving number and the narrative that explains it.
A falsification instrument behaves differently. It does not ask "is the score reasonable?" It asks "did this exact step obey the law that defines a legal trust update?" That question has a measurable answer. The arithmetic interpolation does not obey the canonical law, so the residual goes positive on the first interior step -- before any human notices the dashboard looks fine [0011]. An assertion is wrong in ways you cannot see. A falsification instrument is wrong in ways you can measure.
The Certificate: kappa_t
The canonical trust-transfer law is multiplicative in the trust state. The next-step trust matrix A_{t+1} should be a geometric blend, weight alpha_t, of the prior state A_t and the incoming evidence R_t. The certificate measures how far the executed update fell from that ideal:
kappa_t = || H( log A_{t+1} - (1 - alpha_t) log A_t - alpha_t log R_t ) H ||_F
# zero within floor_t <=> executed update obeyed the canonical trust-transfer law
# above floor_t => reduce / suspend / close the action envelope
Read it term by term. We take the matrix logarithm of each trust matrix, so a multiplicative law becomes an additive one. The bracketed quantity is the difference between what the system did (log A_{t+1}) and the geometric blend it should have done. If the update obeyed the law, that difference is the zero matrix. The H(...)H projection -- a centering that removes the gauge degrees of freedom -- strips out the parts of the representation that carry no causal trust content. Then || . ||_F is the Frobenius norm: a single non-negative number. So kappa_t is a residual against the canonical update form. Zero (within the floor) means this step was legal; positive means it was not, and the magnitude tells you how badly.
Two things about kappa_t = 0 matter, and the truthfulness of this whole architecture depends on stating them. First, floor_t is not a universal magic constant. It is a per-platform, per-deployment calibrated value -- the noise floor of that hardware, that arithmetic, that sensor stack. There is no single threshold that works everywhere. Second, the certificate certifies the interior of a step. Endpoint behavior -- a step that claims full trust transfer (alpha_t = 1) or none (alpha_t = 0) -- needs additional structural and path verification; kappa_t alone does not certify the endpoints [0012].
The Action Envelope Consequence
A certificate is only useful if something acts on it. In Prov 6, kappa_t is wired directly to the action envelope -- the set of action classes the agent is permitted to take this tick. While kappa_t stays within floor_t, the envelope operates normally. The moment it exceeds the floor, the envelope contracts: high-risk action classes close first, then the system reduces, suspends, or closes the envelope entirely depending on how far the residual has run [0133].
Back to the silent-regression robot. With a score-and-story system, the arithmetic-interpolation bug ships, the trust score keeps rising smoothly, and the high-risk action classes stay open the whole time -- the failure is invisible until something goes wrong downstream. With the certificate in place, kappa_t goes positive above floor_t on the first interior tick after the bad build, and the high-risk classes close immediately. Same bug, same smooth-looking score -- but one architecture catches it on the first step and the other never catches it at all.
That is the safety claim, stated precisely. Not "the trust score is correct." Rather: "every trust update is checkable, and an illegal one closes the dangerous actions before it can be used."
What the Certificate Does Not Claim
This is the most important section, and it is where most "trust math" goes wrong.
kappa_t = 0 means this step obeyed the law. It does not mean the system will converge. It does not mean the robot now trusts the user. It does not mean the relationship is "safe" in any global sense. Prov 6 explicitly disclaims unconditional convergence. There is a separate envelope monitor, B_t, whose job is to certify whether a given run satisfied the monitored conditions over its history -- and even B_t does not promise that trust converges to a fixed point. Falsifiability per step is the claim. Convergence is not [0012], [0133].
Two further clarifications keep this honest. The certificate's normalization machinery -- the doubly-stochastic projection from the Sinkhorn-Knopp post -- is gauge presentation, not the causal dynamic. It is a way of writing the trust state in a canonical frame, and it vanishes under the H(.)H projection inside kappa_t. The thing that actually moves trust from step to step is the quotient-affine contraction (QAC), the multiplicative law kappa_t checks against. Confusing the normalization with the trust dynamic is the single most common misreading of this work, and it is wrong. The companion post The normalization is not the trust takes that confusion apart in full.
Finally, the harder problems are not solved here and we do not pretend they are. True pinned-zero behavior and the full support-strata mathematics remain open. The certificate is a per-step falsifier -- a strong, narrow, honest instrument, not a proof that everything downstream is fine. The QAC update and the line it draws between what kappa_t proves and what it merely monitors are structurally equivalent under a common abstract schema across the platforms we have applied it to -- equivalent under that schema, not formally isomorphic. The certificate is the same shape everywhere; the calibrated floor is local to each deployment.
Why a Certificate Beats an Explanation
The deeper reason to prefer falsification is captured in the sibling post A certificate, not an explanation. An explanation is a narrative the system produces about itself; you cannot independently verify it without trusting the narrator. A certificate is an artifact a third party can check without trusting the system that produced it: you recompute kappa_t from the logged matrices and compare against the floor. If the system lied about a step, the recomputation catches it.
This also clarifies why per-step falsification is not the same as the distance-contraction arguments trust systems often lean on. Contraction tells you successive states get closer together; it says nothing about whether each individual update obeyed the law. As Distance contraction is not enough argues, a sequence can contract toward a fixed point while every single step along the way is illegal. The certificate checks the step, not the trend.
The certificate computation, QAC update, and run monitor are implemented in ccf-core on crates.io. Demonstrations that apply those primitives to robots, fleets, or language models still need their own integration evidence. 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
Does kappa_t = 0 prove the robot will eventually trust me, or that the relationship is safe?
No, and this is the misreading the architecture exists to prevent. kappa_t = 0 (within the calibrated floor) certifies exactly one thing: that this single step obeyed the canonical trust-transfer law. It says nothing about where the trajectory is heading. Prov 6 explicitly disclaims unconditional convergence; a run can have every step legal and still never settle to a fixed point. The separate monitor B_t certifies whether a run satisfied its monitored conditions -- but even that does not promise convergence. "The robot will trust you" and "the relationship is safe globally" are not claims this instrument makes.
Is the doubly-stochastic / Sinkhorn-Knopp normalization the thing that actually controls trust?
No. The normalization is gauge presentation -- a canonical way of writing the trust state down -- and it vanishes under the H(.)H projection inside kappa_t. The causal update, the law that actually moves trust from one step to the next, is the quotient-affine contraction (QAC). Treating the normalization as the trust dynamic is the most common error people make reading this work. The certificate checks the QAC update; the normalization is bookkeeping.
What is floor_t, and is there a universal threshold like 1e-9?
There is no universal threshold. floor_t is a per-platform, per-deployment calibrated value: the noise floor of the specific hardware, arithmetic precision, and sensor stack a system runs on. A residual that is "zero" on one platform may be above the floor on another with cleaner arithmetic. Calibrating floor_t honestly for each deployment is part of using the certificate correctly. Anyone quoting a single fixed cross-platform number is overclaiming.
If kappa_t is within the floor every step, does that certify the endpoints too?
No. The certificate covers the interior of an update. A step that claims full transfer (alpha_t = 1) or no transfer (alpha_t = 0) sits at an endpoint of the blend, and those cases require additional structural and path verification. kappa_t staying small does not by itself certify endpoint behavior. The per-step residual and the endpoint checks are different tools.
How is this different from a trust score with good logging?
A score with logging is still an assertion: the number moved, the log explains the move, and you trust both. A regression that swaps the legal update for a plausible illegal one keeps the score smooth and the log clean. The certificate is an independently checkable artifact -- recompute kappa_t from the logged matrices, compare against the floor. An illegal step produces a positive residual you can measure, and it closes the high-risk action classes before the bad update is used. Falsifiable beats explainable.