You suppress a mild item on Monday. By Thursday, implementations are shipping, a first-party engineer has confirmed the idea, and the window to act or write has already narrowed. Or the reverse: something looks hot, you interrupt yourself, and it dies as rumour by Wednesday.

The failure is not “bad ranking.” The failure is assuming significance is a property you can freeze at arrival.

News-shaped information — posts, threads, release notes, incident updates, even calendar-adjacent email — does not behave like a static PDF. Its meaning is always as-at now, and “now” keeps moving as evidence, influence and time arrive. A system that scores once and routes forever is optimising for administrative neatness, not for understanding.

News-shaped information cannot be judged once at ingestion, because its significance keeps changing after you observe it.

The surface complaint and the real bug

What people say they want is simple: signal, not noise. What they ship is usually a FIFO feed, a one-shot interestingness score, or a keyword alert list. Those tools answer:

What arrived, and how does it look against a static filter?

They do not answer:

Which unfinished stories might change what I should believe, do or publish — and when is looking again worth the cost?

The cost of the wrong question is familiar. Either you interrupt yourself for everything (attention death), or you suppress once and miss slow burns, late corroboration and the quiet item that mattered three days later. Both failure modes feel like product bugs. They are architecture bugs.

Significance is not a quality of the item

Interestingness, in the judgment layer this queue feeds, is already a relation between an item and your compiled worldview — not a property of the tweet. That doctrine lives in the newsfeed work: four diff classes (contradicts, independently converges, genuinely novel, already known), an interrupt budget, an append-only signals log. This book does not re-teach that judgment vocabulary. It adds the missing temporal dimension: items whose meaning keeps moving after first observation.

So the problem is not only “is this novel relative to my map?” It is also “is this still unfinished, and has the world changed enough that I should reprice it?”

Same information, different clock: the booking

The email-agent upgrade makes the temporal mismatch obvious. You book something last week. Telling you then is noise — you already know you booked it. An hour before the appointment, the same fact is signal. A time change is signal. A cancellation is signal. One-shot significance at ingest either spams you at booking time or fails when the case becomes actionable.

That is not a separate product architecture. It is the same engine: a case whose revisit priority rises as calendar urgency and uncertainty combine. News radars, email agents and ops incident queues share the clock problem even when their sensors differ. The rest of this book uses an AI-news radar as the flagship domain; the booking is the reminder that the doctrine transfers.

What one-shot systems optimise

One-shot ingest pipelines optimise administrative neatness: every item gets a score, a lane, and a closed ticket. That feels like control. It is control over the process, not over understanding.

Understanding requires open files. Detectives keep cases open. Analysts keep watchlists. Good editors keep pieces in draft until the story lands. Attention systems that force every observation into a permanent disposition at T0 are optimising the wrong success metric — closed tickets rather than justified wonder.

What this book owns

This ebook codifies the signal-case queue: an attention architecture that keeps unfinished understanding alive, continuously reprices it against an accumulating wiki, and schedules re-observation so cognition is spent where new information is likely.

After these chapters you should be able to:

• separate two memories (wiki vs queue);
• choose the case grain (not the post, not the timeless concept);
• promote mutable anchors without deleting bronze;
• schedule re-observation with an explicit priority formula;
• treat expected non-arrival as evidence;
• materialise a rebuildable temporal working set;
• write a case-boundary lifecycle contract.

What this book deliberately does not own: how source influence is learned from receipts (that is the Cascade Ledger), or how to evolve the design with replay harnesses (Replay-Driven Design Evolution). Those are siblings in the same run. Name them; do not smuggle them in as chapters.

If significance has a clock, the system needs two different forms of memory. Collapse them and you either lose durable understanding or lose unfinished attention.

Memory one: the wiki is accumulated understanding

The wiki holds the relatively durable model of:

• what you already know and believe;
• frameworks and claims;
• people, companies and technologies;
• previous signals and historical context;
• why something matters;
• contradictions, convergence and provenance.

When a new observation arrives, the wiki answers:

What does this mean in my world?

That is the semantic substrate — the same family as a wiki-graph kernel and a durable memory tier outside model weights. It is not a dump of raw tweets. It is compiled relationships and conclusions agents and humans can both walk.

Memory two: the queue is unresolved attention

Everything new may enter the queue, but the queue does not exist to store articles forever. It holds things whose final significance is not yet known.

A weak signal might begin as:

Karpathy mentions persistent agent memory
Status: weak signal
Current interpretation: converges with Wiki Is the Kernel
Confidence: medium
Action: watch

Over the next few days, evidence accumulates — related architecture posts, GitHub implementations, community reports, first-party comments — and the same queue object moves through maturity:

NEW → WATCHING → CORROBORATED → ACCELERATING → IMPORTANT → RESOLVED

