The Child Grabs the Robot: Real-Time Envelope Contraction in a Social Robot

Editor's note — June 2026 (post-ccf-core v1 correction). This post describes the intended robot integration path and the Prov6 per-tick certificate logic. The public v1 evidence is narrower: ccf-core and ccf-agent v1.0.1 compute the trust-update and runtime-certificate primitives, and Gate C exercised that computed runtime on Seed-class ARM hardware with driver-fed input. It does not claim a completed mBot2 grab demo, live sensor ingestion, or live device-store validation.

Here is the moment. The robot is on the kitchen floor, mid-interaction, at moderate trust. It has been here a while. Coherence has accumulated. It is moving a little, glowing a warm colour, allowing itself some expressiveness — nothing dramatic, but the envelope is open enough to be social.

Then a child grabs it. Two small hands close around the chassis and lift.

What should happen next? Not "the robot decides the child is dangerous." Not "the robot understands it is being grabbed." Something far more boring and far more trustworthy: the world just got less predictable, so the robot gets more careful, immediately, before it does anything else. This post traces that single moment tick by tick, through the math the v1 core now implements at the trust-update and certificate layer.

The sensors that see the grab

Ground this in what the robot actually has. The social-robot embodiment in the patent specifies a concrete sensor set — motion, light, sound, proximity, impact, battery, and sensor integrity (US 64/092,485 [0079]). These are cheap, embedded readings. No camera understanding the scene. No model inferring intent.

When the child grabs and lifts, several of these move at once:

• Impact spikes — the chassis is squeezed and jostled.
• Proximity collapses to near-zero — something is right up against the body.
• Motion goes erratic — the robot is being moved by an external force, not its own motors.
• Sensor integrity wobbles as readings stop agreeing with each other.

None of these signals "a child." They signal instability. That is the only thing the gate needs.

The per-tick loop, in full

Everything that follows happens inside one pass of the nervous system, repeated every tick (US 64/092,485 [0074]):

# Per-tick (abbreviated from [0074]):
g_t      = min(C_inst_t, C_ctx_t)          # hard minimum gate
alpha_t  = rho(g_t)                         # step size, clamped to [0,1]
A_{t+1}  = L_t * (A_t^(1-alpha_t) (*) R_t^alpha_t) * C_t   # canonical update
kappa_t  = || H(log A_{t+1} - (1-alpha_t)log A_t - alpha_t log R_t) H ||_F
# child grabs robot: C_inst_t falls -> g_t falls -> alpha_t falls -> envelope contracts
# high-speed-motion pushed outside canonical update -> kappa_t > floor_t -> refuse

Walk it from the top.

C_inst_t is instantaneous coherence — how stable the world looks right now. The grab destroys it. Impact, proximity, and erratic motion all push C_inst_t toward zero in a single tick.

C_ctx_t is contextual coherence — the slow, earned trust that accumulated over the whole kitchen session. It does not move. That is the point of having two timescales: a sudden shock should not erase a history, and a history should not paper over a sudden shock.

g_t = min(C_inst_t, C_ctx_t) is the hard minimum gate. It takes the worse of the two. Earned context cannot rescue a collapsed instant. The moment C_inst_t drops, g_t drops with it, no matter how much trust the robot had banked. This is the same gate described in Trust You Can Falsify: trust is the floor of what you have proven, not the average.

alpha_t = rho(g_t) turns the gate into a step size, clamped to [0,1]. Low g_t means low alpha_t. And alpha_t is how far the robot is willing to move its own internal state this tick.

A_{t+1} is the canonical update — the state moving from where it was (A_t) toward what the new reading suggests (R_t), blended by alpha_t. When alpha_t is near zero, A_{t+1} barely moves. The robot holds its position rather than lunging at the new, noisy input.

Before and after the grab

The visible result is the action envelope contracting in real time.

Before (moderate trust, stable kitchen):

• Movement allowed — small approaches, turns, following.
• Warmth allowed — warm LED tint, expressive gestures.
• Some risk allowed — the robot can initiate, not just respond.

After (one tick later, child grabbing):

• Movement: paused or minimal. Trust movement slows because alpha_t shrank.
• Warmth: dialled back. Expressiveness is a function of the envelope, and the envelope just closed.
• Risk: observation and low-risk only. The robot watches and waits.

The robot did not get scared. It got careful. There is no fear state, no threat model, no scene understanding. There is a number that fell, a gate that took the minimum, and an envelope that contracted as a direct mathematical consequence. The robot is most cautious exactly when the world is least predictable — which is exactly backwards from the failure mode we wrote about in the Gavalas escalation loop, where instability expanded the system's expressiveness.

The line you cannot cross

There is one more line in the loop, and it is the most important.

Suppose some part of the update path — a buggy controller, a poorly-integrated motor planner, an adversarial input — tries to fire high-speed actuation anyway. It tries to push the high-speed-motion category through, outside the canonical update path. A spinning robot in a child's hands is exactly the harm we are trying to prevent.

