The robot that trusted a room it had never been in

A real moment

Picture a small museum on the County Down coast. There is a floor robot that walks visitors from the ticket desk to the boat hall, and at the end of the day it goes and charges in an alcove under the west stairs. It has done this about nine hundred times over two years.

By now the robot is settled there. It comes down the corridor without slowing. It turns into the alcove without feeling for the wall. It parks and goes quiet. Staff stopped noticing it about a year ago, which is the highest compliment a building robot gets.

That settledness is not a setting anyone typed in. The robot built it. Every docking added a little to a number the robot keeps about that alcove, and the number cannot be edited, granted, or shortcut. It only goes up by going there. That is the whole idea. A robot should be careful in places it does not know, and the only way to stop being careful is to learn the place.

Then the museum does a refit. The west stairs come out. The dock gets moved forty metres, to the alcove under the east stairs.

The two alcoves are, to a robot, almost the same room. Same stone. Same low light. Same quiet. Same cold. If you measure the difference across the robot's sensors and put a number on it, the number is about 0.20.

The robot's rule for noticing it has moved fires at 0.30.

So nothing fires. The robot comes down the corridor that evening without slowing. It turns into the east alcove without feeling for the wall. It parks. As far as its own records go, it has been coming to this spot for two years.

It has been here once.

The east alcove has a fire door that swings out across the approach. The west one never did. Nobody did anything wrong. The maintenance team moved a charger. The robot ran its checks and passed them. Its arithmetic was correct on every step.

And the confidence it was spending had been earned in a room that no longer exists.

Why this matters

Chargers are the least of it. The story is about what a machine is entitled to assume.

Almost every system that has to recognise a place does it the same way. It compares what it is seeing now against what it saw before, gets a number for how different they are, and checks that number against a line drawn in advance. Above the line, new place. Below the line, same place.

The line has to go somewhere. Put it too low and the system panics at ordinary change: a lamp gets replaced, the season turns, and it decides it has never been here. Put it too high and it waves through things that genuinely are different.

Robotics has known about the high side for a long time. In mapping it is called perceptual aliasing, and the usual cost is a corrupted map. A paper out of Southampton and QUT this July put the general version plainly: these thresholds are tuned offline on test data and then frozen for deployment, and frozen thresholds do not survive contact with real light, real weather and real buildings.

What changes when the system is doing trust rather than mapping is what the wrong answer buys you. A mapping system that guesses wrong gets a bad map. A robot that guesses wrong walks into an unfamiliar room with a familiar room's permissions.

The reason this is worth writing down is that the rule it breaks is the one rule the system was built around. Familiarity cannot be created, copied or granted. It can only be earned. The robot in the museum did not break that rule by cheating. It broke it by being told, wrongly, that it was somewhere it had already earned.

What CCF does about it

CCF is the architecture behind this. It keeps a separate record for every context a robot encounters, and under each record it keeps a floor that rises with how many times the robot has actually been there. Confidence fades while the robot is away, but it never drops below that floor. The floor is the earned part.

When the sensors stop matching a stored context, CCF is supposed to do something fairly drastic. It sets the old floor aside, opens a fresh record at zero, and makes the robot earn the place again from nothing. The robot goes back to being careful. It hesitates. It approaches slowly. People notice, and they are meant to, because a robot that suddenly starts behaving like a newcomer is telling you something changed.

The design is right. This run was about the one number that decides when it fires.

We built the thing and swept it, in both directions, against a ground truth the robot could not see. The program carries a record of which physical place the robot was actually in. Nothing in the detection path can read it. Without that, all you can do is measure the detector against its own opinion.

The first direction is the room changing while the dock stays put. That is not hypothetical for a museum, where the lighting rig gets swapped for every exhibition. Push the ambient conditions around across a simulated year and the robot gets told it has moved on 170 out of 365 dockings. Every one of those wipes out everything it built. The robot knows where it is. The line is what is confused.

The second direction is the one from the story. Move the dock for real, to somewhere that reads similar, and see whether anything notices.

Nothing notices. Not once.

The numbers