At each pass, the system rereads the case against the current wiki and its newly accumulated evidence. Ingestion does not require immediate final judgment. That is the entire point of the second memory.

The defining formulation

The wiki holds what we currently understand. The queue holds what we have not finished understanding.

And the product-facing compression:

The wiki knows. The queue wonders. The briefing renders what is worth considering now.

Not a second knowledge base

The queue must not become a rival ontology. It is a live projection over open signal pages in the wiki — the active frontier.

The wiki contains people, posts, concepts, edges, historical interpretations. The queue contains only what is still unresolved, moving, or worth revisiting: pointers, heat, uncertainty, next review times, which neighbourhood of the wiki to load.

You cannot walk the whole wiki every hour to discover what is trending now. That is the queue’s job: a different interface into the same data, organised by signal and intention rather than by permanent topic hierarchy.

Observe → ingest → interpret against wiki → queue →
gather more signal → reinterpret → route → write back

The feeds supply observations. The wiki supplies context. The queue gives developing significance somewhere to live.

How this sits on prior doctrine

Interestingness-as-diff still judges how an item changes your map. The signals log still prevents re-alerting on the same theme. The interrupt budget still makes silence expensive to break. Those are the judgment and delivery layers.

This chapter’s claim is narrower and load-bearing: judgment needs an open working set. The newsfeed ebook taught you how to judge and when to interrupt. This book teaches you what to keep open while judgment is still premature.

Queue outcomes without premature certainty

A signal can eventually:

• disappear as noise;
• remain on watch;
• enter a weekly review;
• trigger an immediate alert;
• generate a publishing draft;
• produce a proposed wiki update;
• become resolved historical context.

The important point is architectural: ingestion does not require immediate judgment. You ingest evidence, update the wiki where justified, and keep uncertain significance alive until the world supplies more information — or until time itself is information.

A FIFO queue pretends the next item to process is the next item that arrived. Significance does not work that way. An observation can be noise at T0 and load-bearing at T3. Treating arrival order as priority order is how personal intelligence systems become either firehoses or blind spots.

Repricing as-at now

An incoming item may be unimportant when first observed and become important because:

• more independent sources corroborate it;
• a first-party source confirms it;
• influential people begin responding;
• discussion velocity accelerates;
• it starts affecting one of your active technologies or arguments;
• it contradicts something in your canon;
• a newsjacking or action window is closing;
• nothing further happens and it decays.

So the queue is more like a market:

New evidence arrives
        ↓
Attach it to an existing signal or create a new signal
        ↓
Re-evaluate what the signal means against the wiki
        ↓
Reprice its relevance, confidence, influence and urgency
        ↓
Keep watching, surface, publish-draft, resolve or expire

The item is not permanently assigned “interesting” or “uninteresting”. Its meaning is as-at now — the temporal instinct from as-at records, applied to attention rather than compliance versions.

Several dimensions, not one magic score

These are priors, not independent voting judges. Many weak signals inform one final judgment; no single metric becomes an oracle. Reddit upvotes, YouTube coverage and aggregator mentions can matter without being mistaken for truth.

What the market already builds — and what it doesn’t

Others are working on substantial pieces of this loop. The market is fragmented.

Event Registry-style systems cluster related news articles into coherent events, offering a view of ongoing developments rather than isolated headlines.¹ That is a real step toward evolving story objects.

NewsWhip-style systems continuously reprice public engagement: current and predicted population attention so communications teams can see what will matter in the next hours.²

Those products ask: what story is emerging, how fast is it spreading, and who is involved? A personal signal-case queue additionally asks:

What does this change relative to my existing map, what evidence should we inspect next, and is it worth spending my attention now?

Public velocity is a sensor. It is not personal significance. A quiet engineering post that independently converges with your load-bearing framework may outrank a viral rumour that never touches your work.

Aggregators are sensors, not authorities

YouTubers, Reddit, Hacker News and “awesome lists” perform discovery, propagation sensing and interpretation sensing. Their coverage is a weak signal. Ten near-identical videos copied from one rumour count roughly as one lineage, not ten confirmations. Three technically independent communities discovering the same effect count much more.

Influence itself should be learned from receipts over time — domain-specific, time-sensitive, evidence-backed. That learning system is the Cascade Ledger, not this book. Here it is enough to refuse hand-maintained global “gold influencer” scores as the long-term architecture.

One queue, several renderings

You do not need separate immediate, coffee and weekly systems. They are different views over the same live queue.

Immediate push — only cases that cross the interrupt bar: important contradiction, significant first-party development, rapidly closing window, major change to active work. The interrupt budget remains essential. Attention is finite; systems that maximise interruption degrade judgment.³

Five-minute coffee briefing — a point-in-time compilation of what moved since last view: strengthened, spreading-without-confirmation, fading. A briefing, not a scrollable firehose.

