# When Should the AI Speak?
# Book: Language
# Chapter URL: https://programmer.ie/books/language/20-chapter/
# Prose fingerprint (sha256, normalized): ebfb68833101fecb90726d643df0a17b827bddcc4a6143da483245d95b22a640
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

At 14:40 a candidate arrives in Iris’s standing-interest queue. (A standing interest is a topic Iris has asked the system to watch over time.) The candidate is a new paper that may bear on an assumption behind the code her team is deploying.
This is a constructed case, not an observed deployment. Its proposed queuing policy is also not the stricter one used in the scripted Radar example later in this chapter.
The system has done several things so far. It has identified the source, proposed a possible relation between the paper and Iris’s work, and produced a source-linked brief that passed the available preservation checks. None of this proves that the paper contradicts her code. Its scope is still unconfirmed.
With Iris’s permission, the delivery policy also knows two things from her calendar: a design review runs until 15:30, and a separately recorded deployment is scheduled for 18:00.
The proposed default is to queue the item until the first suitable break, perhaps 15:35. Interrupting her presentation may cause an immediate cost. Waiting fifty-five minutes might still leave enough time to investigate before the deployment.
That reasoning is a judgement, not a fact about her future attention. The meeting could overrun, the deployment could move earlier, or the paper could turn out to be irrelevant. So before delivery, the system must check three things:
The candidate is still current. Iris is still authorised to receive it. The time remaining is enough for whatever review the notification is meant to prompt. If any check fails, the policy must choose again, or report that it cannot establish a safe delivery time.
Earlier chapters separated four properties of an item: its proposed relationship, its task relevance, its novelty, and its resolution (how much detail is shown). In this chapter, those results are treated as inputs, not settled truths. Each keeps its evidence, its uncertainty and its version.
The remaining decision concerns delivery. That includes whether surfacing the item now is permitted at all.
Once several items qualify for attention, when should each one be surfaced?
relevance ↓ qualification ↓ resolution ↓ delivery timing Three decisions, kept apart By this point, the channel makes three separate decisions about each item:
WHAT should be shown? selection HOW MUCH should be shown? resolution WHEN should it be shown? timing Keeping these apart matters because each can fail for different reasons. A candidate may matter greatly and still be safe to read tomorrow. A small API compatibility note may be time-sensitive while someone is editing code, without becoming more important in general.
Timing must not quietly raise an item’s relevance. It must not drop an essential qualifier or shorten a brief just because the queue is full.
A prior selection also should not be permanent. If a source is withdrawn, a deadline changes, a permission is revoked, or a relation is corrected, the item must go back through the affected gates. The decision record should say which judgement changed and why. Keeping the decisions distinct makes revision possible without treating them as if they were unaffected by new evidence.
Four ways to deliver A qualifying item has four proposed delivery modes. They describe an interface contract, not a proven best taxonomy. A reader should be able to choose or override them within the system’s permissions.
Proposed delivery modes. Timing still needs a current policy decision; urgency alone does not create authority. Open full-size diagram. The four modes work as follows:
NOW asks for immediate attention. It must pass the reader’s interruption policy first. QUEUE waits for a permitted break. A predicted breakpoint is not a promise, so the queue needs a fallback in case the break never comes. DIGEST follows a known review schedule. It is not a vague instruction to postpone. AVAILABLE keeps the item accessible without sending a notification. Two other cases are different from these modes. Withholding means an item was considered but is not surfaced at all. An unavailable or unauthorised item is a separate case. It must not appear anywhere, including through hints in metadata such as a list of suppressed items.
A queued or digested item must keep its reason and its deadline. This prevents a delay from quietly turning into permanent suppression.
The chapter’s central separation follows:
qualifies for attention ≠ deserves interruption A conservative default is that most qualifying items do not interrupt. But sending fewer notifications is not success in itself. One missed time-critical item can matter more than several avoided distractions. The policy therefore has to account for both consequential late deliveries and unnecessary interruptions. It must not combine them into a single score that hides the reasons.
Urgency and the cost of interrupting Two quantities describe the immediate trade-off. Neither one grants permission to interrupt. The item must first satisfy the reader’s delivery rules and any channel or device restrictions. Only then does the policy weigh the two quantities:
URGENCY how costly is delay? INTERRUPTION COST how costly is surfacing now? Urgency is about the expected cost of delay, for this task, at this time. It is not an intrinsic score attached to a document. A replication may safely wait during routine reading but become urgent if it affects a decision due in an hour. A deprecation may be irrelevant to today’s code even if announced this morning.
Interruption cost is about what the reader might lose by being diverted now. Examples include a broken line of reasoning, a failed presentation, or the effort of returning to the task. A calendar entry or a finished build can suggest a possible breakpoint. Neither one measures attention or shows that the person is free. Both estimates should carry a reason, an evidence source and an explicit unknown state.
The matrix below sketches possible routing after the permission and source-freshness gates. It is not a command to override focus mode. If either cost is unknown, or no breakpoint is guaranteed before the latest useful review time, the policy must name the conservative fallback it uses. It must not manufacture certainty.
high urgency, low cost NOW high urgency, high cost NOW only if the cost of delay is larger, otherwise QUEUE for the nearest break low urgency, low cost QUEUE or DIGEST low urgency, high cost DIGEST or AVAILABLE An item that matters deeply can still go into a digest if the evidence shows that waiting costs little. A less consequential item may deserve quick attention if an explicitly authorised deadline is close.
However, urgent and unconfirmed do not add up to confirmed. If the relation itself is unresolved, the system needs an explicit rule for whether such candidates may interrupt.
The scripted example later in this chapter takes a strict position: unresolved relations are AVAILABLE only. A deployment-specific policy could instead allow a clearly labelled candidate alert. That exception would require the reader’s prior authorisation, a reason to believe that delay would be costly, and a separate test. The example does not establish that such a capability exists.
Two distinctions remain:
importance ≠ urgency urgency ≠ confidence Importance is not time sensitivity. Time sensitivity is not evidential standing.
Suppose the reader has explicitly opted in to timely alerts about unconfirmed deployment risks. Then a defensible message is: “Possible relevance to tonight’s deployment; relationship to your design not established. Review the linked evidence.” If no such permission exists, the candidate can remain available or queued under the declared policy.
The system must never change “may bear on” to “disproves” because a deadline is close. Nor may it conclude that a paper about a different protocol settles a safety question about Iris’s system.
What the system may know about the moment Estimating interruption cost requires some information about the reader’s situation. But observable is not the same as authorised to collect or use.
The rule is to start with the preferences the reader has declared. Access to any other signal should be requested for a stated purpose. The system should use the least information it needs. Even authorised observations may be missing, delayed or ambiguous.
These are the kinds of context the timing decision may use:
declared task current activity available time deadline device notification mode calendar state explicit do-not-disturb consequence of delay Three cautions apply to every signal:
observable context ≠ permission to use it observable context ≠ verified availability observed activity ≠ inferred inner state Suppose Iris has granted calendar access for interruption routing. A review entry in her calendar is evidence that this is a high-cost moment. It is not evidence of her exact workload. Her explicit focus mode is a policy constraint that the system must respect.
The deployment time should come from an identified, current project record. It should not come from an unverified phrase in a retrieved paper, and it may change. A missing calendar signal means unknown, not “free.”
The design does not infer Iris’s mood, stress or mental state from typing patterns, camera images or speech. Those signals add privacy risk and contested interpretations. A declared policy plus a few authorised operational signals can usually do the job.
Calendar contents should not be copied into the sidecar’s permanent knowledge model (the companion component that stores the system’s records) just because the timing gate read them.
The person must be able to set and inspect the policy, including its exception rules and quiet periods. An emergency channel, if one exists, should be an explicit, narrowly scoped opt-in. It should not be an invisible override invented by the model. An explicit exclusion takes precedence over a broader category such as “expiring.” For example:
Focus mode: interrupt me only for [x] verified blockers on my active deployment [x] expiring items I explicitly subscribed to [ ] unconfirmed contradictions [ ] new implementations Unknown availability: queue or make available; do not assume I am free. A disabled class stays disabled even if it appears urgent. Everything else: morning digest Every interruption explains itself An interruption is a policy decision made on someone’s behalf. Its explanation must make that decision inspectable without making a shaky assessment look certain.
The interface should answer more than why this item. It should also answer why now, rather than at the next break or digest. The explanation must use the same information that actually drove the decision. A plausible story written after delivery is not a real decision record.
Compare that with Iris’s unresolved research-paper candidate. For a verified deployment blocker, the explanation might look like this:
Why did you interrupt me? Because: a verified issue blocks tonight's deployment, and your active incident-alert rule permits immediate notice before the next digest. Standing: verified operational blocker. [inspect source and deadline]. Decision made with: authorised incident rule + current deployment record. [send later] [change this rule] [open unchanged source] A delivery record should be written before delivery, so the explanation cannot be invented afterwards. It should contain:
the candidate and source versions the standing interest or active task it served the permission in force the observed context and its timestamp the latest useful review time the modes considered the mode chosen the reason The interface can then offer direct corrections, such as “send this type later,” “revoke this exception,” or “this deadline is wrong.” Such corrections show preferences about that policy. They do not reveal a person’s stable character or attention span.
Opening or clicking a notification is a weaker signal. It measures engagement, but it can also reflect frustration, curiosity or mistakes. Even an explicit correction is feedback to be tested. It is not proof that every future case should be routed the same way.
How delivery goes wrong The policy can fail in several distinguishable ways. Some failures show up as annoyance. Others are silent missed opportunities or breaches of permission:
too eager everything becomes NOW too timid a genuinely expiring item arrives too late stale decision deadline, permission or evidence changes while queued false availability a missing signal is mistaken for a free moment unauthorised NOW a weak candidate overrides an explicit focus rule opaque timing the reader cannot inspect why this mode was chosen If everything interrupts, the routing system has failed. But a very quiet system can fail just as badly, by letting deadlines pass unseen.
A single opaque priority score would hide why either outcome happened. Quantitative estimates of delay and interruption cost can still be useful. The requirement is that the policy keeps its inputs separate, applies hard permission constraints, and leaves a trail that can be reconstructed. Aggregate optimisation must not conceal false urgent alerts, late critical alerts or policy violations behind a good-looking average.
Testing the delivery policy The empirical question is not whether a carefully timed notification feels considerate. The real question is whether a policy improves the reader’s work and their access to time-sensitive evidence, compared with simpler controls.
An experiment would hold fixed the same source-linked candidate set, the same evidence status, the same declared focus policy and the same task deadlines. It would then compare four conditions:
immediate delivery a conventional do-not-disturb setting plus a scheduled digest reader-managed notification preferences the proposed breakpoint-and-deadline policy Simulated tasks might include a meeting, focused coding, a known break, a meeting that overruns, and an item that expires while queued. In the study, the ground truth about deadlines and relevance must be judged independently. It must not be copied from the router’s own estimates.
Several outcomes should be measured separately: interruption count and timing, resumption time, task correctness, missed useful deadlines, false urgent alerts, policy violations, reader-initiated retrieval, and perceived control.
The experiment should also test the fallback when availability is unknown, when a candidate’s relation is unresolved, or when permission is revoked between qualification and delivery. Readers should be able to correct the rule. The study should then check whether the next decision changes in the intended scope, without treating clicks as endorsements.
Because this is a proposed experiment, it has no results yet. Deployment-critical real alerts should not be held back just to randomise a condition. The baseline to beat is not “interrupt for everything” alone. It is an ordinary, competent notification system with user controls.
This design has precedents, but they do not prove that it will work. Horvitz (1999) treated the timing, costs, uncertainty and user control of automated assistance as problems of mixed-initiative design. Iqbal and Bailey (2008) evaluated delivering notifications at task breakpoints and reported reduced frustration and reaction time in the tasks they studied.
Neither result shows that inferred calendar breaks, automatically judged semantic relations or this Radar policy will improve outcomes here. The distinctive claim to test is whether a source-linked, deadline-aware, user-authorised delivery record adds value beyond established notification controls.
Running it Running it. npm run example:radar makes delivery a separate decision. It does not take the chosen resolution as input.
In the constructed trace, a qualifying item that has already been prepared as a brief arrives during a meeting and is queued. After the meeting, it receives a new delivery revision rather than overwriting the old one. This trace does not demonstrate the delivery of Iris’s unresolved paper.
Tests also check that revoked permission and superseded results are withdrawn rather than delivered.
In this implementation, an unresolved relation is never pushed. It stays AVAILABLE for the reader to inspect on their own initiative. This strict rule is a tested boundary of the scripted example. It is not an inconsistency to be hidden behind a general theory of urgency.
The example uses declared or observed context with fixed values. An unknown value is refused, and an unobserved calendar does not imply that Iris is free. No optional override for unconfirmed deployment alerts is implemented or claimed.
What it does not show: the example does not involve any real scheduler, calendar integration, permissioned data access, delayed revalidation across elapsed wall-clock time, or measured user outcomes. The urgency/cost matrix and the strict unresolved-relation rule are declared design choices, not thresholds selected by experiment. The scripted decision revisions demonstrate bookkeeping and withdrawal. They do not show that Iris receives something at the right moment. The program also does not establish that readers inspect the explanations, or that a correction predicts a better future delivery decision. Those are questions for the proposed evaluation.
Where this leaves us Delivery is a decision separate from selection and resolution. A qualifying item may interrupt now, wait for a permitted break, enter a digest, or remain available. Qualifying for attention never grants permission to interrupt.
A defensible policy weighs delay against disruption. It keeps relevance, urgency and evidential standing separate. It honours explicit focus rules, treats unavailable context as unknown, and rechecks queued items before release. Each delivery decision should retain the source, rule, evidence and time context that actually determined it.
The example implementation demonstrates only a bounded, scripted subset of these requirements. Whether the architecture improves how attention is allocated remains to be tested.
The architecture now has a vocabulary for what, how much and when. It does not yet have evidence that it handles even one live item well.
The next problem differs in kind. Several qualified candidates can arrive together, each with its own deadline, uncertainty and claim on one person’s attention. Queuing one item may change the cost of delaying another. An exception granted for one standing interest need not apply to the rest.
The Personal Information Radar must therefore make these decisions together, without collapsing their reasons into a hidden score. It must also be accountable for the important things that never reached the reader.
References Horvitz, E. (1999). Principles of Mixed-Initiative User Interfaces. Proceedings of CHI 1999, 159–166. DOI 10.1145/302979.303030. (A design precedent for assistance timed under uncertainty and user control, not a validation of the Radar.) Iqbal, S.T. & Bailey, B.P. (2008). Effects of Intelligent Notification Management on Users and Their Tasks. Proceedings of CHI 2008, 93–102. DOI 10.1145/1357054.1357070. (Breakpoint notification experiments; not evidence for this chapter’s semantic relevance or delivery policy.)