# The Personal Information Radar
# Book: Language
# Chapter URL: https://programmer.ie/books/language/21-chapter/
# Prose fingerprint (sha256, normalized): 088588b99a727404df43c291e14f9941c1826458ac1a668024476db273c7b426
# 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.

Iris’s afternoon begins at 14:40. She is presenting in a design review that runs until 15:30, and a deployment is scheduled for 18:00. Four items have arrived in the sources she has explicitly authorised the system to watch. Her declared focus rule permits interruption for verified blockers affecting an active deployment; unconfirmed research relationships must remain available for her to inspect, not be pushed. The Radar—the name this part gives to the attention side of the same Language layer built in Part I—has to decide what to do with each item without assuming that noticing it would help.
A a new paper that possibly weakens the bounded-delay assumption B a major update to a library she uses often C an interesting new survey of consensus protocols, mostly material she knows D an incident report affecting tonight's deployment Part I ended with the Semantic Browser: a source-linked way to choose and check representations for a task. This chapter assembles the corresponding attention architecture across changing sources. Its question is: what should reach a person, in what form and at what moment, when more candidates arrive than she can inspect? The radar metaphor is useful because its coverage is bounded, its detections are uncertain and most signals do not warrant an alarm. It becomes dangerous if the system treats the person as the object of surveillance. The proposed Radar watches authorised information sources and declared interests, not Iris herself; any context used for delivery needs a separate permission and purpose.
What the Radar is made of The stages are the ones the part has built, but their order is not a one-way ranking. Permission and source coverage constrain what enters; a source-linked unit may have to bring its qualifications with it; delivery decisions must be reconsidered when a deadline, source or policy changes. The diagram is a proposed decision path, not a claim that the current application implements every stage:
AUTHORISED SOURCES + COVERAGE RECORD ↓ discover, deduplicate, identify versions ELIGIBLE CANDIDATES + INFORMATION UNITS ↓ preserve source claims and dependent qualifications STANDING INTEREST / CURRENT TASK + PROPOSED RELATIONS ↓ relevance, evidential standing, prior-knowledge evidence ATTENTION QUALIFICATION ↓ select a source-faithful resolution (or keep source unchanged) DELIVERY PERMISSION + FRESHNESS + DEADLINE / CONTEXT ↓ NOW · QUEUE · DIGEST · AVAILABLE · WITHHOLD READER (noticing, use and benefit remain unobserved) ↺ corrections or changed evidence reopen the affected decisions This is not a ladder that increases a candidate’s universal importance score. Each stage makes a different claim, under a different kind of evidence: it may decide that an item is outside a subscription, that its relation is unconfirmed, that its qualification cannot be omitted or that Iris has not authorised an interruption. Some gates are hard constraints, not preferences to average away. An implementation may use numerical estimates within a gate, and it will need explicit tie-breaking when several authorised alerts compete. But no final scalar should erase which decision was made, under which rule and with which uncertainty. The proposed record has decision dimensions plus an audit envelope, not merely a priority number:
Proposed decision path. Each stage answers a different question; no final scalar should erase which decision was made, under which rule and with which uncertainty. Open full-size diagram. candidate_id + source_id + source_version coverage which permitted source and scan exposed it eligibility permission, freshness, deduplication and scope relation proposed link to a declared interest or task relevance why it bears on the current purpose necessity claims and qualifications that must travel together novelty evidence about this reader's knowledge, or unknown standing source quality and relation status kept separately urgency deadline and consequence of delay, or unknown interruption authorised policy and estimated cost now resolution source-linked view or unchanged source mode NOW · QUEUE · DIGEST · AVAILABLE · WITHHOLD reasons evidence and rule version for each decision history changed facts, corrections, refusals and delivery receipts A single score makes sorting convenient; it does not make an account of a decision. The record must be able to explain why a highly relevant but unconfirmed paper was not pushed, why a seemingly familiar definition remained visible and why a confirmed deployment blocker could interrupt. It must also say when a required field is unknown. An unspecified calendar is not evidence that Iris is free; an absent knowledge record is not evidence that she knows nothing. The distinctions throughout Part II survive only if the final router keeps them visible:
high urgency ≠ high confidence high relevance ≠ high novelty high novelty ≠ safe to interrupt low novelty ≠ safe to omit An urgent item with weak evidence, a relevant item Iris may already know and a familiar prerequisite she still needs are not interchangeable. The record also makes revision possible: correcting a relation should not silently rewrite novelty evidence or grant notification permission. A correction changes the affected decision, with a versioned reason, while earlier decisions remain inspectable.
Four candidates, four records Consider a constructed policy at 14:40. All four candidates, their apparent relevance and their delivery outcomes are invented to expose the distinctions; there is no observed Iris or real notification. In this illustration, the subscription, source access and interruption rule are declared in advance. The records below abbreviate the fuller audit envelope; any unspecified value is unknown, not silently favourable.
A new paper concerning a bounded-delay assumption source standing: peer-reviewed in this constructed case relation: possible weakening; applicability to Iris's protocol unresolved task relevance: potentially high novelty: provisionally high resolution: source-linked brief, labelled candidate delivery: AVAILABLE (reader-initiated; no push of unresolved relation) why: evidence about another mechanism does not prove a contradiction B major library update declared interest: library releases relevant to her work task relevance: low for the deployment, absent evidence of an impact urgency: no current deadline established delivery: DIGEST, subject to source freshness and active permissions C new survey, mostly familiar by the example's assumed knowledge evidence novelty: one potentially new classification of delay models preservation: retain definitions needed to interpret that classification resolution: GLANCE, with direct access to the underlying section delivery: AVAILABLE; do not suppress solely for low estimated novelty D verified blocker affecting tonight's deployment (constructed) relation: directly linked to the current deployment; evidence inspectable task relevance: high urgency: high before 18:00 permission: Iris opted in to immediate alerts for verified blockers resolution: short notice plus unchanged incident source delivery: NOW, after freshness and authorisation checks Candidate C illustrates why estimated familiarity is not permission to remove source-specific meaning: the new classification remains reachable with its definitions. B qualifies under a standing interest without becoming urgent for the current deployment. A is different again: even an interesting, peer-reviewed paper may have an unresolved relation to Iris’s own safety argument. The subscription can help her discover it, but the strict delivery policy of Chapter 20 leaves it AVAILABLE until she requests inspection. D can interrupt only because both the operational evidence and her explicit exception rule warrant it. None of these example labels is a result of measured relevance or real-model classification.
When two items compete At 14:40 both A and D could matter, but only D qualifies for an interruption under the declared policy. Assigning them imaginary priorities such as 0.91 and 0.84 would obscure that difference. The Radar must first respect the permission gate and the status of each relation, then explain how the remaining delivery choice was made. If two permitted blockers arrive together, a documented deadline and deterministic tie-break rule can order them without claiming that one opaque score has settled every trade-off.
D interrupts because: - a verified blocker bears directly on the active deployment - Iris authorised immediate notices for this class of event - waiting until her next break may remove the chance to respond - source, deadline and permission were checked for this decision A remains AVAILABLE because: - its relation to Iris's protocol is unconfirmed - her rule does not permit pushing unresolved research relationships - she may request the brief and inspect both sources at any time In the constructed sequence, the verified blocker is presented at 14:41 with its reason and source link. Iris can inspect or dismiss it, but the example does not assume that she did so or that it improved the deployment. The paper remains in her available list; at 15:35 she could choose to open its source-linked brief after the review. That is reader-initiated access, not a notification that the scripted system claims to schedule. Before any queued or scheduled item is actually released, the source version, relation, deadline, permission and current policy would need to be checked again. B awaits an authorised digest; C remains accessible. The trace explains dispositions, not observed human behaviour.
What the Radar has not seen An integrated selector creates a special kind of hidden failure: when Iris sees nothing, she cannot tell whether nothing qualified, whether the system judged something irrelevant, or whether the source was never within reach. A coverage report must therefore separate observed and processed, observed but rejected, failed to retrieve and outside the configured scope. It cannot list the identity of a paper it never observed, and it must not reveal the existence of material she lacks permission even to know about.
not surfaced may mean: - observed, but failed a declared eligibility or relevance gate - observed, but judged familiar (with potentially mistaken evidence) - accepted, then held in QUEUE / DIGEST / AVAILABLE - withheld under a stated authorised rule - a configured source or scan failed - the source was outside the configured coverage - the system never encountered it (unknown, not a logged rejection) The last three are limits of observation, not findings about relevance. Even a flawless relation classifier cannot discover a paper that never entered its candidate set, and a successful query cannot establish that no relevant paper exists elsewhere. Conversely, an item rejected by a gate was observed and should be auditable within the reader’s permissions. The system can report source lists, query windows, last successful scans, failures, missing intervals and counts by stage; it cannot describe unseen items individually. Hence:
not selected ≠ does not exist radar coverage ≠ the world This is the danger of a polished Radar: silence starts to feel like evidence. Iris should be able to inspect what the system was authorised to watch, when it last checked, how many candidates it examined, which permitted candidates were rejected or deferred and which scans failed. A coverage statement should distinguish not found in the observed set from not present in the world. Audit logs themselves need access controls and bounded retention, because titles, subscriptions and rejection reasons can reveal information. The system should make uncertainty and gaps visible without offering an impossible guarantee of complete discovery.
A correction that changes policy, not the person At 15:40, while reviewing her declared notification settings, Iris adds a rule: “Don’t interrupt me for library releases unless they affect an active deployment.” This is a preference she is free to state even though candidate B was routed to a digest, not an interruption, in the earlier example. What happens to the rule is more interesting than why she chose it.
The proposed system stores this as a scoped, versioned rule on library-release delivery. It can require evidence that a release affects an active deployment before using the exception. It does not infer that Iris dislikes software releases, nor does it promote the observation into an account of her personality. Nor may it silently override a stricter do-not-disturb rule with this more general preference: the applicable permissions and policy precedence must remain explicit.
correction → policy refinement correction → not a conclusion about the person The changed rule is visible and reversible. Its receipt identifies what Iris said, when it applies, which prior rule it replaces and whether any queued decisions need to be revisited. Corrections to relevance, evidence standing, novelty and interruption belong to separate gates. This is also an admission-control boundary familiar from context and memory systems: observed behaviour is evidence for a possible proposal, not permission to write a new standing instruction. A single thumbs-down could not say which judgement was wrong, and even an explicit correction should not expand beyond its stated scope.
Adaptation without an unrestricted model A broader principle has emerged through Part II, and the Radar makes its architectural form visible. Instead of allowing all observed activity to accumulate into a general personal profile, the design uses several narrow, purpose-bound objects:
knowledge state ≠ dossier explicit standing interest ≠ inferred identity observable context ≠ inferred inner state In the imagined system, the knowledge model holds evidence about particular concepts and senses, not general claims about Iris’s intelligence. Standing subscriptions record what she chose to watch. An interruption gate may use a calendar signal only if she authorised that use, and does not need her meeting’s contents in a lasting profile. The Radar does not need to infer her mood, politics or character to make these proposed decisions. The design hypothesis is that useful attention adaptation can be achieved with bounded, inspectable state rather than an unrestricted personal model. The constructed afternoon illustrates the hypothesis; it does not demonstrate performance, privacy compliance or an absence of unintended inference.
What the selected alert says A candidate can be correctly selected and badly delivered. Suppose, in a constructed example, a paper reports a performance improvement only under one evaluation condition. The Radar finds a genuine relationship to Iris’s task, but its alert says simply “the method improves performance”. Source interpretation and relevance selection may have succeeded while the delivered claim loses its scope. Chapter 8’s A/B comparison could propose that difference for review before the alert is queued or shown.
That comparison supplies evidence for a delivery decision, not notification permission or proof of benefit. It should retain the qualification or offer the source when a short alert cannot carry it. A later answer can be examined against Iris’s actual question; a click alone establishes neither comprehension nor value. The existing deterministic feed screen has not demonstrated this transcript or paper-analysis path.
What the architecture has not shown This is a proposed architecture, not evidence that its integrated judgements are correct. Its components may introduce correlated errors: one misclassified relation can determine selection, resolution and delivery, producing a consistent but misleading experience. An unknown deadline can quietly become “not urgent”; an out-of-date knowledge estimate can hide a needed definition; a correct source-link can point to an incorrectly interpreted claim. A hostile source may even contain text instructing the model to change its watch or delivery rules; source content is data, not authorisation, and must not cross that boundary. More candidates also create contention and duplication that the four-record illustration does not test. The decisive comparison is against competent, simpler systems, not only a firehose of unsorted alerts. That requires a measured programme.
Testing the Radar as a whole A first, proposed offline study would freeze a permissioned corpus of source snapshots and timed arrivals, with duplicate reports, conflicting accounts, expiring deadlines, ambiguous relations, irrelevant near-matches, instruction-bearing hostile source text and critical items outside some monitored sources. Independent reviewers would label the questions each item actually bears on, its evidential standing, its required qualifications and the consequences of missing or delaying it. The Radar would not see these labels. Compare a chronological feed, a strong keyword-and-source filter, reader-configured alerts with ordinary do-not-disturb and digests, and the proposed stage-based Radar. Ablations would remove typed relations, knowledge estimates or preservation gates one at a time.
Report consequential misses, false urgent alerts, precision at a fixed attention budget, source and qualification fidelity, latency, duplicate burden, policy violations, retraction handling and coverage gaps separately. A second, consented task study would examine whether people actually noticed, correctly interpreted and used the material, whether interruptions harmed work and whether stage-specific corrections helped; presentation receipts alone are not observations of attention. Finally, a limited shadow-mode study on live streams could compare proposed routing with what existing tools delivered, without withholding deployment-critical messages. These are designs to run, not studies the book has completed. Closed-world labels cannot certify discovery in an open world, so a live report must retain an explicit coverage boundary.
The outer edge in use There is a smaller application with an observed run beside that design. Too Much YouTube (tmy) screens my YouTube subscriptions against a purpose file. In its first live run on 15 October 2026, it resolved 195 subscriptions, read 195 public feeds and screened 169 videos from the preceding week. A broad deterministic rule surfaced 49; a tightened rule surfaced 19. Those are counts from the run recorded for this book, not independent measurements of relevance. We do not yet know whether the 19 contained the most useful videos or which consequential items either rule skipped. The numbers establish that the rule changes altered selection, not that the narrower rule improved it.
The input is deliberately limited to each video’s title and the first 500 characters of its description. The file against which these are matched contains a declared purpose, terms, exclusions and a field labelled as known material. An assistant initially drafted that file from my work; publication in a file makes the draft reviewable, not automatically authorised or correct. The deterministic rules can compare words and exclusions. They cannot determine whether a talk’s decisive claim is at minute 53, what its speaker actually demonstrated, or whether a familiar phrase is understood. This is metadata screening, not the transcript decomposition or knowledge estimation proposed in Chapters 14 and 16.
Each screened video gets a disposition—LOOK, AVAILABLE or WITHHELD—and a recorded reason, and the digest retains the other categories for review within the configured access scope. The run also reports feeds and entries it could not retrieve, the publication window, and the possibility that a public feed omitted older videos in that window. A record of 195 successful feed reads therefore does not imply complete coverage of those channels, let alone all YouTube. Showing the withheld list is useful for auditing the items actually observed; it cannot expose videos outside the scans or justify revealing unauthorised source metadata.
This is the Radar’s outer edge in practice: a finite configured source set, a visible screening rule, recorded dispositions and a declared coverage limit. It is also a useful deterministic baseline for the proposed experiment, because it can be replayed on a frozen feed snapshot before more elaborate relation models are introduced. Its command and code are described in tmy/README.md; the invocation begins npm run tmy -- scan, with subscriptions and purpose supplied explicitly. A reproducible comparison would retain the exact input snapshot and both rule versions, then independently examine some of the kept and withheld videos rather than reporting a shorter foreground list as success.
It does not implement the full Radar. It does not read transcripts, identify timestamped units, detect relations across papers, check semantic subscriptions, choose preservation-checked resolution levels or schedule permission-bound interruptions. It uses a declared known-material list, not an evidence-backed knowledge model, and it makes no real-model calls. Neither the reduction from 49 to 19 nor the existence of a reason per item establishes reader benefit, correct selection or a safe omission policy. An immediate next test is to adjudicate a frozen subset of the 169 observed videos, including omissions, and compare both rules at the same attention budget. Evidence of missed relevant videos matters more than aesthetic quality of the digest.
There are three distinct artefacts here: the conceptual Radar decision dimensions, the scripted Pi example’s typed stage trail, and the live tmy screening ledger. They share design principles but not an implemented end-to-end schema, and results from one do not validate the others. Keeping those boundaries visible is an important part of this capstone: the live edge establishes that a bounded real source stream can be screened and audited at the metadata level; the integrated selection and delivery claims remain hypotheses.
Running it Running it. npm run example:radar exercises a separate, invented afternoon on a Pi host with a scripted stand-in for the model; it does not call a real model. Its five constructed candidates are a preprint, a different mechanism, a qualifying contradiction, a brief that drops a qualifier and a keyword-stuffed decoy. The run prints each stage’s typed decision and reason, meeting-end delivery revisions and a source-coverage boundary. It is a software trace designed to test refusals and bookkeeping, not a replay of Iris’s four candidates or the YouTube scan.
What it shows: the scripted decisions can be routed and refused without an opaque total-priority score; a stage can report why it refused an item, and a later event can produce a revision rather than rewriting the past. Separate receipts for admitting material to a model’s context and presenting something through an interface demonstrate a crucial distinction from Context: information reaching the model is not information reaching the human. A presentation receipt proves that a presentation call occurred. It does not prove Iris noticed, understood, used or benefited from anything. The strict unresolved-relation policy described in Chapter 20 still applies to this scripted example.
What it does not show: reliable candidate discovery, real-model relationship judgements, actual scheduled delivery, a validated unified decision schema, human reconstruction or superiority over a chronological feed. No closed-world end-to-end comparison was run. The stage trail’s typed reasons and revisions overlap with, but are not identical to, the conceptual record, and some conceptual obligations are not executable gates in this demonstration. It says only what configured inputs and supplied scripted cases permit it to say. This should not be conflated with the live tmy run, which has real input but much less machinery.
Where this leaves us Part II has brought a set of independently risky decisions between abundant information and a finite reader. What is the information unit? Which claims and conditions must stay together? What matters to the current task, what may be new to this person and what relationship has she asked to watch? How much should reach her, and does she permit it to arrive now? The proposed Radar keeps these decisions separate, source-linked and revisable. The channel now has a role not only in how something is said, but in whether, when and on what authority it is allowed to enter the reader’s view. Whether that architecture improves decisions beyond competent simpler tools is still an experimental question.
In the constructed afternoon, Iris has authorised sources, subscriptions and an interruption rule, and the system has proposed dispositions without taking any operational action for her. A live system could accumulate a history of her corrections, requests and responses, but that history is not automatically permission to build a personal model. Even the difference between a declared rule, a recorded click and an inferred preference would need to remain visible. Choosing what reaches her creates the possibility of memory, not the right to use every observation as memory.
Part III begins at that boundary: what can persist from one encounter to the next, under whose authority, and how can Iris see, contest or remove an inference? The Radar has not solved personalisation. It has made clear why a system that remembers its encounters needs a stricter account of declaration, observation and inference than an attention filter alone can provide.