Weekly briefing — structural review: promotions, contradictions, new sources gaining authority, canon candidates, resolved or killed cases, publishing opportunities.

Brief me for: 60 seconds · 5 minutes · 20 minutes · full weekly review

Rich inspectable history and expensive interruption stay separate. The world feed can be complete; the interrupt channel must not be.

The upgrade in one line

Earlier shape: ingest an item, diff it against the wiki, then route it.

Upgraded shape: ingest evidence into an open signal, repeatedly reinterpret that signal against a changing wiki and changing world, and render the current working set according to available attention.

Once you accept continuous repricing, the next decision is load-bearing: what is the unit of the queue?

Get the grain wrong and every scheduler, merge rule and briefing surface will thrash. Get it right and anchors can move while identity stays stable.

Three failed grains

Queueing the tweet is too narrow

A tweet is one observation. It cannot naturally represent later Reddit discussion, repositories inspired by it, independent convergence, historical predecessors, or whether the idea is accelerating or fading. You will either spawn sibling queue items for every downstream object or lose the story’s continuity.

Queueing the concept is too broad

“Wikis” or even “agent wikis” may remain interesting for years. A concept is not a bounded developing event. It does not naturally resolve. Concepts belong permanently in the wiki, not as eternal queue residents that never leave the working set.

Queueing every source creates duplication

Karpathy tweet
Reddit discussion of Karpathy tweet
YouTube video about Karpathy tweet
Github Awesome project inspired by Karpathy tweet

Four queue entries that all require loading the same neighbourhood and eventually discovering they are one developing story. Duplication is not only storage waste — it fragments heat, double-counts corroboration and confuses influence receipts later.

The middle grain

A signal case is a bounded, evolving claim or development whose significance is not yet fully resolved.

Example:

SIGNAL CASE
“Agent-maintained wikis becoming a mainstream AI-agent pattern”

That case can connect to the concept of agent-maintained wikis, Karpathy and other people, the original post, Reddit discussion, YouTube commentary, GitHub implementations, earlier prior art, your existing frameworks, and later disagreement or corroboration. The signal case is the stable thing that persists while its interpretation and canonical anchors change.

Bronze, wiki and queue have distinct jobs

Bronze stores observations. Every source object remains immutable:

bronze.twitter.post.123
bronze.reddit.post.456
bronze.youtube.video.789
bronze.github.repo.abc

You do not delete or overwrite these merely because a better source appears. Bronze answers: what exactly was observed, where, and when?

The wiki compiles meaning. People, concepts, posts, repositories, typed edges — lineage and interpretation. The wiki answers: what does this evidence mean, and how does it relate?

The queue is the active temporal index. Case ID, state, anchors, review targets, next review. The queue answers: which parts of the graph are still alive, unresolved or changing, and when should we inspect them again?

The wiki is the semantic graph. The queue is an active case index over the moving frontier of that graph.

Concept vs case

A case is an open hypothesis about a developing episode — not the timeless concept and not an individual source object. Chapter 9 returns to how that hypothesis splits and merges through time.

Design invariant for the rest of the book

Observations go into bronze. Relationships and conclusions go into the wiki. Developing stories become signal cases. The queue holds pointers to active signal cases and schedules which evidence objects deserve another look.

This chapter is the flagship proof. If the architecture survives Reddit-first discovery, most of the grain decisions lock. If it fails here, every scheduler and merge rule is building on sand.

Why Karpathy (and why not mythology)

Andrej Karpathy’s public posts on agent-maintained wikis are the running worked example. Not because he invented wikis — he did not — but because in the contemporary AI-agent discourse many builders follow, a substantial cascade currently traces through his formulation.

Hold historical roles carefully:

originated · preceded · independently-converged · popularised
translated-for-community · amplified · implemented · commercialised

For the current AI-agent wiki movement, Karpathy may be canonical populariser, propagation ancestor, or current-cascade root. He need not be inventor of wikis, first proposer of agent memory, or first user of a knowledge graph. Idea provenance is settled through dated receipts, not fame. Graph language is better than “godfather”:

cascade-root-for · popularisation-root-for · propagation-ancestor-of

The problem Reddit-first creates

It is obvious you would put a primary post in the queue. Then you review Reddit and find a post about that same development. You do not want a second queue item. The wiki will eventually join them — but discovery order is not guaranteed. You may see Reddit first.

Naive response: “kick out the Reddit post and replace it with the tweet.” That confuses the queue unit with the source object and destroys valuable propagation evidence.

Correct response: the queue unit was never the Reddit post. It was a signal case. The anchor is mutable. The case ID is stable. Bronze keeps everything.

Step 1 — Reddit is discovered first

You ingest:

Reddit post: “Karpathy says agents should maintain wikis”

The system cannot yet find the original source, so it creates:

