The first essay on Tone Process Monism described a way of looking at persistence through change. I used terms such as tone, compression and return to ask what gets carried forward when a person, institution or other process changes without becoming entirely unrecognizable.
That left an important question mostly untouched.
If every representation carries only part of what produced it, how does a system discover that something important has been left out?
Distributed software provides a useful place to examine the problem because representation happens everywhere.
One service receives something complicated and returns something smaller. A database converts events into stored state. An API exposes selected fields while hiding everything behind its interface. Monitoring software reduces millions of events into metrics, alerts and dashboards that an operator can actually comprehend.
None of this is a defect.
Without compression, a sufficiently complicated system would become impossible to operate. The whole purpose of an interface is to let me use something without reproducing everything the thing itself knows.
The difficulty appears when I forget that the interface is a representation.
Imagine several services that are each behaving correctly according to their own definitions. Requests are valid. Schemas match. Latency remains within expectations. Error rates are low. The dashboard is green.
Something can still be wrong.
Perhaps customers have discovered a way of using the product nobody anticipated. Perhaps a metric is technically correct but no longer measures what the organization thinks it measures. Perhaps two services assign slightly different meanings to a field they both call the same thing.
Nothing has to be malfunctioning locally for the combined result to become misleading.
That's an important distinction.
It doesn't mean correctness is useless or that systems should avoid authoritative state. A database may need one authoritative primary. Financial records need rules for deciding which transactions actually occurred. DNS needs authoritative answers within particular zones. Distributed systems frequently become more reliable by making authority explicit rather than leaving it ambiguous.
The problem begins when authority over a particular question quietly becomes authority over questions the system was never designed to answer.
A database can tell me that an order exists.
It can't necessarily tell me whether the customer intended to place it.
A monitoring system can tell me that a request returned HTTP 200.
That doesn't tell me whether the person on the other end accomplished what they were trying to do.
The measurement may be correct.
Our interpretation can still be wrong.
This is where surprise becomes useful.
By surprise, I don't mean that a system needs to wander around permanently uncertain about everything it knows. Most of the time we want stable expectations. If a payment has settled, continually reopening the question of whether it settled would make the system less useful rather than more intelligent.
Surprise matters at the boundary between the model and whatever the model is supposed to represent.
Something happens that the current explanation didn't predict. A user reports a failure while every internal metric reports success. Two independently collected measurements disagree. An operator encounters behavior the documentation says shouldn't be possible.
At that moment, the mismatch is information.
What happens next tells us something about the system's ability to learn.
A brittle response protects the existing model. The customer must be confused because the dashboard is green. The unusual measurement is discarded because it doesn't fit the expected range. The operator's observation is treated as error because the documentation says the system can't behave that way.
A more useful response asks where the disagreement came from.
Maybe the customer really is confused.
Maybe the se