The robot that remembers being trusted, and forgets what it heard

A real moment

St Brendan's is a twenty-four bed rehabilitation ward outside Ennis. It is invented, and so is everyone on it, but wards like it are real and so is the problem.

Bed 14 is Marion Hourigan, six weeks after a hip replacement. The ward has had a mobile assistant robot since the spring. It fetches things. It reminds people about medication. It walks alongside anyone going down to the day room, at their pace, which is the part the physios actually like.

Marion asks it for privacy most days. Sometimes it is a call with her daughter in Perth, who rings at odd hours. Sometimes it is a dressing change. Sometimes she just wants the thing to stop hovering at the end of the bed. There is a button on the rail. She presses it and the lens cover swings shut with a click she can hear from where she is lying, the light on the robot's collar goes amber, and it turns away. Twelve minutes later she presses it again. The robot comes back and asks her nothing at all about what it missed.

Here is the part nobody designed on purpose. Marion is the patient on that ward the robot understands worst.

She is not difficult. What she is, is quiet. A third of her time with the robot is time it was told to sit out, and in the software running today every one of those minutes is a hole. The robot's picture of Marion is built from what it observed. She gave it less to observe than anyone else on the corridor. So three weeks in it is still treating her a bit like a stranger. Still checking. Still keeping its distance in a way it has stopped doing with the man in bed 11 who never presses the button at all.

Marion notices. She would not put it the way an engineer would. She would say the robot never really took to her.

The nurse manager notices too, and puts in a ticket about it. There is nothing to fix. The design is working exactly as specified.

Why this matters

Every ambient system on the market makes you choose between being known and being left alone. Smart speakers, ward robots, home assistants, the lot. Let it watch and listen and it learns who you are. Ask it to stop and that stretch of time becomes nothing.

That looks like a law of nature. It is not. It comes from one decision buried in how these systems store what they know: the absence of data is treated as the absence of interaction. Nothing recorded, nothing happened.

Think about what that gets wrong. A stranger does not ask a robot for privacy. A stranger just says nothing near it. Asking for privacy is something you do with a thing you have already decided is in some sense on your side. When a person you barely know says "this is between us," the relationship moves, and it moves because of the asking, not because of what gets said afterwards.

So the current design has the sign backwards. It treats the clearest available evidence of confidence in the machine as a gap in the record.

The usual answers do not fix this. On-device processing, federated learning and differential privacy all make it safer to compute over the content. They still need the content. If the person's whole point is that there should be no content, those approaches have nothing to offer.

What CCF does about it

The change is small enough to describe in a sentence. When someone invokes privacy, the robot writes down that it happened, and nothing about what happened.

One row, twenty-four bytes. Which room. What time. How long. What state the interaction was in just before. That is the whole record. There is no field on it capable of holding audio or video or a transcript, which matters more than a policy would, because a policy is something the code is trusted to follow and a missing field is not.

Then the robot counts that row as part of the relationship.

Three guards stop this being gamed, and all three were forced on us by measurement rather than chosen for tidiness.

The first is that the robot pays less for a privacy request the more ordinary it becomes in that room. The first time somebody draws the curtain in the side room tells you something. The two hundredth time does not. The arithmetic says so on its own, using how surprising the request was in that context, so nobody has to tune a rule about it.

The second is that a privacy request only counts in a room where the robot has actually spent time with people. The credit is scaled by how much of the relationship in that room is real. In a room where the robot has never helped anyone, a request to leave is worth nothing, however many times it is made. This guard was not in the first version of this post. Someone reviewing the work found that the first guard on its own could be beaten, and the section below says how.

The third is the CCF hard gate, which has been in the architecture from the start. Trust is capped at the lower of what the moment supports and what the history supports. A privacy event cannot push a robot past what it has actually earned, any more than a good afternoon can.

There is one more piece, and it is the one people find uncomfortable when they first hear it. The robot builds a picture of when private time tends to happen in each room. Not what happens. When. And the only thing it is permitted to do with that picture is hold back. If it works out that bed 14 usually wants the room around eight in the evening, the sole effect is that it is quieter at eight in the evening. There is no path in the code by which learning a habit lets the robot do more. That is a property of how the number is built, not a promise about how it is used.

The numbers

We built it in Rust and ran it against a simulated ninety-day ward: 1620 interactions, six rooms, three designs racing on the identical stream.