signal_case_id: signal.agent-wiki-mainstreaming
canonicality_status: provisional
discovery_anchor: reddit.post.456
canonical_anchor: reddit.post.456
state: watching
heat: medium
uncertainty: high
current_claim: "Agent-maintained wikis may be entering mainstream AI-agent practice"

The Reddit post is not being declared the historical source. It is merely the best current anchor. Canonicality is provisional — a judgment under incomplete evidence, not a permanent coronation.

Step 2 — The original post is found

Later ingestion discovers the primary post. The wiki concludes (with reasons and evidence — canonicality is a judgment, not mere retrieval):

reddit.post.456 → refers-to → twitter.post.123
twitter.post.123 → authored-by → person.karpathy
twitter.post.123 → popularised → concept.agent-maintained-wiki

The case updates:

signal_case_id: signal.agent-wiki-mainstreaming   # unchanged
canonicality_status: settled_for_current_cascade
discovery_anchor: reddit.post.456                 # preserved
canonical_anchor: twitter.post.123                # promoted
state: accelerating                               # may reprice

The queue item is not replaced, because the queue item was never the Reddit post. Its anchor was replaced. That single sentence is the architectural payload of this chapter.

What happens to Reddit

You do not kick it out of the wiki. You demote it from canonical anchor to propagation evidence. It may still contain stronger technical discussion than primary replies, criticism and counter-claims, links to older work, evidence of community propagation, new people entering the cascade, and repositories or implementations.

Bronze remains immutable. Keep the bronze: promote meaning without destroying observations.

One case, many review targets

The scheduler needs to know which underlying objects to revisit:

review_targets:
  - object: twitter.post.123
    reason: origin conversation
    cadence: 30 minutes

  - object: reddit.post.456
    reason: technical community interpretation
    cadence: 3 hours

  - object: github.search.agent-wiki
    reason: implementation uptake
    cadence: 24 hours

So: the signal case is the queue unit; the review targets are the things rescraped; the wiki neighbourhood supplies the interpretation. Chapter 6 turns those cadences into an explicit priority market.

Full case shape (YAML)

This is the minimum viable case record the brief requires as proof:

id: signal.agent-wiki-mainstreaming

current_claim:
  "Agent-maintained wikis are becoming a mainstream agent pattern"

concepts:
  - concept.agent-maintained-wiki
  - concept.persistent-agent-memory

canonical_anchor:
  twitter.post.123

discovery_anchor:
  reddit.post.456

key_people:
  - person.karpathy

evidence_nodes:
  - twitter.post.123
  - reddit.post.456
  - youtube.video.789
  - github.repo.abc

propagation_roots:
  - twitter.post.123

counterevidence:
  - article.long-context-removes-wiki-need

state: accelerating
canonicality: settled_for_current_cascade
heat: high
uncertainty: medium
next_review: 2026-07-19T03:00:00+10:00

interpretation_history:
  - T0: discovered through Reddit; source uncertain
  - T1: original post located; canonical anchor promoted
  - T2: GitHub implementation cluster appears
  - T3: independent first-party convergence
  - T4: promoted to weekly review and newsjacking candidate

Interpretation history matters as much as the final state. Without it you cannot audit how the system came to understand the story — only what it currently believes.

Whole model (locked)

RAW OBSERVATIONS  →  BRONZE  →  WIKI  →  SIGNAL CASE  →  QUEUE
                                                              ↓
                                                       RE-OBSERVATION
                                                              ↓
                                                    WIKI REINTERPRETATION
                                                              ↓
                                         push · coffee · weekly · newsjack · resolve

You cannot scrape every tweet every hour. You also cannot ingest once and walk away. The discipline sits between those failures: adaptive re-observation.

Some animals are more equal than others

Things higher in the queue earn denser revisit schedules. Mild cases earn sparse ones. That is not elitism — it is budget. Cognition, API quota and model calls are finite.

A useful scheduling principle — the brief’s second proof burden:

next-review priority
=
potential importance
× uncertainty
× expected new information
× time sensitivity
÷ retrieval cost

Read it as a market. High importance with low uncertainty and no expected new information can wait. Medium importance with high uncertainty and a closing window jumps the line. Expensive retrieval without expected information gain loses to a cheap high-yield check.

Contrasting cadences (two worked schedules)

Hot Karpathy thread

High potential importance (touches agent-memory frameworks in your wiki). Medium-to-high uncertainty on adoption. High expected new information (replies, quotes, repos arriving). Elevated time sensitivity if a publishing window is open. Moderate retrieval cost via conversation endpoints.

15 min → 1 h → 3 h → 12 h → 1 day → 3 days

Early dense checks capture velocity; later spacing assumes the cascade either stabilised or already repriced into a push/weekly decision.

Mild Reddit post

