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.

A man in a dark jacket stands close to a sunlit brick wall, looking up and away past the camera.
Anton Chigurh, No Country for Old Men — The question a worry kernel exists to answer. A rule produced this outcome, so what was the rule for? Subtitles on the image read: “If the rule you followed brought you to this, of what use was the rule?”
The question
Who built this conclusion, and when was it last tested?

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.

diagram

The loop a worry kernel sits inside

  1. BlankSomething is hidden and you do not yet know it matters.
  2. AskCould an answer here change what I do? If not, stop.
  3. SignAn observation that leaves a trace of the hidden state.
  4. TestRun it against the evidence, with a control.
  5. UpdateBelief moves, or the blank survives and stays named.
  6. 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 kernel is the part of this that keeps turning without a person remembering to look. Its whole job is to close the gap between the sign and the decision.

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.

policy.yaml — the 3 October kernels, verbatim
detectors:
- id: duplicate_send_storm
ontology: comms.mail.outbound
when: "sends by one member to one recipient >= 3 within 60m"
action: "refuse further sends until they reply; notify owner, head"
rate: [board_member_duplicate_email_per_hour]
- id: ci_allowance_burn
ontology: delivery.ci.cost
when: "billed minutes / (allowance x month fraction elapsed) >= 3"
action: "ticket DevOps: find the waste; project exhaustion time"
allowance_minutes: 2000
- id: ci_chronic_red
ontology: delivery.ci.health
when: "CI failure share >= 30% over the trailing 6h (min 10 runs)"
action: "ticket DevOps: a red signal that is always on carries no information"
diagram

The life of one signal

  1. ObservedThe stream already exists — mail, CI, queues, comments. Nothing is instrumented for this.
  2. PricedConverted into dollars per hour of cost of delay, with provenance on the conversion.
  3. RoutedSent to the seat that owns that class of harm, at a severity set by the price.
  4. 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.

A signal earns its place only if it can reach the last step. Most detection systems stop at step two and call it monitoring.

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.

Unit conversions · provenance declared per line
   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.

Severity ladder · by cost-of-delay rate
   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?

3 October 2026 · replay over captured evidence · times UTC
PartWould fireActually noticedEarlier by
A · support storm07:2211:244 h
B · delivery halt06:2112:125.5 h before the halt
C · stalled debrief12:0512:105 min
A fires on the third duplicate within sixty minutes; B on CI burn at three times the month-to-date pace, then again when delivery blocked; C on a member posting three near-identical comments. Only B was detected before it caused harm, and it was detected six hours before.
Detected earlier
4 h
the support storm
Saving, P50
$510
P10 $333 · P90 $739
Build cost, P50
$203
P90 $321 · mostly review time
False alarms
0
on quiet mail · 10 chronic, all true

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

CUSUM k=10, h=ln 1000 · against the six rules and against what actually happened
PartCUSUMSix rulesNoticed
A · support storm07:2407:2211:24
B · delivery halt00:0806:2112:12
C · stalled debrief12:0512:0512:10
Falsified as pre-registered: no later than the control on only one of three parts, and the verdict held in just two of nine grid settings. It is reported as a loss. It may not be re-tuned and re-tested on this same evidence — that would be fitting to the answer.
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.

Measured intervals · 3 October
   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

Left: one organisation, one night. Right: 684 federal documents, 272 experts. Independent work; a structural parallel, not a validation.
This analysisHung et al., arXiv:2609.16260
The signals existed; no detector watched themThe sectors exist; coverage does not track expert-rated vulnerability
Impacts were bare integers with no unit, so harms could not be comparedNo 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 ordinaryPublic 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 reasonFinance and healthcare are rated highly vulnerable by experts and receive comparatively low coverage
The CI signal landed on a seat with no accountability for deliverySocioeconomic, environmental and emerging risks — including multi-agent risks — receive the least attention
Fix: price every harm, route by price, one owner per classFix: surface the gaps so decisions can be informed — it names them, it does not route them
Both studies measure where attention actually goes against where the loss actually is, and both find the two uncorrelated. The parallel is structural. The federal study is about governance documents and expert judgement, not about alarms, and it does not test any of the machinery above.

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.

The floor, priced
   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.

  1. 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"
    context · public · as of 1954
  2. measured · public · as of 2026-09-14 · accessed 2026-10-10
  3. 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
    context · public · accessed 2026-10-03
  4. 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"
    context · public · accessed 2026-10-03
  5. 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
    context · public · accessed 2026-10-03
  6. 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
    context · public · as of 2021 · accessed 2026-10-03
  7. Howard (1966), value of information · worth is the expected improvement in a decision's outcome, and zero where the answer cannot change the decision
    context · public
  8. 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
    context · public · accessed 2026-10-03
  9. 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
    measured · internal · as of 2026-10-03
  10. 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
    context · internal · as of 2026-10-06
  11. 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
    assumed · public · accessed 2026-10-10

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.