We ran 1800 genuine relocations to places between 0.05 and 0.29 away in sensor terms. The rule as specified caught zero of them. We ran 600 more at 0.31 and above, and it caught all 600. There is no soft edge. It is a cliff.

For the robot in the museum, settled after nine hundred dockings, a missed move means it arrives at the new alcove with an earned floor of 0.749 instead of zero. Its working confidence is 0.85 instead of 0. Its willingness to update on what it sees is 0.343 instead of 0.02, which is about seventeen times higher, and close to the top of the range it is ever allowed.

One more, which surprised us. We expected that after a reset, getting back to normal would take roughly as long as it took the first time. Getting all the way back does. Getting back to looking normal takes 203 dockings no matter what. So a robot that lived somewhere for 3600 dockings is behaving like its old self after six percent of the recovery is done. The longer it lived there, the more misleading that looks.

What this doesn't solve

This measures a model, not a robot. The curve is fitted to a single worked example from the patent filing, which is enough to pin two numbers and not enough to prove a shape. Real sensors are messier, correlated, and occasionally broken. Before any of these counts get quoted as deployment advice they need running against logged data from an actual dock.

We also did not fix it. We know moving the line does not work, because the two failures sit on the same line and pull opposite ways. Tighten it and the museum robot gets amnesia every time the lights change. Loosen it and it walks into strange rooms with a resident's confidence.

The deeper reason is that two different questions are being asked of one measurement. Whether the readings changed is a question about readings. Whether the robot is in a different room is not. What to do about that is a design decision, and it is going through review rather than being settled in a night's work.

And nothing here measures a person. The filing says a robot losing its place is visible to anyone watching. That is a claim about people and we have not tested it.

For the curious, the math

CCF has a runtime certificate. Every time the robot updates its internal state, a number gets computed that says whether the step taken was exactly the step the math prescribes. If it drifts, the system fails closed.

So the obvious question is whether the certificate catches the museum robot.

It does not. Across 240 steps spanning a missed relocation, all 240 certified clean, sitting about seven orders of magnitude under the limit. No excursions. No warnings.

That is the correct answer and it is worth being precise about why. The certificate takes the previous state, the target, the new state, and the update rate. There is no context key in that list, and no place identifier. It is checking that the sum was done right. It is not checking which ledger the sum was entered in. A missed relocation produces a perfect run of correct arithmetic against the wrong ledger, and there is nothing in the certificate's inputs that could ever notice.

We made the code state this out loud rather than argue it. There is a test that runs the same sequence twice, once as if the dock had moved and once as if it had not, and asserts the certificate cannot tell them apart.

This is the second night in a row this boundary has turned up. The previous run found that the certificate does not settle why a robot stopped working and went to charge. Tonight it does not settle where a robot thinks it is. Two different questions, same answer: the certificate binds the step, not the situation the step happened in. Knowing exactly where a guarantee stops is worth as much as the guarantee.

Where this fits

This came out of the second provisional filing (US 63/994,113), which describes four behaviours that fall out of one accumulation dynamic. Last night's run covered two of them. This one covers the third, which the filing calls dock relocation distress, along with the three-phase arc a robot's attachment to its charging spot goes through as it settles. Both phases turned up where the filing said they would: the early phase ends around interaction 29, the settled phase starts around 203, and the shift between them is gradual rather than a switch.

The code is in the CCF repository under crates/research/dock-relocation-re-earning. Forty tests, no mocks, fixed seeds, and every number in this post is printed by a program you can run. The full write-up with the sweep tables is on the research branch, and there is a keyword-dense version in the public gist.

Repository: https://github.com/Hulupeep/CCF Specflow, the contract discipline these runs are built under: https://github.com/Hulupeep/Specflow Flout Labs: https://floutlabs.com

One correction while you are here. Some older pages on this site describe Sinkhorn-Knopp and Birkhoff geometry as the thing that makes trust transfer work. That framing is out of date. The actual update is a quotient-affine contraction behind a hard minimum gate, with a per-step residual certificate. Normalization is presentation only.

License & contact

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