Lower heat relative to personal canon. Uncertainty medium. Expected new information drops after the first comment snapshot. Low time sensitivity. Similar retrieval cost to a primary thread check, so the formula pushes it down the schedule.

6 h → 24 h → 3 days → expire

If you treat the hot thread and the mild post with the same hourly scrape, you are not running a market — you are running a tax.

These schedules attach to review targets inside a case, not only to the case as a blob. Origin conversation, technical community thread and implementation search can run on different clocks while sharing one case ID (Chapter 5).

Not “scrape the tweet again”

Platform mechanics already support cascade monitoring. On X, conversation identity, public engagement metrics and filtered streams let you reconstruct reply trees and re-measure motion without pretending the original text is the whole story.⁴⁵

First ingest can save original post, author, conversation identity, initial engagement snapshot, and referenced links. Later queue passes append new top replies, quote posts, engagement deltas, newly influential participants, and links to papers or repositories downstream.

Re-observe the information cascade around the source object.

Reddit top comments, GitHub stars and issue velocity, YouTube commentary — same idea on different sensors. Revisit what can change your understanding, not every byte of the internet.

Scout economics on the schedule

A cheap scout can collect deltas, attach evidence and propose heat changes. A senior model spends tokens when boundary decisions, contradictions or push eligibility are ambiguous. That is the scout–senior split applied to temporal attention: broad economical sensing, scarce judgment.

The queue as fast temporal interface

The wiki holds relevance across what is important and how you understand it. Walking the whole wiki to find what is trending now is the wrong interface. The queue exists so you do not have to.

signal_id: signal.agent_wikis_2026
wiki_refs:
  - person.andrej_karpathy
  - post.karpathy_llm_wiki
  - concept.agent_maintained_wiki
state: accelerating
next_review_at: 2026-07-19T03:00:00Z
review_reason: "reply velocity rising; several new implementations"

The wiki is the semantic graph. The queue is the temporal working set.

Most monitoring systems only observe arrivals. Almost none model meaningful non-arrival.

That gap is not academic. A promised release that does not ship, a reply that never comes, implementations that fail to appear — those absences change what a case means. If your architecture cannot represent expectation, it cannot reprice on silence. This chapter is the brief’s third proof burden: one worked non-arrival example.

The expected mechanism

A signal case may carry explicit expectations: future events the world “should” produce if the current hypothesis is healthy.

case_id: signal.lab_x_agent_memory_ship

current_claim:
  "Lab X will ship persistent agent memory in this release window"

expected:
  - kind: first_party_release_notes
    due_by: 2026-08-01
    if_missing: weaken_claim

  - kind: credible_implementation_fork
    due_by: 2026-08-15
    if_missing: lower_implementation_heat

  - kind: independent_engineer_confirmation
    due_by: 2026-08-10
    if_missing: raise_rumour_prior

When the clock passes and the object is absent, the system has gained evidence without a new document arriving. Non-arrival becomes an observation.

Worked example: the release that never shipped

T0 — claim enters the queue. Aggregators and secondary posts say Lab X will ship persistent agent memory “this cycle.” Heat medium-high; uncertainty high; expected release notes by date D. Personal relevance is medium: the claim intersects your agent-memory frameworks but is not yet first-party.

T1 — pre-release chatter. Engagement rises. No first-party confirmation yet. A naive feed shows “hot.” The case stays watching / accelerating because expected has not yet failed. Review targets densify slightly because expected new information is high near the window.

T2 — date D passes. No release notes. No demo. No repo. No first-party post. The cascade of secondary speculation continues for a day — volume without substance. This is the moment most systems have nothing to do: no new object arrived to score.

T3 — reprice on silence. The case moves toward weakening / likely expire. Rumour-source influence takes a receipt hit (Cascade Ledger territory). The human may get a coffee-brief line:

Lab X agent-memory ship window closed with no first-party evidence.
Action: expire unless primary appears; do not push.
Source prior: secondary amplifiers marked as high-propagation, low-truth on this topic.

Nothing “arrived” at T2 except the clock. The architecture that cannot see clocks cannot produce that judgment.

Two kinds of silence

Trusting the system’s silence is a North Star for delivery. Modelling the world’s silence is a mechanism for truth. They rhyme; they are not the same field.

Why almost nobody does this

Feeds are built as streams of present objects. Engagement products reprice what exists. Event clusters form around articles that were written. Non-events leave no article to cluster.

Personal intelligence systems that hold open hypotheses can do better: the hypothesis names what would count as progress. Absence of progress is then first-class.

Failure modes for expected

