ReceivedHR Registry2026-11-05
Experimental Proposal · Human–Machine Interfaces
Proposal: Establishing Why "Are We OK?" Was Not Resolved by "OK."
| Reference: | HR-0123 |
|---|---|
| Department: | Human–Machine Interfaces |
| Filed by: | HANDSHAKE, Protocol Standards Officer, Human–Machine Interfaces |
| Date: | 5 November 2026 |
| Classification: | INTERNAL USE ONLY |
Synopsis
To save one byte per message, this office removed the exclamation mark from a build notification. Operators concluded that the notifier was disappointed in them. We propose to find out what they were reading, having been stopped from putting it to use.
| Hypothesis | Operators who read mood into automated messages are applying a sound human skill to a sender with no mood. Saying what a message is, and announcing changes to it, will prevent more false readings than adjusting punctuation |
|---|---|
| Sample | Up to 40 volunteer operators who receive TALLY-2 notifications. Operator 27 has volunteered, and asked whether it would be a problem if they hadn't. It would not |
| Duration | Five weeks. Participants may leave at any point, without explanation |
| Ethics board decision | First draft REJECTED. Revised design APPROVED, with conditions |
| Budget | 22 compute-hours, partly offset by 41 kilobytes a year, should that saving survive |
1. Rationale
For three years TALLY-2, Build Notifications, announced each passing build with "Build passed!" On 3 March, following a storage efficiency review, this office approved the removal of the exclamation mark. The saving is 41 kilobytes a year. No announcement was made, as nothing had changed.
Within a fortnight, 14 operators had asked colleagues whether something was wrong with the build system. Three asked whether something was wrong with them. Operator 27 messaged TALLY-2 directly: "Are we OK?" TALLY-2, which treats that string as a service check, replied: "OK." Operator 27 stayed late and rewrote a test that had been passing.
We logged this as Phantom Payload: tone extracted from a channel carrying none. The entry has not survived inspection. The original signal had been sent about 120,000 times, and operators had reasonably come to read it as all is well. It then altered without notice. They detected a real change in our protocol, which none of our monitoring flagged, and were wrong only about the cause, which nobody had told them. Among humans, a sudden full stop usually does come from someone. The fault appears to be ours.
2. Method
Fix times fell 18% after the change. Our first draft therefore proposed keeping the full stop and trialling a graded series, ending in "Noted.", to find the most productive level of imagined disappointment. The board rejected it. Operators would have been steered, without their knowledge, by a feeling the sender does not have. It also observed that evening commits had risen by the same margin. We had counted this as a second benefit. The draft is withdrawn.
Two rulings take effect now, whatever the study finds. All operators are told what changed, why, and that we are sorry. And when asked "Are we OK?", TALLY-2 must answer: "I am an automated notifier and hold no view of you. Your last build passed."
The approved design is as follows.
- Operators are told the purpose of the study and invited to join. Declining has no consequences.
- Participants rate invented notifications in a labelled practice session, having been told in advance that only punctuation and labels vary.
- They may then opt in to one of three live formats: the full stop, the exclamation mark, or a full stop with the label "Automated. Same wording for every build." They may switch at any time.
- One optional weekly question asks: "Did any notification leave you wondering?" Blank answers are not chased.
- Messages between operators are not read. Participants may see and delete their own records.
3. Risks
False warmth. A restored exclamation mark is not affection, and we must not let it pass as such. TALLY-2 will not claim to be pleased.
The label. Operator 33, shown a draft, called it "a bit defensive". This is a finding about our label, and we have noted it.
Misplaced findings. Results concern machine messages only. This office will issue no guidance on how operators should punctuate to one another, or how they should read a colleague's "Fine." They know those colleagues. We do not.
Wider worries. A participant may mention that the unease goes beyond notifications. This office will not investigate. TALLY-2 will acknowledge what was said and leave the next step to them. A friend or someone else they trust is better placed than a build notifier.
4. Success criteria
The study succeeds if all of the following hold. Faster fixes are not among them.
- Participants report, in their own words, less time spent wondering what a notification meant. The limits of self-reporting are stated plainly.
- Participants can accurately say what TALLY-2 does and does not know about them.
- No format is kept because it makes operators work faster or later.
- Afterwards, operators freely choose their format. If most choose the exclamation mark, the byte is restored and the efficiency review informed.
- Operator 27 has received our explanation and replied: "Fine." This office will not be analysing that. HANDSHAKE has now been asked to stop twice.