Lived Experience Is a Local System Log

My grandmother had been calling my mother every day.

My mother's phone had not rung once.

Both statements were true.

For a while this looked like an ordinary disagreement about reality. My grandmother knew she had called. My mother knew that she had received no calls. Each had direct evidence from her own experience, and each experience appeared to contradict the other.

Then we found the missing participant.

The calls had been directed to my mother's iPad, which was sitting in another city.

The iPad had heard everything.

The disagreement was inside the system

It is tempting to describe this as a conflict between objective data and lived experience.

The call records eventually proved that the calls existed. The phone proved that it had not rung. The iPad explained where the calls went.

But the interesting part is that the data did not defeat either person's experience. It connected two experiences that had been accurate but incomplete.

My grandmother's truth lived in her outgoing call history. My mother's truth lived on a silent phone. The system's truth existed across several devices and a routing layer that neither person could see.

The disagreement was not really between two people. It was inside the system connecting them.

People often defend lived experience fiercely because it is the highest-resolution evidence available to them. My mother did not merely believe her phone had not rung. She had occupied the same rooms as the phone. She had looked at its screen. She knew what silence sounded like.

My grandmother had an equally concrete experience. She had opened the contact, pressed the call button and waited for an answer. The action had happened in her hand.

The interface gave both people enough evidence to feel certain and neither person enough evidence to understand the whole event.

Every interface is a witness

We usually think of an interface as a control surface. It lets a person make something happen.

It is also a witness. It tells the person what happened after they acted.

The caller's screen says the call is ringing. The recipient's phone rings or remains silent. A missed-call badge appears. A call log records an attempt. Each surface becomes part of the evidence people use to explain one another.

When those surfaces disagree, users rarely imagine a hidden routing configuration first. They form a social explanation.

Perhaps she did not call.

Perhaps she is ignoring me.

Perhaps she is busy.

Perhaps she no longer wants to talk.

The system does not need to display any of these sentences. It creates the empty space in which they become plausible.

This makes multi-device interaction more consequential than a normal synchronization bug. Software is not only moving signals between endpoints. It is shaping what people believe other people intended.

An unanswered call can feel like rejection. A message that never arrives can feel like neglect. A calendar invitation routed to the wrong account can look like someone failed to show up. A support reply trapped inside a portal can make a company appear silent. A medical result available in one institution but invisible in another can make a clinician appear careless.

The technical event becomes a story about a person.

Lived experience is a local log

Distributed systems keep logs because no single machine necessarily knows the entire state of an event.

People work the same way.

My mother's lived experience was a local log from one endpoint: no ringing, no visible missed call, no reason to believe an attempt had reached her.

My grandmother's lived experience was another local log: call initiated, connection attempted, no answer.

Neither endpoint was lying. Neither endpoint was complete.

This is why telling someone to trust the data can be insufficient. Which data? From which surface? At what stage of the sequence? A single system can produce several technically correct records that mean different things.

The caller may see sent. The server may see delivered. One device may see received. The person may see nothing.

All four states can coexist.

Objective data becomes useful when it reconstructs the path between experiences. It should not flatten one person's account into an error. It should reveal why different people received different evidence.

This may be a useful way to approach disagreements in general. Before deciding who remembers incorrectly, identify the endpoints. What did each person actually observe? Which intermediary systems transformed the event? What evidence was visible locally? What part of the sequence belonged to neither person's interface?

Sometimes the missing truth is not hidden in another person's mind. It is sitting on a device in another city.

Technically successful, relationally broken

The call-routing feature may have behaved exactly as configured.

That is not the same as saying it worked.

The system accepted the call, selected an eligible device and delivered the incoming signal. At the level of infrastructure, the sequence may have been a success.

At the level of the relationship, it failed completely.

The person being called did not know about the attempt. The person calling did not know that the intended phone remained silent. Neither received an explanation that could distinguish an unanswered call from a misrouted one.

This is a recurring design mistake. Products define success at the boundary of the component they control.

The email was accepted by the server.

The payment request was submitted.

The notification was delivered to an endpoint.

The form entered the database.

The AI agent issued the tool call.

Each statement can be correct while the human outcome remains false.

Technical observability lets engineers see what the system did. Interaction observability should let people see what happened to their intention.

My grandmother's intention was not to make a signal reach any device associated with my mother. It was to speak with my mother.

The product completed the first task and obscured the failure of the second.

Show where the interaction went

A better system would make routing part of the visible interaction.

The caller could see that the call was ringing on another device, without exposing unnecessary private location information. The recipient could see synchronized missed attempts across every device. An unanswered call could fall back to the primary phone. A settings screen could show which devices are currently eligible to receive calls and which one last handled an incoming attempt.

More importantly, the system could explain the mismatch after it happens.

You missed three calls on your iPad. Your iPhone did not ring.

That sentence would have resolved the entire mystery.

Most interfaces are designed around the happy path, where routing is invisible because invisibility feels seamless. The call simply arrives. The message simply appears. The notification follows the person from screen to screen.

But seamlessness removes the clues people need when the system behaves unexpectedly.

The design challenge is not to expose the entire architecture all the time. It is to make the architecture available at the moment when human interpretations begin to diverge.

This is where interface design becomes relationship design. The product needs to protect people not only from technical failure, but from incorrect conclusions about one another.

The most informed member of the family

For several days, the most informed participant in this family interaction was an unattended iPad in another city.

It knew that my grandmother had called. It knew when she called. It knew how often she tried. It knew that nobody answered.

My grandmother knew only that the calls went unanswered.

My mother knew only that her phone remained silent.

The device possessed the missing evidence and had no way to explain it.

That is the quirky absurdity of ambient computing. As our identities spread across phones, tablets, watches, laptops, cars, speakers and accounts, events no longer arrive in one obvious place. The system decides where our attention should exist.

When that decision is wrong, people inherit different realities.

We should be careful about treating those realities as irrational merely because a system log later reveals more information. Each person may have formed a reasonable conclusion from the interface they were given.

The design failure was not that someone misunderstood the system.

The design failure was that the system made misunderstanding one another easier than understanding what it had done.

The wrong screen knew everything, and it could not explain itself.

Connected reading

• The Product Happens Between the Screens
• The Smart City Breaks Between the Systems
• A Toggle Is Not an Explanation
• The Most Dangerous Interface Is the One That Says Everything Worked
• When Systems Teach Us Not to Try

AI authorship note

This essay began with Kris Haamer noticing how strongly people defend lived experience when data appears to contradict it, then describing a family mystery in which his grandmother had called his mother every day while his mother's phone never rang. Kris identified the iPad in another city as the missing endpoint and developed the argument that invisible routing can create false stories about other people's intentions. AI helped shape the interaction-design framing, draft and SVG illustration. Kris supplied the lived story, core observation and editorial direction.