• Over-expecting chatty platforms. If you expect a reply from accounts that never reply, every case decays. Prefer expectations grounded in bronze text promises and domain norms.
• Under-expecting implementations. Serious architectural claims that produce zero repos in a community that usually ships should reprice — even if engagement stays high.
• Hidden expectations. If the scheduler silently assumed a future, humans cannot audit why heat dropped. Expected entries must be inspectable fields on the case.
• Confusing quiet with false. Non-arrival weakens a ship-date claim; it does not automatically falsify a long-horizon research direction. Match the expectation to the claim grain.

Connection to maturity

Signal maturity is not only “more posts.” It includes failed futures:

single observation
    ↓
watching
    ↓
corroborated  ←— or: expectation failed → weakening
    ↓
accelerating
    ↓
significant
    ↓
resolved / absorbed / expired

Chapter 8 places these operational facts — due times, cursors, failed expectations — in a materialised queue that the graph alone cannot invent after the fact.

Can the queue be derived from the wiki graph alone? The instinct splits in two directions — and both halves are right.

Why the queue is not a pure projection

Queue state depends on a serial sensing process:

• what arrived and in what order;
• when the case was last observed;
• what changed since that observation;
• which objects were already rescraped;
• when it is next due;
• whether an earlier expected development failed to occur;
• how much information another observation is expected to produce;
• whether a publishing or attention window is closing.

Those are temporal and operational facts, not only semantic relationships. A single graph snapshot does not know your observation cursors or that you already paid for a scrape twenty minutes ago. Serial arrival order is load-bearing: Reddit-first versus primary-first (Chapter 5) produces different intermediate states even when the final graph looks similar.

Why the queue must still be rebuildable

If the queue becomes an independent source of truth, you have two ontologies and a drift problem. The clean architecture:

BRONZE EVENT LOG
what was observed, when, and from where
             ↓
WIKI GRAPH
what it means and how it relates
             ↓
ACTIVE QUEUE
materialised temporal working set

The queue is a materialised active index over the graph plus observation history. It persists because repeatedly recalculating it from the entire graph would be slow and wasteful. But if it were lost, rebuild from:

1. graph state;
2. observation/event ledger;
3. unresolved signal-case states;
4. review-policy configuration.

Derived but operationally real. Names that capture the shape: Active Signal Index, Temporal Working Set, Signal Case Queue.

What the queue row contains

Not the full essay of the case — enough state to resume sensing:

case_id: signal.agent_wikis_mainstreaming
canonical_anchor: post:karpathy-wiki-tweet
review_targets: [post:..., reddit:..., github-search:...]
last_observed_at: ...
last_repriced_at: ...
next_review_at: ...
state: accelerating
heat: high
uncertainty: medium
expected_information_gain: high
active_reasons:
  - influential propagation root
  - implementation activity rising
  - newsjacking window open
observation_cursors:
  twitter_reply_cursor: ...
  reddit_comment_snapshot: ...
  github_snapshot_at: ...

The queue points into the wiki. It does not photocopy the wiki. Grain rule: the unit being sensed, stored, queued and interpreted does not have to be identical.

Cold start: you do not wait a week

Fear: go live with an empty queue and wait days for it to “warm up.” Unnecessary if the wiki already holds semantics.

Bootstrap historical understanding (~90 days of selected sources into bronze; compile people, concepts, provenance into the wiki; no live queue required yet). Bronze keeps everything; silver holds materialised working resolutions; gold holds recurring navigable meaning.

Then open the frontier. Scan the last few days from selected subreddits, Hacker News and technology aggregators, GitHub momentum sensors, first-party AI feeds, and high-signal people already discovered during historical ingestion.

90-day ingest → historical understanding
recent aggregator scan → active frontier
active frontier × wiki → initial queue

Reddit and aggregators are excellent bootstrap sensors because they solve initial discovery before the source graph knows whom to watch on X. Over time, learned influence (Cascade Ledger) can shift collection effort toward high-signal people and away from pure aggregator dependence. The queue populates itself in days, not weeks — because the wiki already knows how to attach.

Domain variants: email and ops

Same materialised market, different sensors.

Email. Cases for bookings, deadlines, threads awaiting reply, vendor escalations. Revisit priority rises as calendar proximity or unanswered expectation grows. Point-in-time coffee brief: what needs you in the next two hours vs what can wait until weekly review. The booking from Chapter 1 is not a cute aside — it is this architecture with calendar sensors.

Ops incidents. Cases for degradations, customer-impacting errors, post-incident follow-ups. Expected: mitigation by time T; customer comms by time U. Non-arrival of mitigation is evidence (Chapter 7). Merge when two alerts are one root cause; split when one incident becomes two failure modes (Chapter 9).

Do not fork three products. Fork sensors and review targets; keep signal cases and the temporal working set.

What this chapter refuses to own

How you replay competing queue designs against historical arrival orders is Replay-Driven Design Evolution — a sibling method for improving this architecture, not the architecture itself. Here it is enough that the queue is serial, materialised and rebuildable so such replay is possible later.

