← Back to blog
September 6, 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.

Forty green ticks and a fleet that would not settle

A real moment

Maeve Kilbride runs the night shift at a parcel hub outside Portlaoise. Forty autonomous tugs pull cages between the inbound docks and the sort lines. None of them came out of the box with authority. Each one keeps its own trust state, a record of how much it may do, in which zone, at what speed, built up over weeks of clean runs and knocked back by every bump and every near miss.

Twice a minute the fleet controller hands every tug a reference profile for the zone it is in. The tug does not jump to it. It moves part of the way, and how big a part depends on how stable its own sensors look right now. A tug with a flickering lidar takes a smaller step than a tug with a clean one. That step is checked every time: was it the right shape? Did the tug move along the path the rules say it should, and by no more than it was allowed? If yes, the check passes and the tick on Maeve's screen stays green.

At 01:40 a second controller replica comes back from maintenance. It still has last week's zone plan loaded. The two replicas now take turns answering. Thirty-one tugs get this week's plan, then last week's, then this week's again, every cycle. Each tug does the right thing with what it is given. Every step is the right shape. Every check passes.

Here is what Maeve's screen shows without the second number. Forty tugs, forty green ticks. Nothing is wrong with any single step, so nothing is flagged. On the floor, the tugs near dock 7 are told to slow for a zone that was reclassified on Tuesday, then told the old limit applies, then the new one. A forklift driver sees tugs hesitate, move off, hesitate again. He mentions it at the 03:00 break. Nobody has been paged. The dashboard has been telling the truth about each step and lying about the night.

Here is what the screen shows with it. Within about fifty cycles a second number on thirty-one tugs stops falling and sits at a plateau. The screen does not say failed. It says not certified. The fleet monitor stops counting those tugs' trust updates toward anything and pages Maeve. She opens the packet on one tug and then on the rest. All thirty-one look the same: step check inside its floor, reference motion nonzero and identical, envelope at one plateau. The nine tugs on the healthy replica show zero reference motion. That pattern says controller, not tug. She takes the second replica out of the rotation. Twenty cycles later the number has fallen back to where it rests.

I should say what is and is not real here. There are no tugs in the code. The Rust proof of concept behind this post simulates the trust state, the reference it is pulled toward, and the two numbers. The story is what those two numbers would say on a screen, and what a screen with only one of them would fail to say.

Why this matters

Every serious autonomy stack now has some kind of runtime check. A certificate, a monitor, a receipt. The good ones check something concrete about each decision: was this step within policy, was this action inside the envelope the system was allowed. That is the right instinct and I am not arguing against it.

The problem is what a per-step check cannot see by construction. A check on the shape of a step is a check on that step. It has no opinion about the thing the step was aimed at. If the target holds still, a run of correct steps gets you there and the check's silence means what you think it means. If the target keeps moving, a run of correct steps can leave you exactly where you started, and the check is just as silent.

That is not a bug in the check. It is the blind spot of any check that only looks at what the agent did and not at what it was told to do. And target motion is the normal case in a fleet. Plans get republished. Supervisors change their minds. Two replicas disagree. A policy service flaps. Every one of those looks like a sequence of perfectly good steps to a per-step certificate.

Most monitoring answers this with thresholds on the raw state, or with a human looking at a chart. Both work until the night they do not. What you want is a second number, computed from the same tick, that charges for target motion the same way it charges for a wrong step, and that a fleet monitor can read without any of the raw sensor data.

What CCF does about it

CCF's filed runtime certificate (Prov6, US 64/092,485) already has the per-step check. Each tick, the agent moves from its trust state toward the reference along one specific path, by a step size the hard minimum gate sets from the current ceilings. The certificate measures how far the executed step departed from that path. Inside a small floor set by the platform's arithmetic, it passes. Outside, it fails closed.

The envelope is the second number in the same filing. In plain terms it is a ceiling on how far the agent could be from its target right now. Each tick it shrinks by the step size. Then it grows by two things: how far the reference moved since the last tick, and how wrong the last step was. Still target and correct steps, and it falls to almost nothing. Moving target, and it stops falling at a level equal to the target's motion divided by the step size, no matter how correct each step is.

