Personal intelligence · Attention architecture

The Signal-Case Queue: The Wiki Knows, the Queue Wonders

News-shaped information cannot be judged once at ingestion, because its significance keeps changing after you observe it. The correct architecture separates a semantic wiki from a queue of bounded signal cases that continuously reprices each case as evidence, corroboration and time arrive.

Scott Farrell · LeverageAI · Full design essay companion to the Signal-Case Queue ebook

You open a feed. Something looks mildly interesting. You suppress it. Three days later, implementations are shipping, a first-party engineer has confirmed the idea, and the window to write or act has already narrowed. Or the reverse: something looks hot, you interrupt yourself, and it dies as rumour. The failure is not “bad ranking.” The failure is assuming significance is a property you can freeze at arrival.

That assumption is baked into most personal news systems, email triage tools and ops alert pipelines. Ingest an item. Score it. Route it. Done. But news-shaped information is not a static document. It is a living cascade of observations whose meaning is always as-at now — and “now” keeps moving.¹

This essay codifies one architecture for that problem: the signal-case queue. It is the missing temporal layer above interestingness-as-diff judgment. Where an earlier design asks how this item changes your map, this design asks which unresolved developments still deserve cognition, and when looking again is worth the cost.

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

Two forms of memory

The system needs two different memories that must not collapse into one store.

The wiki is accumulated understanding. It holds what you already know and believe: frameworks, people, companies, prior signals, contradictions, provenance. When something new arrives, the wiki answers: what does this mean in my world? That substrate is the same family as a self-cleaning wiki-graph and the durable memory tier that agents boot from — not a dump of tweets, and not the model weights.²³

The queue is unresolved attention. Everything new may enter the queue, but the queue does not hold “articles forever.” It holds things whose final significance is not yet known. A weak signal can stay alive long enough for the world to supply corroboration, contradiction, implementation evidence or — crucially — silence.

The queue is not a second knowledge base. It is a live projection over open signal pages: the active frontier of the graph. You cannot walk the whole wiki every hour to discover what is trending. That is the queue’s job — a different interface into the same data, organised by heat, uncertainty and intention rather than by topic hierarchy.

The queue is a market, not a FIFO

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

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

So the item is not permanently labelled interesting or uninteresting. Its meaning is as-at now — the same temporal instinct that turns a knowledge base into a defensible record when the question is past-tense, applied here to attention rather than compliance versions.⁴

Public products already reprice population attention. NewsWhip Spike calculates current and predicted public engagement so teams can see how popular a story is now and up to a day ahead.⁵ Event Registry groups related articles into coherent evolving events rather than isolated headlines.⁶ Those are real advances. They still ask a different question than a personal queue:

Which unresolved developments are changing in ways that could alter my understanding, priorities or publishing opportunities — and which source objects should we spend cognition re-observing next?

Interestingness remains a diff against your compiled worldview — contradicts, independently converges, genuinely novel, already known — not an engagement score dressed up as judgment.⁷ The queue does not replace that judgment layer. It keeps weak observations alive until judgment can be fair.

The grain is a signal case

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

Queue the tweet and you are too narrow. A tweet cannot naturally hold later Reddit discussion, repositories, independent convergence or whether the idea is accelerating.

Queue the concept and you are too broad. “Agent wikis” may remain interesting for years. Concepts do not resolve; they live in the wiki forever.

Queue every source object and you create duplication: four queue entries for one developing story, each loading the same neighbourhood until the system finally notices they are the same case.

The middle grain is the signal case:

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

Example: “Agent-maintained wikis becoming a mainstream AI-agent pattern.” That case can connect to Karpathy, his original post, Reddit discussion, YouTube commentary, GitHub implementations, earlier prior art and your existing frameworks — while remaining one queue object whose interpretation and anchors can change.

Flagship: Reddit-first, then the original post

Andrej Karpathy’s public writing on agent-maintained wikis is the running worked example — not because he invented wikis, but because in the AI-agent discourse many of us follow, a large cascade currently traces through his formulation. Treat him as a cascade populariser with dated receipts, not as a mythic inventor.

Here is the Reddit-first scenario the architecture must survive.

Step 1 — Secondary source opens the case

You discover a Reddit post: “Karpathy says agents should maintain wikis.” The original post is not yet in bronze. The system creates:

The Reddit post is not declared the historical source. It is the best current anchor.

Step 2 — Primary source is found; anchor promotes

Later ingestion finds the original post. The wiki records typed edges: Reddit refers-to original; person authored original; original popularised concept. The case updates:

The queue item is not replaced, because the queue item was never the Reddit post. Its anchor was replaced. Bronze still holds both observations immutably — keep the bronze; promote meaning without destroying evidence.⁸

The Reddit thread remains valuable: technical criticism, older links, community propagation, implementers who never replied on X. It becomes a review target with its own cadence, not a second case.

One case, many review targets:

Platform mechanics already support cascade re-observation. X API v2 exposes conversation_id for thread identity, public metrics (reposts, replies, likes, quotes, bookmarks, impressions) and Filtered Stream for near-real-time rule matches.⁹ The discipline is not “scrape the tweet again.” It is:

Re-observe the information cascade around the source object.

Adaptive re-observation: some animals are more equal

You do not re-scrape every object every hour. Each queued case — and each review target — earns its schedule. A useful priority is:

Contrasting cadences under the same formula:

A cheap scout can attach observations and propose heat; a senior model reinterprets ambiguous boundary and push decisions — the same scout–senior economics, applied to temporal attention rather than one-shot triage.¹⁰

Expected silence is evidence

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

A signal case can carry expected entries: a promised release date, a reply that should have come, implementations that “ought” to appear if the claim is real. When the clock passes and nothing arrives, that absence should reprice the case — often downward, sometimes as a different kind of story (vaporware, stalled cascade, overhyped rumour).

This is the dual of the interrupt budget. Silence toward the human is a high-judgment output; silence from the world is a high-information observation when you had a reason to expect sound.¹¹

Materialised but rebuildable

Can the queue be derived from the graph alone? Not completely. Queue state depends on serial arrival order, observation cursors, last review times, due times, failed expectations and closing windows. Those are operational facts, not only semantic edges.

But the queue must not become an independent source of truth. Clean architecture:

If the queue is lost, rebuild from graph state + observation ledger + unresolved case states + review policy. Derived but operationally real — a materialised active index, not a second ontology.

Cold start: bootstrap ~90 days of bronze and gold understanding so the system already knows people, concepts and history. Then scan recent aggregators and communities (Reddit and similar are excellent discovery sensors before the source graph knows whom to follow on X). Active cases appear almost immediately:

You do not wait a week for an empty queue to “warm up.” The wiki supplies priors; the frontier supplies motion.

The hard problem: case boundary through time

Signal cases are useful because they are flexible — and that flexibility hides the next load-bearing risk.

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

Hold three distinctions, even if storage is unified:

A Case Boundary and Lifecycle Contract must answer: what creates a case; what attaches as evidence; what merges; what splits; what resolves; what reopens; how parent/child cases are represented. Without that contract, fluent but wrong attachments contaminate heat, false corroboration and learned influence.

Ten messy shapes any honest design should survive as a test suite (full appendix in the ebook): secondary before primary; two independent convergences; viral-then-false; quiet-then-important; one post, many implementation branches; old concept reactivates; one story becomes two; several collapse into one; large engagement, no adoption; small engagement, consequential implementation.

How you learn source influence from those cascades is its own deliverable — the Cascade Ledger. How you evolve the design with replay harnesses is another — Replay-Driven Design Evolution. This article owns the queue artefact itself, not those siblings.

Same engine, other domains

The email upgrade is the same market with different sensors. A booking is noise when made and signal an hour before it happens — or when the time changes. Ingestion that judges once will either spam you at booking time or fail to surface the appointment when it becomes actionable. A queue of cases with calendar-sensitive revisit priority fixes the temporal mismatch without a second product architecture.

Ops incidents, regulatory consultations, customer escalations: anywhere significance is as-at now and evidence arrives serially, the same grain applies.

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. That compounding loop is why 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. The moat is the memory — a theme for a sibling piece; here it is simply the reason the queue must write back.

Build checklist

1. Separate wiki (semantic graph) from queue (temporal working set).
2. Adopt signal cases as the queue unit; reject post-grain and concept-grain.
3. Keep discovery vs canonical anchors mutable; never delete bronze on promotion.
4. Implement multi-target revisit schedules with the priority formula.
5. Model expected non-arrival as first-class evidence.
6. Persist the queue as materialised state; ensure rebuild from bronze + graph + cases + policy.
7. Write a Case Boundary and Lifecycle Contract before you polish dashboards.
8. Cold-start with historical wiki bootstrap + recent aggregator scan.
9. Feed judgment from interestingness-as-diff and an append-only signals log; do not invent a second interestingness magic number.
10. Leave influence receipts and design-replay harnesses as deliberate adjacent systems.

If you only remember one sentence: 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.