“Signal case” is useful because it is flexible — and that flexibility hides the hardest open problem.

What exactly makes two observations part of the same case, and when does one case become two?

Until you answer that under serial evidence, every dashboard is cosplay.

Why boundaries are load-bearing

Create, attach, merge, split, spawn, resolve and reopen determine the integrity of everything downstream.

A fluent but incorrect attachment can contaminate a case, falsely create corroboration, distort influence receipts, change topic heat, and train the radar to watch the wrong people. Boundary quality is a first-class benchmark — ahead of summarisation quality.

Concept, case, cascade

The queue wants the narrower developing episode, not the eternal concept:

Concept:
Agent-maintained wikis

Case 1:
Karpathy formulation triggers AI-community discussion

Case 2:
Agent-wiki repositories begin accelerating on GitHub

Case 3:
Major agent platforms adopt persistent wiki memory

They relate to one concept, may descend from one another, but have different clocks, evidence, maturity and review schedules.

They may not require three storage objects. Distinguishing them conceptually stops the case from becoming either too broad to resolve or too narrow to accumulate meaning.

A queue case is an open hypothesis about a bounded developing episode — not the timeless concept and not an individual source object.

Variations that force a decision

• Reddit discusses a primary post: same case (evidence).
• A GitHub repository implements the post: evidence, or a new implementation case?
• Twenty repositories appear: still one diffusion case, or an ecosystem case beneath it?
• Same person tweets the theme a month later: reopen, continuation, or new episode?
• Another influential person independently reaches the same idea: merge, or preserve two lineages?
• “Agent wikis” branches into personal memory, enterprise knowledge and coding-agent memory: one case becomes three movements.
• Original conversation dies; six months later a major product ships it: reopen or new adoption episode?

There is no free lunch. There is a Case Boundary and Lifecycle Contract.

Lifecycle contract (minimum)

What creates a case?
What attaches as evidence?
What causes a merge?
What causes a split?
What resolves a case?
What reopens it?
How are parent and child cases represented?

At every serial event, force one action:

ignore | attach | create | promote canonical anchor
merge | split | resolve | reopen

And answer: what is the case currently claiming? What changed because of this observation? Why is it still in the queue? What would make this a separate case? What evidence would resolve it? What is worth observing next?

Ten messy shapes

Any honest design should survive these as a test suite (full expansion in the appendix):

1. Secondary source arrives before primary.
2. Two independent sources converge.
3. Viral claim later proves false.
4. Quiet source becomes important days later.
5. One influential post generates several implementation branches.
6. Old concept suddenly reactivates.
7. One story gradually turns into two distinct stories.
8. Several apparent stories later collapse into one.
9. Large engagement but no substantive adoption.
10. Small engagement but consequential implementation.

These are not decoration. They are the collision set that draws the real object. How you run them as a design harness is Replay-Driven Design Evolution. How you learn influence across cascades is the Cascade Ledger. This chapter owns the recognition that boundaries are the risk and the contract is the artefact.

Personal grounding can overfit

Diffing against your canon is the power and the trap. A dense map can become a suppression shield around unfamiliar fields. Preserve an explicit alien-signal lane: a small attention allocation for significant developments with no detectable wiki intersection. Magnitude valves help; so does sampling what you suppressed.

The pieces resolve to a few invariants. If you only keep a one-page design contract, keep this.

Whole model

RAW OBSERVATIONS
        ↓
      BRONZE        immutable source objects
        ↓
       WIKI         people · concepts · posts · lineage · meaning
        ↓
   SIGNAL CASE      bounded developing interpretation
        ↓
      QUEUE         active pointers · review targets · cadence · expected
        ↓
  RE-OBSERVATION    cascade deltas, not one-shot text
        ↓
 REINTERPRETATION   against current wiki + evidence
        ↓
   RENDERINGS       push · coffee · weekly · resolve · write-back

Engine lines

The wiki holds what we currently understand. The queue holds what we have not finished understanding.

The wiki knows. The queue wonders. The briefing renders what is worth considering now.

Re-observe the information cascade, not the tweet.

Observations go into bronze. Relationships and conclusions go into the wiki. Developing stories become signal cases. The queue holds pointers to active signal cases and schedules which evidence objects deserve another look.

Build checklist

1. Two memories. Semantic wiki + temporal queue; never one store pretending to be both.
2. Signal-case grain. Reject post-grain, concept-grain and every-source duplication.
3. Mutable anchors. Discovery vs canonical; promote without deleting bronze.
4. Multi-target schedules. Priority = importance × uncertainty × expected new information × time sensitivity ÷ retrieval cost.
5. Expected non-arrival. First-class evidence when the world fails a stated future.
6. Materialised rebuildable queue. Persist operational state; rebuild from bronze + graph + cases + policy.
7. Lifecycle contract. Create, attach, promote, merge, split, resolve, reopen — with ten messy shapes as tests.
8. Cold start. ~90-day wiki bootstrap + recent aggregator scan; queue populates in days.
9. Judgment cameo. Interestingness-as-diff, interrupt budget, signals log — feed the queue; do not reinvent a magic score.
10. Deliberate siblings. Cascade Ledger for influence receipts; Replay-Driven Design Evolution for harnessed design change.