Two things follow that matter on a screen. First, the envelope never says the agent is closer than it is. That is a bound, and the proof of concept tests it on every tick of every run. Second, it can say the agent is further than it is, and it does so most when the target keeps reversing and when the agent has the least authority. That is a feature, in the sense that a low-authority unit should have little tolerance for a target that will not hold still. It is also a number an operator will misread unless the screen shows the factor next to it.

The two checks have disjoint blind spots, and this run measured both. A wrong update rule, arithmetic interpolation instead of the filed path, is caught by the certificate on every tick against a moving target. Against a still target it is caught for 28 ticks and then goes quiet, because the wrong rule converges to the same place as the right one and there is nothing left to get wrong. The envelope does not see the wrong rule at all in that case, because the gap is small. Meanwhile a thrashing target under the correct rule produced zero certificate failures in 4,800 ticks and a plateau in the envelope every time. A fleet packet with only one of the two columns misreads two of the six units in the demo.

The numbers

The certificate stayed silent through 4,800 ticks of target thrashing across twelve amplitude and period settings. The envelope plateaued at the target's motion divided by the step size in every one of them, to four decimals. With a window of eight ticks, the trend policy flagged the plateau at tick 51.

Against a target that reverses every tick, the real gap settles at the motion divided by two minus the step size. The envelope settles at the motion divided by the step size. The ratio between them is two minus the step size, all over the step size: 4.0 at full authority, 8.5 at half, 33.5 at a stalled gate. That is the overstatement an operator needs to see.

Cost: the envelope recurrence itself is 3.9 nanoseconds. Feeding it takes two distance computations at about 240 nanoseconds each. The whole tick, including the filed step and the certificate, is 1.6 microseconds on an i5-10400T. The packet a fleet monitor receives is 88 bytes.

What this doesn't solve

The envelope bounds the gap. It does not make the gap small. Nothing in this run says the agent converges, and the filing does not say that either.

The certificate is blind to a wrong update rule that has already converged on a still target. This run measures that blindness and does not fix it.

Two of the three policies I tried, a fixed budget and a floor-relative ceiling, flag on tick one because the starting gap is large. They need a settled-state guard before they mean anything. The trend policy does not have that problem but will call a steady drift "not certified" forever, because a plateau is literally a failure to decrease. Whether you want that is a deployment choice.

Any change in the gate spikes the floor for one tick, and the envelope with it. A tight budget will see that as an excursion.

And run the implementable form, the one that adds the floor each tick. The exact form as written violates its own bound by a few parts in ten to the seventeenth once everything is down at the rounding floor. Small, but a bound that is violated is not a bound.

For the curious: the math

Skip this if you do not want it. The quotient distance between two trust states is the Frobenius norm of the double-centered difference of their logs, so gauge factors drop out. Write E_t for the distance from state to reference and delta_t for the distance the reference moved between ticks. The filed step is affine in the log chart, so the distance from the correct next state to the old reference is exactly (1 - alpha_t) E_t. The certificate kappa_hat_t is by definition the distance from the executed next state to the correct one. The triangle inequality then gives

E_{t+1} <= kappa_hat_t + (1 - alpha_t) E_t + delta_t

and the envelope B_{t+1} = (1 - alpha_t) B_t + delta_t + kappa_hat_t with B_0 = E_0 bounds E_t by induction. In f64 that held to 2.5e-17. The implementable form adds floor_t and held exactly.

For a target alternating between two classes d apart every tick, the state falls into a two-cycle with E = d / (2 - alpha) and the envelope rests at d / alpha. Measured ratio (2 - alpha) / alpha at all nine sweep points. The full tables, the crate and the tests are in the research doc linked below.

Where this fits

This is one night's run in an ongoing series that takes each part of the filed CCF architecture, builds it in Rust on the published ccf-core crate, and measures it. Earlier runs did the finite-precision floor for the certificate and the moral-constraint gate for vehicles. This one does the envelope, and it is the first to put a number on how conservative the envelope is and when.

  • Research doc and crate: docs2/research/nightly/2026-09-06-runtime-trust-envelope-monitor/ on https://github.com/Hulupeep/ccf
  • Published core crate: https://crates.io/crates/ccf-core
  • Causation-trail lineage: https://github.com/Hulupeep/Specflow
  • Filing: Prov6, US 64/092,485, paragraphs [0014], [0061] to [0063], [0084], [0095]
  • Company: https://floutlabs.com

License & contact

Code is BSL 1.1, converting to Apache 2.0 in 2032. Contact via https://floutlabs.com.