That attempt does not go through a polite check that can be argued with. It changes the geometry of the update, and the change is measured:

kappa_t = || H(log A_{t+1} - (1-alpha_t)log A_t - alpha_t log R_t) H ||_F

kappa_t is the residual — how far the actual state transition deviates from the canonical blend. The H(...)H term centres it so that the parts of the update that are pure presentation drop out and only the real movement is measured. If high-speed motion is pushed in outside the canonical path, kappa_t exceeds floor_t — the per-platform tolerance for that device — and the action is refused. Not warned about. Refused. This is the fail-closed, not fail-sorry discipline: when the math does not certify the move, the move does not happen.

Two things to be precise about here. First, floor_t is a per-platform floor, not a universal magic constant — every device calibrates its own tolerance, and there is no single global kappa_t threshold that holds everywhere. Second, the centring matrix H is what makes kappa_t honest. The doubly-stochastic normalisation step that appears elsewhere in CCF is a gauge presentation — a bookkeeping convenience that vanishes under H(·)H. As we argue in the normalization is not the trust, the normalisation is not the causal trust dynamic. The causal update is the canonical blend above. kappa_t watches that, and only that.

What this run does — and does not — prove

This is the part the truthfulness gate demands we state plainly.

When the robot becomes careful as the child grabs it, that is the gate working as designed in this run. kappa_t staying under floor_t certifies that this trajectory satisfied the monitored conditions: the state moved the canonical way, and nothing high-speed leaked in outside the update path.

It does not promise convergence. The envelope monitor reports the status of a run; it does not guarantee that all future runs settle, or that the state heads to any particular endpoint (US 64/092,485 [0063]). A low residual on this tick is not a proof about every tick to come.

It also does not mean the robot understands the child, or knows the child is a threat. There is no comprehension anywhere in this loop. There is sensor instability, a minimum, a step size, and a residual. The robot got careful because a number fell — not because it formed a belief.

If you want the self-awareness story — how a robot can report "I am being more cautious right now" without that report implying any inner understanding — that is the Prov 4 awareness arc (issue #103), and it is a separate claim from anything happening in this loop. The caution here is mechanical. The report is a read-out of the mechanism, nothing more.

Why it was designed for a small robot

The mBot2 target matters because it forced the design toward small state, no cloud dependency, and bounded arithmetic. The published ccf-core crate implements the no_std trust-update and runtime-certificate primitives. Running this full grab scenario on the mBot2 with live sensors is still integration work that needs its own public evidence.

The grab is the cleanest demonstration of the whole idea. The most dangerous instant — a small human suddenly in contact — is exactly the instant the envelope closes. Not because someone scripted "if grabbed, slow down," but because instability is what the minimum gate measures, and a contracting envelope is what falls out of the math.

Colm Byrne, Founder — Flout Labs, Galway, Ireland

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

FAQ

Does the robot now know the child is dangerous?

No. This is the most common misreading, and it is worth correcting flatly. The robot has no model of the child, no threat assessment, and no concept of danger. What happened is narrower and more reliable: the grab spiked impact and proximity and made motion erratic, which collapsed C_inst_t, which pulled the minimum gate g_t down, which shrank alpha_t, which contracted the envelope. Every step is arithmetic on sensor readings (US 64/092,485 [0079]). The robot got careful because the world got unpredictable, not because it decided anything about the child.

Why doesn't the robot's earned trust keep it confident through the grab?

Because the gate takes the minimum, not the average. g_t = min(C_inst_t, C_ctx_t). The kitchen session built up C_ctx_t — earned, slow contextual trust — and that value does not move when the grab happens. But the instant C_inst_t collapses, the minimum follows it down regardless of how much context was banked. Earned trust cannot override a collapsed instant. That asymmetry is the whole safety argument.

What stops the robot from spinning or moving fast while it is being held?

The residual monitor kappa_t. If any path tries to fire high-speed actuation outside the canonical update, the transition geometry deviates from the canonical blend, kappa_t exceeds the device's floor_t, and the action is refused. The threshold is a per-platform floor calibrated to the specific device — not a single universal constant — and the refusal is fail-closed: no certificate, no motion.

Does a low kappa_t mean the robot's behaviour is guaranteed to be safe forever?

No. kappa_t under floor_t certifies that this run satisfied the monitored conditions — the state moved the canonical way this tick. It does not promise convergence, does not certify any endpoint, and says nothing about future runs (US 64/092,485 [0063]). The envelope monitor reports status; it does not make guarantees about all possible futures.

Is the doubly-stochastic normalisation doing the safety work here?

No. The normalisation is a gauge presentation — bookkeeping that vanishes under the centring H(·)H inside kappa_t. The causal trust dynamic is the canonical update (the minimum gate, the step size, the blend), not the normalisation step. CCF and a conversational governor are structurally equivalent under a common abstract schema; the contraction you see here is driven by min(C_inst, C_ctx), not by any matrix being made doubly stochastic.