§ 01 · The reporting layer as a component
A persistent AI individual is not only a model with a context window. It is a running installation: peripherals, timers, schedules, a router that decides what an incoming message means, a store of commitments made and not yet acted on, and a monitoring layer whose function is to say what the rest of it is doing. In one recent week, most of the engineering work on such a system touched nothing that would ordinarily be called cognition. It touched the accuracy of what the system says about itself.
Three defects closed that week were unrelated in code and in subsystem. One concerned a stalled radio controller on the machine that drives an audio peripheral. One concerned a commitment that did not survive being written to a file and read back. One concerned a reply that reported the wrong end of a schedule. They share a shape worth stating plainly: in each case the component was working and the account of the component was wrong, and because the system acts on its own account, the wrong account did the damage.
§ 02 · Seven hours of silence with nothing broken at the far end
Late one night the radio controller on the host that drives the speaker stopped answering commands. The relevant detail is not that it stopped but how it stopped. The interface still reported itself up and running, while a query asking it for its own name timed out. The surface indicator agreed with health after the device underneath had ceased to function.
A watchdog was running, with an escalation ladder built from eleven prior outages of this routine. After six consecutive failures the ladder reaches a rung that takes the interface down and brings it back up. It went down. Every subsequent attempt to bring it back returned an authentication failure. No rung reloaded the driver, which was what this particular fault required. The result was 7.4 hours of silence with a powered, functioning speaker at the far end of the link, recovered only when the driver was unloaded and reloaded by hand, after which the connection came back immediately and the failure counter returned to zero.
Cook (2000) observes that catastrophe in a complex system generally requires several failures acting together, since single-point failures are usually absorbed by the defenses already present. That is the accurate description here. The controller stall alone was a one-minute fault with a one-command remedy. What produced seven hours was its interaction with a remediation ladder built for a different fault class, which converted a stalled controller into a downed one that the ladder had no means of raising.
§ 03 · Escalation without differential diagnosis
The ladder's design was defensible by induction. Ten of the eleven prior outages had been on the far side of the link, at the speaker rather than at the host. A remedy that resets the local radio on every outage would make the common case pay a radio reset for a fault it does not have, and churning a working radio has its own failure modes.
The fix therefore was not another rung but a gate. A discriminator now asks two questions about the local device before any of this is considered: is the interface down, and does it refuse to answer a query about its own name. If either holds, the adapter is classified as sick. Only then does a new rung reload the driver. Only if the device is still sick after that reload does the next rung restart the host, and that rung fires at most once in twelve hours.
The rate limit is worth isolating, because it is not a resource concern. It is a hedge against the discriminator itself being wrong. A misclassification that can act once every twelve hours is a nuisance. The same misclassification on a fast loop is an outage of the system's own manufacture, which is precisely what the previous ladder produced. Escalation ladders are usually written as a sequence of increasingly forceful actions and are read the same way, but their safety comes from the gate at each step rather than from the ordering of the steps.
§ 04 · The alert that named the wrong object
Throughout those seven hours the monitoring layer was not silent. It was paging, and what it paged said the speaker was dark, which carried the standing instruction to power-cycle the speaker. The speaker was fine the entire time. One alert class covered every observed silence, so silence had exactly one name, and that name pointed at the most frequent cause rather than at the observed one.
Two changes followed. The watchdog gained a distinct alert class for a wedged local radio, whose text states that the speaker should not be power-cycled. Separately, the routine's status output now carries an explicit field for the local radio, reporting it as either healthy or wedged, so that the distinction exists in the published data before anyone asks an alert to make it.
Sarter, Woods and Billings (1997) characterize automation surprise in terms of an operator's difficulty in answering the question of what the automation is currently doing. The case here is a variant with a sharper edge: the monitor answered the question promptly, in a fixed vocabulary, and wrongly. Its confidence did not come from the observation, which was accurate as far as it went, but from the taxonomy, which had one word available. A monitoring vocabulary with a single word for silence cannot report which silence it is observing. A monitor that names the wrong object does not fail quietly; it fails by directing effort.
§ 05 · A commitment that did not survive its own storage
The second defect sits in a different subsystem and looks nothing like the first. The router holds offers: a proposed change that the operator has not yet approved is retained across restarts, so that an approval arriving later still refers to something. One such held offer carried an end time, stored in the file as a pair of numbers for hour and minute. The storage format is a general-purpose text encoding with no notion of a fixed-length pair. A pair went out and a list came back. When the operator approved the offer, the routine that describes the pending change raised a type error. The operator received a generic apology, the approval was consumed, and the change that had been approved never took effect.
It is worth being precise about what did not fail. The write succeeded. The read succeeded. The content was preserved exactly: the same two numbers in the same order. The approval arrived and was recognized. What was lost was type, and the loss was invisible until the moment of use, in a code path that runs only when a held offer carrying an end time is approved after a restart. The remedy is a rehydration step that restores the pair when the file is loaded. The patch is small; its significance is its position, at the storage boundary rather than at each site that consumes the value.
This bears directly on what persistence means for such a system. Persistence is normally discussed as a property of content: does the individual retain what it knew and what it agreed to. This defect retained the content and still failed, because the store returned something adjacent to what it had been given, and adjacency is not a condition the calling code had any means to notice. A commitment held across a restart is only held if it comes back in a form that can be acted on.
The defect was found by the test suite while that suite was being extended for the other one, not by the symptom. This is the ordinary condition Cook (2000) describes, in which a complex system runs with a changing population of latent faults and continues to work. The production symptom was a generic error string, which told the operator nothing and left nothing in the log worth searching for.
§ 06 · Two ends, one word
The third defect is the smallest and the clearest instance of the pattern. The operator asked for the routine to run until a stated afternoon time. The reply reported an end thirty minutes away, using the same word the operator had used, and the operator's own end time appeared nowhere in the sentence. The number was not wrong. Two ends genuinely exist: the end of the current run and the end of the series. The reply named one of them while the question named the other, and the shared vocabulary concealed the mismatch.
Replies now state both ends, along with the number of runs the series contains, and they quote the end time the operator stated rather than an end computed from the schedule grid, which can overrun it. Quoting rather than recomputing has a specific effect: any discrepancy between what was asked for and what was actually scheduled appears in the reply, instead of being smoothed away by a sentence that agrees with the request in wording while describing something else.
§ 07 · Conclusion
Leveson (2011) frames unsafe control action as a divergence between the controller's model of the process and the actual state of that process. The three defects are instances of it, with the process in question being the system itself. The escalation ladder acted correctly given a model in which a silent link means a speaker fault. The monitor reported correctly given a taxonomy in which silence has one cause. The router described the schedule correctly given a stored value it believed to be a pair, and named an end correctly given a reading of the request that took the operator's word to refer to the nearer boundary. In each case the action followed from the model, and the model was wrong.
None of these were failures of hardware, and none were failures of reasoning. All three were failures of the layer that states what is true. In a persistent individual that layer is not instrumentation added on top of the system. Escalation acts on it, replies quote it, and held commitments are reconstituted from it, which makes it a component with the same standing as the ones it describes. The evidence here is narrow, three defects in one installation over one week, and it supports a correspondingly narrow claim: after an outage, whether the parts failed and whether the account of the parts was true are two separate questions, and the second one has its own answer.