# From Channels to Semantic Channels
# Book: Language
# Chapter URL: https://programmer.ie/books/language/18-chapter/
# Prose fingerprint (sha256, normalized): bb628a91372733e70af76a2cfce2ff7d36562e3b69ace4f3882858bca56e6faf
# 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 follows fourteen conferences, nine labs, thirty authors and four preprint feeds on distributed consensus. In this constructed example, a result appears in March in a distributed-databases paper by authors outside those channels. It describes a mechanism that operates under different timing assumptions from the ones her team adopted. The paper never uses the word “consensus”, so her usual alerts do not find it. In June she encounters it by accident, cited in a thread about something else. She has spent three months designing around an assumption that the unfamiliar result might help her reconsider. But might matters: another mechanism operating without a particular delay bound neither refutes her protocol’s safety claim nor shows that the mechanism transfers to it. Establishing either connection would take additional technical work.
Her subscriptions did what their channels were configured to do: deliver publications from selected sources. What they could not promise was to find work elsewhere that might bear on a specific assumption. Even a system watching the wider literature would have two separate jobs: discover the March paper, then determine whether its result actually changes anything about Iris’s design. The second cannot make up for failure at the first.
Most of this part has begun with an explicit question. Someone asked what matters in a talk or a collection, and the system selected information for that purpose. Iris’s concern about the assumption persists when she closes the browser. She could ask a system to inspect incoming material on her behalf, subject to a declared boundary. That does not make the system omniscient or authorise it to interrupt her. It raises a narrower question about the object of the standing request:
What would it mean to subscribe not to a source, a creator or a feed, but to a relationship in the world?
What people subscribe to now The objects people subscribe to today are familiar:
a creator a publication a topic a feed a keyword Each is a useful but coarse contract. Following a creator admits what that creator publishes; it does not promise to find relevant work elsewhere. Keyword alerts depend on the language chosen by authors and indexers. Topic feeds can use richer classifications, and a well-configured search alert can be remarkably effective, but none of these by itself requires a testable claim about how a new item bears on one particular assertion. The gap is not that existing channels are foolish. It is that finding material about a subject and finding evidence that changes a specified relationship are different tasks.
The earlier chapters provide a vocabulary for expressing that second task. Part I distinguished textual similarity from source-supported relations: one claim may support, qualify, contradict or supersede another, and those labels require scope and evidence. A standing interest can be expressed as a query for a particular kind of relation to a named anchor. The architectural ambition is to reuse the same discipline as new material arrives, not to assume that relation labels have become reliable merely because they have names.
typed relation ↓ standing relational query ↓ semantic channel The difference is the one between two questions:
topic subscription ≠ relationship subscription A topic subscription asks which new items belong to, or discuss, X. A semantic subscription asks which newly observed items might support, qualify, contradict or supersede a specified claim about X. The answer is initially a candidate with an evidence trail, not a determination that the reader’s understanding should change. Whether it actually changes belongs to further examination by the reader or an appropriately validated process.
A small object The declarative meaning of a semantic subscription can start with four fields. Keeping those four visible makes the request understandable; it does not mean an operational system can dispense with source identities, permissions, versions or an audit history.
ANCHOR what the subscription is about RELATION what kind of change or connection matters CONDITIONS when something qualifies EXCLUSIONS what should not trigger it Here is Iris’s, written out:
ANCHOR this protocol's stated safety claim (in the approved specification, including its scope) RELATION contradicts, or weakens an assumption of CONDITIONS a newly observed, peer-reviewed result with evidence that bears on the stated timing assumption EXCLUSIONS tutorials duplicate reporting pure opinion This is more specific than “subscribe: consensus algorithms”, but specificity does not solve discovery. To match the March paper, the system first has to encounter it through a permitted collection, search or citation trail. It then has to connect a claim in that paper to Iris’s versioned anchor, checking whether the timing model, failure assumptions and claimed property are comparable. The relation-first query tells the system what evidence to seek and how to assess a candidate. It does not guarantee that unseen evidence will be found.
An anchor should therefore identify the actual claim and source version, not merely a topic label or a document title. If the specification changes, the old watch must not silently acquire a new meaning. It should be marked for review, migrated with explicit approval, or retired, while preserving a record of what the earlier watch was asking.
Three more, to show how different these are from topics:
"Tell me when a new result weakens the assumption that this protocol needs bounded network delay." "Show me new evidence that contradicts the causal claim in this paper." "Tell me when this API's recommended practice is superseded." These are standing relational interests rather than ordinary topic labels. Each asks for a potential change affecting a declared anchor, and each has a different evidential burden. Contradicting a causal claim requires comparable populations, measures and conditions. Superseding an API practice requires an authoritative version history, not merely a newer blog post. Weakening an assumption may mean providing a relevant counterexample or a workable alternative, neither of which automatically falsifies the original result. The interface must say which claim is being made and which remains conjectural.
Delivery is deliberately absent from those four semantic fields. A subscription determines what may qualify for consideration; another policy determines whether a candidate should be made available, included in a digest or delivered now. Keeping those decisions apart matters: a possible contradiction can be important without being confirmed, and a confirmed update can be important without being urgent. The next chapters address amount and timing.
Conceptual guide to the chapter; no new empirical result is asserted. Open full-size diagram. Subscriptions are not recommendations Recommendation systems sit nearby, and the difference is worth being exact about.
RECOMMENDATION the system infers what you may want SUBSCRIPTION the person declares what relation should matter A recommender typically chooses items predicted to be useful or engaging, sometimes using behaviour and other context. A semantic subscription instead starts with a relation the reader explicitly declares. The two approaches can share retrieval, ranking and modelling techniques; they differ in who sets the criterion and what counts as success. Iris can ask to see evidence that challenges her design even if she has never clicked such material before. But this does not guarantee that a relation-based search will discover material a conventional search would miss. A strong keyword or hybrid-search alert remains a baseline the semantic channel must beat, not a straw man.
Matching is not confirmation The discipline from Part I carries forward. Finding a paper is candidate discovery. Recognising passages that could connect it to Iris’s anchor is relation proposal. Establishing that the passages really share the relevant assumptions and support the asserted relation is a further evidential judgement. None of these stages may be silently substituted for the next.
candidate found ≠ relation established ≠ claim verified A standing query may yield an unconfirmed candidate. It should then say, for example: Possible challenge to the bounded-delay assumption; applicability to this protocol unresolved, and show the two passages on which that assessment rests. “Possible” and “confirmed” are not probability decorations: they should refer to explicit review states and the basis for each state. A person confirming that two texts are related has not thereby certified either underlying technical claim. If a match is unsupported, the system should decline the stronger label rather than presenting uncertainty in confident typography.
Scope is where this becomes difficult. A paper about another protocol, another fault model or another timing assumption may offer an analogy, an alternative design or a genuine counterexample. Those are not interchangeable relations. In distributed systems, even “bounded delay” can refer to different models; the classic work on partial synchrony distinguishes bounds unknown in advance from bounds that hold only after an unknown time. More importantly, an assumption used to prove progress need not play the same role in a safety guarantee. The system has to identify which property, under which assumptions, the incoming evidence bears on. Iris’s March paper is a reason to investigate, not an automatic refutation. Peer review, where required by the subscription, is an eligibility condition, not a guarantee that the result is correct or applicable.
A standing query is not an all-seeing search There is an older engineering precedent here. Continuous query systems register a declarative query and evaluate it as a stream changes; Arasu, Babu and Widom’s CQL is an example. The new question in this book is not whether a query can persist. It is whether the predicate can be a useful, source-grounded relationship between claims while preserving the limits of extraction and interpretation.
A practical channel has at least three independently fallible stages: coverage (which permitted sources were actually observed), candidate discovery (which observed items were retrieved for consideration) and relation assessment (which proposed links survived scope and evidence checks). A failure in the first two cannot be repaired by a perfect relation classifier. A label that looks plausible cannot repair a bad scope comparison. An alert should be able to say what it searched and what it cannot claim to have searched. A promise to monitor “the world” would be indefensible; a promise to monitor named feeds and searches, with declared limits, could be audited.
An interest is not a profile The last chapter introduced a narrow, corrigible estimate of prior knowledge. Here the system needs a different object: an explicit request to monitor an anchor for a specified relationship. The request must not be inflated into a claim about the person’s tastes, identity or beliefs.
standing subscription ≠ profile of the person explicit standing interest ≠ inferred identity Iris can subscribe to “possible changes to the assumptions in this specification” without licensing a general profile of her interests. She should be able to inspect, pause, edit, expire and delete that request, and to see its original wording beside any machine-compiled query. Compilation may expand synonyms or follow citation paths internally, but it must not silently change the conditions that qualify an alert. The operational record should show who authorised the watch, which version of the anchor it targets, when it last ran, what sources were covered, and why each reported candidate matched. Access to the subscription and its resulting items must follow the underlying document permissions; even a title or the existence of a match can reveal a restricted project.
How a semantic channel goes wrong The semantic request is small. Its failure surface is not. Besides the mistakes of ordinary alerts, a standing relational query can fail during discovery, interpretation, maintenance or delivery. Those failures need separate names because they need different remedies.
too broad floods her with weak candidates too narrow misses consequential material coverage gap never encounters a relevant source wrong relation mistakes analogy or similarity for contradiction scope error ignores differing assumptions or claims stale anchor monitors an outdated claim or source version silent expansion changes the declared watch without approval permission error reveals restricted content or even its existence Silent expansion is a particularly serious governance failure: the machine stops executing the reader’s standing request and substitutes another. But the most difficult technical failure may be the invisible miss. A poor alert is noisy; a missed paper may leave no trace in the reader’s view at all. The subscription therefore needs a maintenance policy: explicit edits rather than covert broadening, an expiry or review point for stale anchors, and enough information about monitored sources and recent runs to expose coverage limits. Pausing and deleting the request must stop future monitoring. None of those controls proves that the watcher saw every relevant result.
Testing whether relational subscriptions earn their cost The claim to test is not that the interface can store four fields. It is that a declared relational watch finds consequential changes with fewer harmful misses or distractions than simpler alternatives. A proposed test would freeze a set of versioned anchor claims at a historical cutoff, then replay only material published afterwards. Human reviewers, blind to the method that retrieved each item, would adjudicate which later sources genuinely bear on each anchor, which relations are supported, and where applicability remains unresolved. Disagreements and genuinely uncertain cases would be retained rather than forced into a single label.
Run at least four conditions over the same accessible corpus and time window: ordinary feed and author alerts; carefully written keyword and citation alerts; a strong hybrid-retrieval alert; and the proposed typed-relation channel. Include a manual expert-review workflow as a practical reference. Compare candidate recall (especially consequential misses), precision of the proposed relation and its scope, time-to-discovery, duplicate and false alerts, reviewer effort, and unsupported claims presented as established. Separate a retrieval failure from a relation-labelling failure. Use held-out anchor versions and later sources, not examples used to construct the watch. A system that improves relevance among already-retrieved documents but misses the March paper has not solved the opening problem.
This is a proposed experiment, not a reported result. The baseline may win. That would tell us whether typed subscriptions add anything beyond well-maintained conventional alerts, and at what cost.
Running it Running it. The reference example, npm run example:radar, represents a subscription with an anchor, relation, conditions and exclusions. Its written condition asks for a “new, peer-reviewed result”. A retrieved preprint addressing the same claim does not satisfy that condition, and the program records the reason rather than silently changing the user’s request to include preprints. If Iris wants them included, that is a new authorised condition. A retrieved example of another mechanism working without a delay bound also remains an unresolved relation, because the supplied evidence does not establish that its result applies to her specific anchor. In the tests, a model’s assertion alone cannot serve as that missing bridge. These are checks on the supplied case and the program’s control flow, not a successful literature-discovery run.
What it does not show: successful discovery of the hypothetical March paper, reliable classification of relations, or an improvement in what a reader learns. The candidate relations and relevant source material in the example are supplied rather than found independently. The example also does not implement the complete reader-facing list of standing interests or demonstrate the proposed no-silent-expansion guarantee across an evolving watch. Its refusal cases are useful software tests, but they are not measurements of missed relevant papers or false alerts.
Where this leaves us A semantic channel is a standing request about the relation between new material and an explicit anchor, not simply a subscription to an author or topic. Its four semantic fields name the anchor, relation, conditions and exclusions; its operational machinery must additionally respect source versions, coverage, permissions and change history. Matching returns candidates with provenance and a review state, not automatically established changes in the world. Declared interests should remain legible and editable, while discovery failures and omitted items stay part of the system’s evaluation rather than vanishing from the account.
That settles the shape of the standing request, not its value as a service. The query may find nothing because there is nothing to find, because its conditions are too strict, or because the system never saw the relevant paper. And even a well-supported match does not tell the system when or how it should reach the reader. Qualification and delivery remain separate decisions:
qualifies ↓ candidate for attention ↓ delivery decision A possible challenge found at three in the morning is a candidate for attention, not automatically an emergency. It may call for a short notice, a reviewable evidence bundle, a place in the morning digest or no interruption at all. Confidence in the relation, consequence of delay and the reader’s delivery policy must remain distinct. The next question is how much of a qualifying item should reach her first.
References Arasu, A., Babu, S. & Widom, J. (2006). The CQL Continuous Query Language: Semantic Foundations and Query Execution. The VLDB Journal. (Precedent for declarative queries that run continuously over incoming data streams; not evidence that semantic relations can be classified reliably.) Dwork, C., Lynch, N. & Stockmeyer, L. (1988). Consensus in the Presence of Partial Synchrony. Journal of the ACM, 35(2), 288–323. (Background for the distinct timing assumptions used in the constructed example.)