Take a robot that honours privacy in half its interactions. The design shipping today loses 8.2 percent of its accuracy about the relationships it is in. The design described here loses 2.7 percent, while storing zero seconds of audio against the recording baseline's 32.8 gigabytes. The first version of this post said 0.4 percent. That number was real, and it came from a version of the rule that turned out to be farmable. The corrected rule gives some of the benefit back, and 2.7 is the honest figure.

The gap is worst early, which is the part that matters. At day seven, the current design reads its relationship with the side room at 0.44 when it actually stands at 0.61. Twenty-eight percent behind, through the whole first month. That first month is when a ward decides whether to keep using a robot at all.

One number surprised us. We tried the obvious version of this idea first, where a privacy request counts like any other engagement. Under that rule somebody could reach high standing with the robot in 35 requests and no real interaction at all, which is faster than an honest user gets there by talking to it. Scaling by rarity stopped that attack, and the first version of this post said that was the end of it.

It was not. A reviewer read the work and tried a different attack. Instead of asking for privacy in one room over and over, ask in every room in turn. Then no room ever becomes the routine one, the credit never decays, and high standing arrives after 307 requests with no real interaction anywhere. Two rooms are enough to do it in 239. We reproduced that exactly.

The fix is the second guard above. Under it that attack earns precisely nothing, in one room, two rooms or all six. We are reporting the cost too. Someone who first has 25 real interactions in a room, and then runs the every-room attack, can still get there in 223 requests. That is slower than before and it is not closed. Closing it needs one more rule, a ceiling that privacy requests can never lift trust above what real interaction alone has earned, and that is the next thing on the list rather than something we are claiming tonight.

What this doesn't solve

Ask this robot what Marion said to her daughter and it answers at chance. We measured that too, and we are reporting it rather than burying it. There is no content, so there is no content-derived personalisation. Anything a ward needs from inside the private period is outside what this can do.

The bigger honesty problem is the log itself. Writing down zero content does not make the record uninformative about the person. We measured how much: holding all the metadata narrows a guess about when this person takes private time by about three bits. On a hospital ward that is close to clinical information. The same three bits are what make the anticipation work. There is no version where you get one and not the other, and the right response is to treat the content-free log with the same care as content, which the design does not currently require.

And the whole thing rests on a claim about people: that asking for privacy is an act of confidence rather than a withdrawal. That feels true and it is not proven. It needs a long study on a real ward, not a simulation, and until somebody runs it this remains a well-measured idea rather than a demonstrated one.

For the curious, the math

The trust granted for a privacy event is the surprisal of that event in that room, negative log of the smoothed rate, normalised so the scale does not move with the number of rooms. That is multiplied by a grounding term, the number of real interactions in the room divided by real interactions plus privacy requests plus one, which is exactly zero with no real interactions and climbs toward one inside a real relationship. That value is then capped by the CCF gate: trust moves by at most a step size derived from the minimum of momentary stability and what the room has earned. Increments apply against the accumulator's remaining headroom, so growth stays asymptotic and no sequence of events reaches the top.

The anticipation is a per-room histogram over hour of day, scored by how many bits it removes from a uniform prior. It fires above 1.5 bits. That threshold was measured, not picked: a room with no pattern at all still reads about 0.45 bits from smoothing and sample size alone, and rooms with a genuine fixed-hour habit read 2.8 to 3.1. The multiplier it produces is constructed inside zero and one, which is what makes downward-only a fact about the code.

Full derivation, all four experiments and the verbatim benchmark output are in the research document. The gate itself is in the published ccf-core crate on crates.io and is not re-derived for this work.

Where this fits

This exercises Extension 4 of the second CCF provisional (US 63/994,113), which covers privacy-responsive trust accumulation, null-content trust events and anticipation from relational metadata. It is one of a series of nightly runs that take a filed part of the architecture and measure whether it does what the filing says it does.

• Research document and benchmarks: https://github.com/Hulupeep/ccf/tree/research/nightly/2026-09-05-privacy-responsive-trust-accumulation/docs2/research/nightly/2026-09-05-privacy-responsive-trust-accumulation
• Rust crate: crates/research/privacy-responsive-trust-accumulation/
• The gate crate: https://crates.io/crates/ccf-core
• The contract-driven method behind the build: https://github.com/Hulupeep/Specflow
• https://floutlabs.com

License & contact

Code under BSL 1.1, converting to Apache 2.0 in 2032. Licensing and technical contact through https://floutlabs.com.