Worry Kernels
A detector is a pre-built conclusion about what normal looks like. Here is one built to be priced, dated and falsified — and the night it was tested againstA declarative policy that watches one stream, prices what it sees, and decides who to wake. Replaying one October night through six of them caught three failures hours earlier, at a build cost of about $203 against a saving of about $510.

Asimov wrote that prejudice is wonderful for saving a man the trouble of thinking for himself, because it hands him pre-built conclusions. Every detector you have ever run is a pre-built conclusion about what normal looks like. A useful one and a prejudiced one differ in maintenance rather than confidence: whether anyone priced it, dated it, and left themselves room to lose the argument.
1. A pre-built conclusion about what normal looks like
On the evening of 3 October 2026 an organisation had three unrelated failures inside five hours. A support email storm hit a board member, who had been locked out since that morning. A delivery pipeline stopped dead at 11:54 and stranded the fixes for the first problem. A debrief was missed, which broke a promise.
None of this was invisible. The signals all existed. There was a refused-send stream in the mailroom, CI failure emails in the same mailroom, a hot list showing a jammed queue and people waiting outside, and a member repeating itself on one request without making progress. What was missing was the thing that turns a signal into a waking person.
The signals existed. Nothing was watching them, because nothing had been told what watching meant.
A worry kernel is that missing thing: a small declarative policy that watches one stream, prices what it sees in a unit everybody shares, and decides who to wake. It is a rule, a price list and a routing table, all written down before the night.
The loop a worry kernel sits inside
- BlankSomething is hidden and you do not yet know it matters.
- AskCould an answer here change what I do? If not, stop.
- SignAn observation that leaves a trace of the hidden state.
- TestRun it against the evidence, with a control.
- UpdateBelief moves, or the blank survives and stays named.
- ActOnly where the answer crossed the decision.
Read as: A hidden state leaves a sign. You ask whether an answer could change a decision, and only if it could do you test. The test moves what you believed, which exposes the next blank, and the loop repeats. Where the answer cannot change anything, the loop stops on purpose.
The name matters less than the shape, and the shape has a long pedigree. Google SRE agrees a few numbers in advance and adds rituals — no engine. PagerDuty and Atlassian both reduce severity to a four or five row table with plain criteria and named roles, under the rule that when in doubt you go higher. FAIR defines risk as loss-event frequency times loss magnitude, entered as ranges and run through Monte Carlo. Hubbard argues that calibrated ranges beat high-medium-low, and that a measurement is worth taking only when its answer could change a decision. ISO/TS 22317 records impact over time per activity, which is another way of saying a cost-of-delay curve.
None of that is new. What is new here is refusing to build anything heavier than it, and then testing the refusal against a real night rather than a design document.
The first job is to stop describing harm in units nobody can compare.
2. Anatomy of a worry kernel
The whole policy is data. A unit list with provenance, a severity ladder, and a set of detectors. Each detector names the stream it watches, the condition that fires it, the action it takes, and the rate it is priced at.
The life of one signal
- ObservedThe stream already exists — mail, CI, queues, comments. Nothing is instrumented for this.
- PricedConverted into dollars per hour of cost of delay, with provenance on the conversion.
- RoutedSent to the seat that owns that class of harm, at a severity set by the price.
- AcknowledgedHeld open as one episode until a person takes it. Not re-fired per event.
Read as: A signal is observed, then priced in a shared unit, then routed to someone who owns that class of harm, then held open until a person acknowledges it. If it cannot be priced it cannot be compared; if it cannot be routed it does not exist; if nobody acknowledges it, it was never a signal at all.
Step four is the one most systems skip, and the 3 October record shows what happens when they do. One CI channel had been red 114 times that day. A red that is always on carries no information, so the outage looked like every other failure. The kernel that would have caught it fires once on the condition and stays fired until someone answers.
Pricing is the step that makes any of it arguable.
3. Priced, not felt
The hot list that night carried impacts as bare integers: 60, 55, 30. No unit. A jammed queue and a halted delivery pipeline therefore could not be compared, ordered or escalated on one scale, so whichever was loudest won. That is the single most consequential defect in the whole record, and it is a one-line fix: give every harm a price and a provenance.
inference_call 0.00196 measured ci_minute 0.00600 measured visioneer_attention_hour [100, 150, 300] assumed board_member_duplicate_email [ 2, 10, 40] assumed member_locked_out_hour [ 5, 15, 50] assumed delivery_halted_hour [ 2, 8, 30] assumed department_blocked_hour [ 2, 6, 20] assumed missed_commitment [ 20, 50, 150] assumed
Two conversions are measured and carry their source in the file: an inference call at $0.00196, derived from $0.251 across 128 calls, and a CI minute at $0.006 from the published rate. Six are assumptions, each declared as one, each given a range rather than a number, and each priced high on purpose where the input is scarcest — an hour of the Visioneer's attention is the most expensive thing on the list and is labelled as such.
Severity is then just a function of the price, not a judgement call.
SEV1 >= $100/h visioneer, coo, owner, sre within 5m every 30m SEV2 >= $25/h coo, owner, sre within 15m every 1h SEV3 >= $5/h owner, head within 1h every 4h SEV4 >= $0/h hotlist within 1d
A reader who disagrees with the routing can now disagree precisely. Change $100 to $250 and say why. Pricing is the whole argument here: it turns a disagreement about feelings into a disagreement about a number, and numbers can be settled.
With the prices in place, the night could finally be replayed.
4. One night, three failures
The replay ran at 23:50 AEST over evidence already captured that day — mailroom, CI, request comments, spend. Nothing was instrumented for it, which is what makes the result worth anything. The verdict was set before the run: adopt, narrowly.
Would a worry kernel have caught it?
| Part | Would fire | Actually noticed | Earlier by |
|---|---|---|---|
| A · support storm | 07:22 | 11:24 | 4 h |
| B · delivery halt | 06:21 | 12:12 | 5.5 h before the halt |
| C · stalled debrief | 12:05 | 12:10 | 5 min |
Part A dominates the loss: $459 of the $784 at P50. Refusing at the third duplicate avoids 17 further duplicates and 60 refused sends. Telling the owner and the head four hours earlier probably brings the sign-in fix forward, and that effect is honestly recorded as a range of zero to four hours rather than as a number.
Part B is the more interesting one, because the win is prevention rather than detection. The burn alarm at 06:21 projected the allowance exhausted by morning; the pace then accelerated. With three hours to fix the waste, the halt is avoided in most draws. Its direct cost was only $31, because CI minutes are cheap — the real exposure was always the halt, not the bill.
The saving's P10 beats the build's P90. By the conversation's own rule — learn only if the answer could change the decision — that is the end of the calibration work. The assumed rates do not need refining yet, because no plausible refinement flips the verdict.
Then the part worth being embarrassed about.
5. Six rules against two parameters
Hand-set rules are expensive in a specific way: the six kernels above required twelve or more hand-set numbers between them, each one a pre-built conclusion somebody had to justify. So a challenger was run against the same evidence — CUSUM, a rate-change detector that asks whether the flow has shifted, using two global parameters and baselines read from existing policy.
It was pre-registered before it ran and committed, with its sensitivity grid and its failure condition written down first. The rule was: adopt only if it is no later than the six rules on all three parts.
The challenger, by the rule fixed in advance
| Part | CUSUM | Six rules | Noticed |
|---|---|---|---|
| A · support storm | 07:24 | 07:22 | 11:24 |
| B · delivery halt | 00:08 | 06:21 | 12:12 |
| C · stalled debrief | 12:05 | 12:05 | 12:10 |
It lost, and this reports it as a loss. Re-running it until the answer improved would have made the exercise worthless.
What it lost is worth stating plainly, because it is a real result. Fast storms are a draw: both arms fire on about the third event, minutes apart, and the hand-set windows happened to be marginally tighter. But on slow drifts it was six hours earlier, seeing the CI drift long before a cumulative-pace rule could. It produced no false alarms on quiet mail, using two parameters where the control needed six rules and a dozen numbers.
It also produced ten alarms on 1 and 2 October that were all true — the SLO and the allowance really were breached — and all useless as pages. An alarm nobody can act on detects nothing. A second version is pre-registered for the next incident, out of sample, with episode grouping and a stated success bar: within ten minutes of the rules on fast events, at least an hour earlier on drifts, and at most one episode per genuine breach.
Underneath both arms ran a clock nobody had measured.
6. The organisation's Planck time
Every runaway loop that night beat on the same tick. Refused sends: 64 events, median gap 2.00 minutes. Replies to the same recipient: 20 events, 2.00 minutes. The repeating comments: 2.00 minutes. That is the agent wake interval, and it is the smallest interval the organisation can resolve.
refused sends 64 events median 2.00 min IQR 1.99–2.02 replies to one 20 events median 2.00 min IQR 1.99–2.01 repeating comments median 2.00 min by nyquist, nothing slower than ~4 min can see a loop at the tick
By Nyquist that means nothing running slower than about four minutes can observe or damp a loop running at the tick. The coach ran on three hours. The other human loops ran slower still. They were all, structurally, incapable of seeing it.
The send storm was worse than a slow response. The agent sending and the guard refusing ran at the same frequency, half a cycle apart: sixty-four cycles of energy in, zero displacement. That is a standing wave, and it is why the storm did not decay. The fix is to rest on refusal — move the next attempt past the point where the limit resets, instead of echoing straight back.
There is a general detector hiding in that observation, and it costs nothing: high activity with near-zero net change in state, on any stream, is a standing wave. Work is being done and nothing is moving. It also showed up in the money. GitHub billed 2,028 minutes against 1,621 actually used, because each job rounds up to a whole minute — a twenty percent quantisation loss across every job, and far worse for pushes far below the quantum, such as documentation edits.
One of the three failures was never going to be caught by any of this.
7. Not every failure is a detection problem
Part C saved a handful of calls and nothing else. The debrief still failed, because the mail system could not accept a member address. That gap was fixed afterwards in a separate pull request. A detector fired correctly, at the right time, and the harm happened anyway.
This is the finding most likely to be lost in a write-up that wants a clean story, so it is stated as a rule: the replay cannot tell you that a failure was a detection failure. It can only tell you whether a detector would have fired. Before you build the next kernel, ask whether the previous night was a watching problem or a plumbing problem.
It also forces an honest category the platform did not have. The cause-class list on a support ticket was platform, process, people skill, third party, customer environment — and the ticket could not be closed without picking one. Forced guesses then pollute the grouping that clusters repeat incidents. Adding an undetermined class, carried as an open question, is the better postmortem practice, and it is the same discipline as leaving a blank visible instead of filling it with a plausible default.
The limits here are not local. The same shape turns up at national scale.
8. The same shape, six hundred documents wide
In September 2026 a study at MIT and Harvard mapped 684 United States federal AI governance documents against 14 sectors and 24 AI risks, measuring coverage as breadth — how often a risk or sector is addressed — and depth — how substantively. It then compared the coverage pattern for each risk against a Delphi study of 272 experts rating sector vulnerability.
The finding is the same finding this piece has been describing, one scale up: attention and vulnerability do not track each other.
Two findings, two scales
| This analysis | Hung et al., arXiv:2609.16260 |
|---|---|
| The signals existed; no detector watched them | The sectors exist; coverage does not track expert-rated vulnerability |
| Impacts were bare integers with no unit, so harms could not be compared | No common unit carries across risk classes; robustness and system security outrank the rest by attention |
| A CI channel red 114 times a day reads as normal, so the outage looked ordinary | Public administration and national security are covered so constantly that coverage stops distinguishing anything |
| A board member was classified as "a person outside" — right urgency, wrong reason | Finance and healthcare are rated highly vulnerable by experts and receive comparatively low coverage |
| The CI signal landed on a seat with no accountability for delivery | Socioeconomic, environmental and emerging risks — including multi-agent risks — receive the least attention |
| Fix: price every harm, route by price, one owner per class | Fix: surface the gaps so decisions can be informed — it names them, it does not route them |
The honest limit: this is a parallel, not a confirmation. The federal study measures documents and expert opinion. It says nothing about detectors, pricing or routing, and nothing in it was run on our evidence. What it does show is that the mismatch is not an artefact of a small organisation having a bad week. The same decoupling appears when you count 684 policy documents against 272 experts.
Which raises the question of what you do about it, given you cannot afford the alternative.
9. Zero-point energy
Zero-point energy is the lowest energy a quantum system can have, and the point of the name is that it cannot be removed. Borrowed here as a practice, it means the floor of vigilance you maintain whether or not anything is happening: always on, priced, and cheap enough that switching it off would be a decision rather than a saving.
The alternative everyone assumes is a binary. Either you buy the full operation — the watch floor, the on-call rotation, the platform — or you have nothing until the tide comes in. Zero-point is the third option, and the 3 October replay sizes it precisely.
build once ~$203 at P50 (~$321 at P90), mostly review time run continuously ~$0 one night returned ~$510 at P50 (P10 $333, P90 $739) the floor pays for itself and then stops costing anything
That is the whole case for the practice: the cheapest useful amount of attention is neither zero nor an operation. It is a handful of priced rules on streams you already have, held open until someone answers. It is also, not incidentally, a way of not being the crop — a business whose alarm revenue depends on you being frightened is one whose conclusions are pre-built for it, which is exactly the failure the Asimov line describes.
What we have not done, and should not pretend to: the federal comparison above has not been replicated on our own material. The study counts breadth and depth across documents; the natural experiment is to count breadth and depth across our own policies, tickets and postmortems against the losses we have actually booked, and see whether the same chart appears. Until that runs, section 8 is an analogy.
Which leaves the danger that makes all of this necessary.
10. When a worry kernel becomes prejudice
A worry kernel and a prejudice are the same object: a pre-built conclusion about what normal looks like. They part company on maintenance.
A kernel becomes prejudice the moment its baseline stops being a claim and starts being an assumption: when nobody can say who set it, from what evidence, or when it was last tested. On 3 October the organisation had baselines. CI was expected to be partly red, so partly red was normal. A board member emailing support was expected to be a person outside the business, so that classification was correct by the rules and wrong by the facts. Every one of those was a reasonable pre-built conclusion that had simply stopped being examined.
The guard against it is not better judgement. It is the three boring disciplines already in the literature: price it with provenance, date it, and pre-register the rule you will judge it by before you run it. A kernel you may re-tune until you like the result has become a prejudice with a dashboard — and the 3 October challenger is the demonstration, because it was held to its own rule and lost.
The opposite of prejudice is not open-mindedness. It is a conclusion you can show the working for, and lose.
Method and sources
How it was runOne incident on 3 October 2026, recorded the same night. The replay ran at 23:50 AEST over evidence already captured by the platform — mailroom, CI, request comments, spend — with nothing instrumented for it, using six declarative kernels from a policy file and a severity ladder set by cost-of-delay rate. Dollar figures are Monte Carlo draws over triangular ranges declared in the policy: measured conversions for inference calls and CI minutes, assumed ranges for reputation, lockout, halt, blocked-department and missed-commitment costs, each marked assumed in the file. The CUSUM challenger was pre-registered and committed before it ran, with its grid and failure condition; its result is reported as a loss and may not be re-tuned on this evidence. Time-to-detect was reconstructed by hand because detected_at was not recorded — that gap is the first thing the next version fixes. The organisation is not named here beyond what the evidence requires, and the three failures are described as recorded rather than attributed.
- Isaac Asimov, The Caves of Steel (1954) · "Prejudice is a wonderful thing for saving a man the trouble of having to think for himself, because it provides him with pre-built conclusions"
- Google SRE Workbook · error budget policy, and alerting on SLOs by burn rate over two windows, with slower burns routed to tickets rather than pages
- PagerDuty open-source incident response docs, and Atlassian severity levels · a four or five row SEV table with plain criteria, named roles and cadence, under "when in doubt, go higher"
- FAIR (Open Group O-RA/O-RT), and Douglas Hubbard, How to Measure Anything · risk as loss-event frequency times loss magnitude, entered as ranges and run through Monte Carlo; calibrated ranges over high-medium-low
- ISO/TS 22317:2021 business impact analysis · impact by category at one hour, four hours, one day and one week per activity, with the maximum tolerable period of disruption inside it — a cost-of-delay curve
- Howard (1966), value of information · worth is the expected improvement in a decision's outcome, and zero where the answer cannot change the decision
- Cloudflare, Stripe and Etsy postmortem practice, and Learning from Incidents · public timelines separating started, detected and mitigated; clustering repeat incidents by class and fixing the class; near-misses as first-class records
- The 3 October 2026 incident record and experiment folder · policy file, replay and CUSUM runner, pre-registration, per-part results and the cost conversions quoted above
- Too Much World (d/rksci research) · the vocabulary this piece builds on rather than restates: state and sign, reach and horizon, basins and ridges, worth and price, and the blank that must survive
- An anonymous public comment on r/accelerate, October 2026 · the "breastfeeding" framing of inherited expectations nobody did the work to build around, and the claim that a security turning-point was mostly being caught acting rather than practising. Used as a lens on GRC, not as evidence; the author is unidentified and its substantive claims are unchecked here
A worry kernel is a pre-built conclusion you can show the working for. A prejudice is the same object with the working thrown away.