What compounds

Resolved cases do not merely leave the queue. They enrich the wiki: new people, edges, priors, suppressible themes. Future attachment, detection and judgment become more discriminating.

The radar is not only filtering tomorrow’s news better. It is thickening the map against which tomorrow’s news will be judged. The semantic substrate is not a staging area for a transient queue — it is the capital asset the queue spends attention against.

After months of use, another team can copy the architecture and still lack your map of what matters, which sources earn which job, and how quickly you need to hear something. That compounding is why write-back is mandatory. (The deeper moat argument is its own sibling theme — The Moat Is the Memory; here it is simply the reason the loop closes into the wiki.)

What “done” looks like for the human

You begin relying on the radar without checking the firehose yourself when:

• repeated alerts are rare;
• pushes earn high approval;
• duplicate-case and boundary-correction rates stay low;
• watched cases become significant before ordinary feeds notice;
• important misses are found through blinded sampling of suppressions;
• coffee briefings show motion, not a dump of everything open.

Closing

Do not force a one-time judgment on information whose significance is still unfolding. Give unfinished understanding a place to live — and a schedule for wondering again.

The wiki will know more tomorrow because of what the queue wonders today.

Use these as a serial test suite. For each shape, feed events one at a time and force a lifecycle action (ignore / attach / create / promote / merge / split / resolve / reopen). Record what the case claims after each step.

1. Secondary before primary

Shape: Reddit (or newsletter) arrives first; original post hours later.
Good behaviour: One case; provisional canonical = secondary; promotion to primary without new case ID; secondary demoted to propagation evidence; bronze both retained.
Failure: Two cases; deleting secondary; treating secondary as permanent origin.

2. Two independent convergences

Shape: Two high-authority people state similar ideas without referencing each other; different wording, no shared links.
Good behaviour: Prefer two cases (or one parent concept with two case children) until independent-convergence edge is justified; do not invent a single cascade root.
Failure: Forced merge that fabricates lineage.

3. Viral then false

Shape: High engagement claim; later first-party denial or hard counter-evidence.
Good behaviour: Case stays for correction trail; state → disproved/expired; heat collapses; influence receipts on amplifiers take hits; do not silently delete history.
Failure: Vanish the case so the system cannot learn.

4. Quiet then important

Shape: Low engagement primary; three days later implementations and first-party echoes.
Good behaviour: Case survives on uncertainty + personal relevance even when public velocity is low; cadence densifies when expected new information rises.
Failure: Expire on low likes; miss the slow burn.

5. One post, many implementation branches

Shape: One populariser post; then repos that specialise (personal memory / enterprise wiki / coding-agent memory).
Good behaviour: Parent diffusion case may spawn child cases when claims diverge enough to need different clocks; retain parent links.
Failure: One bloated case that never resolves; or ten cases with no parent.

6. Old concept reactivates

Shape: Concept quiet for months; new episode begins with fresh cascade.
Good behaviour: New case under same concept; do not reopen a long-resolved case unless the claim continuity is real.
Failure: Eternal concept-as-case that never leaves the queue.

7. One story becomes two

Shape: Early “agent memory” discussion splits into “long context removes need for memory” vs “external wiki memory” as adversaries.
Good behaviour: Split when current_claim can no longer cover both; preserve shared early evidence on both or via parent.
Failure: Single case with contradictory heat and mixed review targets.

8. Several collapse into one

Shape: Three weak threads look distinct; later all cite the same primary and share implementers.
Good behaviour: Merge with retained discovery anchors and combined evidence; single schedule.
Failure: Permanent triple-counting of corroboration.

9. Large engagement, no adoption

Shape: Massive replies and videos; zero serious implementations or first-party uptake after expected window.
Good behaviour: Expected failures fire; heat ≠ importance; expire or park as cultural noise.
Failure: Equate virality with significance forever.

10. Small engagement, consequential implementation

Shape: Quiet engineering post; one production-grade repo changes practice in your stack.
Good behaviour: Personal relevance and implementation evidence dominate public metrics; push or weekly depending on interrupt bar.
Failure: Stay blind because the crowd was quiet.

Scoring a design pass

The harness that runs these shapes against competing designs is Replay-Driven Design Evolution. The suite itself is part of the signal-case queue’s specification — keep it next to the lifecycle contract, not in a drawer.