Building for Reliability  🔗 **Source:** [Building for Reliability](https://www.youtube.com/watch?v=ugZjcHoLQQo) > [!note]+ Document Notes > tags: [monzo, leaddev, site-reliability, emergent-failure, anomaly-detection, deploy-frequency, cost-of-quality, technical-debt, postmortem-culture, kubernetes, behavioral-metrics, auto-remediation, non-deterministic-systems, fintech-engineering] > author: LeadDev > source: youtube.com > reference: https://www.youtube.com/watch?v=ugZjcHoLQQo > date created: 2026-09-03 08:20 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the speaker. > > Do not quote or attribute any other line to the named speaker. > > > [!warning] Read this before trusting the note > > **Source shape.** A 22-minute conference talk (22:25) on the LeadDev YouTube channel, published 2026-09-02, 311 views at capture. Speaker introduces himself as "Mate," a software engineer at Monzo; the captions never give a surname, a job title beyond "software engineer," or the conference edition, so none is asserted here. 2,668 caption words across 39 paragraphs. > > **ASR artifacts.** Auto-captions mishear "LeadDev" as "like Dev," "Monzo" once as "Monsa," "org" as "orc," "incident response runbooks" as "instant response runbooks," "out-of-order delivery" as "out of delivery." Quotes below are left as captured. > > **Evidence quality.** Every number (15 million customers, 3,000 microservices, 300 deploys a day, 99.996% availability, 100 ms → 1% completion drop, 0.4% acceptance-rate drop) is the speaker's own account of internal Monzo data. No slides, dashboards, or postmortems are visible in the transcript; nothing is independently checkable. Treat the figures as practitioner testimony from a regulated bank, not as published measurements. > > **No sponsor.** No product pitch; the speaker's employer is the case study. > > # 🏷️ Title: Building for reliability > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Source: https://www.youtube.com/watch?v=ugZjcHoLQQo (LeadDev channel, https://www.youtube.com/@LeadDev) - No outbound links in the transcript. Named entities: Monzo, Kubernetes, the UK and Ireland markets. ## 📝 Summary **What this is.** A Monzo engineer's talk arguing that reliability is an emergent property of a whole system plus the organization running it, not a feature you add to components. The talk is built on three incidents of increasing size and then draws six operating rules from them. **The three incidents.** - *100 milliseconds.* An A/B-tested change to currency conversion passed every metric. An adjacent screen, "move money," lost 1% of completions. The cause was an unintended 100 ms added to that screen's load time. Nothing errored; customers "voted with their attention." - *Unhealthy nodes.* A few Kubernetes nodes going unhealthy under load slowed the app for a small subset. Monzo added a monitor-and-replace loop: mark the node unhealthy, later swap it for a fresh one. - *The big one.* A routine rolling upgrade restarted nodes one by one. Each was marked unhealthy during restart and came back fine, but the unhealthy marks stayed. The auto-recovery loop then replaced large parts of the cluster at once, took out core services, and forced a failover to a stand-in system. The speaker's summary: "an upgrade process performed flawlessly, interacted with automated monitoring and recovery mechanisms," and did something "locally reasonable" that was "globally harmful." **The six rules.** 1. You can't test your way out of production failure; assume partial failure, timeouts, retry storms, and out-of-order delivery as the default and prefer idempotent workflows and compensating actions. 2. The first design choice is how fast you notice, so measure everything, including behavioral metrics like customer intent. The 100 ms failure surfaced as a behavior change, not an error. 3. High-impact incidents are usually slow movers living in the tails of distributions; anomaly detection on subgroups caught a 0.4% drop in card acceptance that population-level dashboards would never show. 4. Ship fast because it's safer: about 300 deploys a day, each small enough to reason about and roll back. "The goal is to break in a detectable, reversible manner." 5. Technical debt is a tool with three rules: know you're taking it, cost it (isolated and reversible vs. trunk and hard to reverse), and give every item an owner and a payback plan. Adversarial domains like fraud justify speed over polish. 6. Balance three buckets (proactive reliability, reacting to production, new features) using a "cost of quality" metric whose proactive and reactive components have a minimum; over-alerting pushes reactive cost back up. **Culture clauses.** Zero risk appetite collapses learning; treating proactive work as a tax leaves response unpracticed; treating rollbacks as failures stops people rolling back; blameless, mandatory, tooled, broadcast postmortems are "one of the most important things you have to get right." **The closing turn.** More code shipped than ever, more of it by people who don't read or write code, and "a new class of non-deterministic component" (AI) inside the system. The speaker says none of the lessons change; they intensify. ## 📖 Main Content **Why a bank talks about reliability as trust.** The speaker frames trust three ways: competence, integrity, reliability. Reliability is the one where the product shows up when needed, and for a phone-only bank every failure is felt in the app. That framing makes the 100 ms story land: a "functioning" system that feels slower is a reliability failure by his definition, and the customer response (abandoning a transfer) is the measurement. **The composition argument.** The middle incident is the talk's real content. Every component involved was well-tested: the upgrade tooling, the health monitor, the node replacer. The failure is in the interaction: a health mark that should have cleared on restart didn't, and an automation designed to protect reliability read that stale state as an instruction to replace most of the fleet. His conclusion is stated as a principle, "reliability is not something that you add to individual components. It is the composition of systems and tools and operators and third parties that must be reliable together." The word "operators" is doing work there: he includes humans and third parties in the system boundary. **Measurement before prevention.** "Our first choice is not whether we allow a failure to happen or not. Our first choice is actually how fast we notice." That ordering is the operational thesis. He gives two supporting mechanisms: behavioral metrics (customer intent) catch what error rates miss, and anomaly detection on subgroups catches slow drift in the tails. The 0.4% card-acceptance example is the size of signal he says matters: invisible in aggregate, real for the affected subgroup. **Speed as a safety property.** Three reasons, in his order: faster feedback, failure is inevitable so delay only delays learning, and small changes are easier to reason about and undo. He contrasts 300 daily deploys with bundling "hundreds and thousands" of changes into a monthly release that is "much harder to undo." The prerequisites he names are culture, an articulated risk appetite, and heavy investment in automation and low-friction tooling. **Technical debt with rules.** The rules are crisp enough to be adopted verbatim: if you don't know you're taking it, "it's not technical debt, it's just bad engineering"; cost it by blast radius and reversibility; every item has an owner and a plan. He credits team ownership plus accountability for the proactive anomaly-detection investment, a team choosing to spend on reliability because it had the freedom to. **Cost of quality.** Total spend to hold a chosen quality level, split into proactive (tests, alerts, runbooks) and reactive (everything spent responding). Reactive never reaches zero; over-investing proactively (his example: oversensitive alerts) raises reactive cost through false incidents. He claims a global optimum exists and that a team in that zone can spend the rest on features. No formula, no numbers, no view of the dashboard. **Culture and postmortems.** Four failure modes named as conditionals (no risk allowed, proactive work as tax, rollback as failure, no transparency), each with its consequence. Postmortems must be easy, sometimes mandatory, tooled, learning-focused, and broadcast org-wide so that failure is normalized as the thing you learn from. **The AI coda.** He doesn't name a vendor or a model. He names three shifts (more code, code from non-coders, non-deterministic components interacting with systems, teams, and customers) and says the lessons are "only reinforced." The specific claims: you need more automation and low-friction tooling, things fail in new unpredictable ways, so assume it, measure for it, and practice a response. ## 🗒️ Notes - **The auto-remediation incident is a textbook feedback-loop failure.** A stale health signal plus an automated actor equals an automation that does exactly what it was built to do at the wrong scale. The pattern generalizes to any "self-healing" component: the healing logic needs a rate limit or a sanity check on how much of the fleet it may touch at once. The speaker doesn't say what the fix was. - **100 ms → 1% is the most useful number in the talk** and also the least verifiable. It's one screen, one bank, one day. The mechanism (latency as a trust signal that shows up in behavior, not errors) is the durable part; the ratio is not. - **"Behavioral metrics" and "customer intent" are the terms to keep.** They're his answer to "what do you measure when nothing errors." For a CMS or a plugin, the analogue is completion rates on admin flows, not PHP error logs. - **Deploy-frequency argument matches the WordPress minor-release discussion today.** WordPress 7.1.1's schedule (deep-read 2026-09-02) exists because a monthly-ish bundle is hard to reason about and undo; this talk is the general case. - **Cost of quality is Crosby's manufacturing term** (Philip Crosby, *Quality Is Free*, 1979) applied to software; the speaker doesn't cite it. His "over-alerting raises reactive cost" is the software-specific addition. - **No mention of SLOs or error budgets.** Unusual for a reliability talk in 2026; his "risk appetite" plays that role informally. - **The AI paragraph carries no specifics** about how Monzo uses non-deterministic components, so the "lessons reinforced" claim is an assertion from the stage, not a case. ## 📚 References - LeadDev (YouTube), *Building for reliability*, speaker "Mate" (Monzo), published 2026-09-02, 22:25. Captured to Reader 2026-09-03. - Cross-reference in Reader: *Rudy Faile — The Big One Is Coming* (2026-09-02): append-only logs and least privilege for AI agents; complements this talk's "non-deterministic component" coda. - Cross-reference: *WordPress 7.1.1 Release Schedule* (2026-09-02): the release-cadence argument applied to WordPress core. - Cross-reference: *Rank Math Pulls Controversial Support Agent* (2026-09-02): an automation acting with broad permissions at scale; the plugin-ecosystem analogue of the auto-recovery incident. - Crosby, P. (1979). *Quality Is Free*. Origin of the "cost of quality" term the talk uses without attribution. ## 🗣️ Paraphrase Reliability is what makes customers trust a bank, and at a phone-only bank every slowdown is felt. We learned that a 100 ms regression on one screen cost us 1% of completions with zero errors. We learned that an upgrade and an auto-recovery loop, each correct alone, combined to take down most of a cluster. So: reliability emerges from how everything interacts, including people. You can't test it in; you notice it fast, by measuring behavior and watching the tails, then you respond and learn. Shipping 300 small changes a day is safer than one big one because each is easy to understand and undo. Take on technical debt knowingly, cost it, and give it an owner. Spend on prevention up to the point where it stops lowering your reactive costs, and no further. Reward rollbacks and blameless postmortems. AI-written code and non-deterministic components don't change any of this; they make it more urgent. ## 📰 Newsletter **A bank's reliability lesson in one line: notice first.** Monzo runs 3,000 microservices, deploys about 300 times a day, and reported 99.996% availability last year, so its engineer's talk at LeadDev is worth the 22 minutes. The headline story is an automated node-replacement loop, built to improve reliability, that read stale health marks after a routine upgrade and replaced most of the cluster. His takeaway isn't "less automation." It's that reliability is emergent, so the first design decision is how fast you notice, not whether you fail. Two practices carry the weight: behavioral metrics (a 100 ms slowdown showed up only as a 1% drop in completed transfers) and anomaly detection on subgroups (a 0.4% card-acceptance drop invisible in aggregate). Then ship small and often, so breaking is "detectable, reversible." The numbers are his; the mechanisms travel. ## ✅ Action Items **DevRel** - The three-incidents-then-six-rules structure is a reusable talk shape: each rule is earned by a story before it's stated. `#action/h4` - "The goal is to break in a detectable, reversible manner" is a quotable frame for any release-process or CI/CD content. `#action/h3` **OSPO** - Not applicable to this source. **Community** - Not applicable to this source. **WordPress teams** (Core, Core Performance, Core AI, Core Program Team, Mobile, Playground, Community, Training, Marketing, Support, Design, Documentation, Photos, TV, Polyglots, Accessibility, Meta, CLI, Hosting, Tide, Openverse, Themes, Plugins) - **Core Performance:** the 100 ms → 1% completion story is an argument for pairing Core Web Vitals work with behavioral completion metrics on admin flows, not just lab timings. `#action/h3` - **Core / Core Program Team:** the deploy-frequency section is the general case for more frequent, smaller minor releases; relevant to the 7.1.1 schedule discussion. `#action/h4` - **Hosting:** auto-remediation that reads stale health state can amplify a routine upgrade into an outage; hosts running self-healing fleets should cap how much of the fleet remediation may touch per interval. `#action/h3` - **Meta:** anomaly detection on subgroups (by locale, plugin, PHP version) would surface slow-moving regressions that aggregate dashboards hide. `#action/h4` - **Core AI:** the speaker's "non-deterministic component interacting with everything else" is the failure class the Abilities API and any agent surface need measurement and practiced response for. `#action/h3` - All other teams: not applicable to this source. **The WPOCC** - Not applicable to this source. **FAIR** - Not applicable to this source. **Personal (Courtney)** - **Reuse the "notice first" ordering** in any reliability or release-process writing for your next DevRel role: measure behavior, watch the tails, then prevent. It's the cleanest statement of the thesis you'll find. `#action/h2` - **Pair this with the Rudy Faile note** for a short piece on automation acting at scale: an auto-recovery loop here, an AI agent there, both "locally reasonable, globally harmful." `#action/h3` - **Lift the three technical-debt rules** (know it, cost it, own it) into your own project checklists; they're checkable. `#action/h3` ## 🧪 Hypotheses - **H-A:** For admin-flow screens in WordPress, a 100 ms added load time produces a measurable drop in completion rate within a week of A/B exposure. *Testable on any site with completion analytics; the talk gives one data point.* - **H-B:** Self-healing infrastructure without a per-interval remediation cap will, on at least one routine upgrade per year, remediate healthy capacity. *Testable in incident postmortems across hosts.* - **H-C:** Teams that publish blameless postmortems org-wide roll back changes sooner than teams that don't. *Testable with deploy and rollback timestamps.* - **H-D:** Anomaly detection on customer subgroups finds regressions that population-level alerting misses at a rate that justifies its false-positive cost. *The talk asserts it with one example; a count of true vs. false anomalies over a quarter would settle it.* ### 📊 Methodology Practitioner testimony: three incident narratives and a set of operating principles, illustrated with internal numbers and no external data. No slide content survives in the transcript, so the "cost of quality" curve and the anomaly-detection example can't be inspected. The right use is as a hypothesis source and a vocabulary source; the numbers are not evidence beyond Monzo. ### ❓ Questions - What was the fix for the auto-recovery loop: clearing health marks on restart, rate-limiting replacements, or both? - How does Monzo compute "cost of quality" in practice, and what counts as indirect reactive cost? - Does the 300-deploys-a-day figure include config and feature-flag changes or only code? - How is "customer intent" instrumented without becoming surveillance of individual users? - Which non-deterministic components are in production at Monzo, and how are they measured? ### 🔮 Future Research - Compare this talk's "notice first" thesis with SRE-book SLO/error-budget framing; are they the same idea with different vocabulary? - Collect published incidents where automated remediation amplified a routine change (Kubernetes, autoscalers, AI agents) into a pattern note. - Map the three technical-debt rules onto WordPress core's Trac workflow to see where "owner and payback plan" is missing. ### 💡 Implications - **For platform teams:** automation that acts on health state needs the same blast-radius reasoning as a deploy. - **For product analytics:** completion-rate metrics are reliability metrics; a slowdown without errors is still an outage for the people who left. - **For release management:** the argument for frequent small releases is reasoning and reversibility, not speed for its own sake. - **For AI-in-production:** the speaker's claim that nothing changes is itself a testable position; his own composition argument suggests new interaction failures will appear that no component test predicts. ## 🧠 Learning Styles Assessment **Auditory** — well served; a single-speaker narrative with three stories. **Read/write** — served by the transcript; the six rules are stateable as a list. **Visual** — unknown; slides exist but nothing visual survives in captions. **Kinesthetic** — weakly served; no exercise, though the three-bucket trade-off and the debt rules invite immediate application. **Sequential** — well served; incidents escalate in size, then principles follow. **Global** — served by the thesis statement in the middle ("reliability emerges, or it doesn't"). **Overall:** a story-first conference talk for practitioners; adapts easily to a written checklist. ## 📊 Accessibility Assessment Assessment of the captured transcript, not a WCAG audit of YouTube. #### Captions and transcript - Auto-generated captions with frequent word-joins ("agreat," "themove money") and misheard names; a Deaf or hard-of-hearing viewer gets the argument but loses proper nouns (LeadDev, Monzo once). Manually corrected captions would fix both. #### Visual dependence - The cost-of-quality curve and the incident timeline are described verbally in enough detail to follow without slides. Good practice for blind and low-vision viewers. #### Cognitive load - Three stories, six rules, explicit signposting ("One… Two…"). Moderate length. Clear. #### Language - Plain English, few acronyms (A/B, UK). Kubernetes and microservices assumed. ## 🌍 DEIB Assessment - **Voices:** one speaker, one company. No customers, no operators, no third parties quoted despite being named as part of the system. - **Framing of customers:** "voted with their attention" treats abandonment as rational signal, not user error. Respectful. - **Blamelessness** is explicit in the postmortem section; the talk models it by describing a major incident without naming a team or person. - **Access to the material:** free on YouTube with auto-captions; the conference itself is paid. - **Gaps:** no mention of accessibility as a reliability dimension, no mention of how failures fall unevenly across customer groups (the subgroup anomaly detection hints at it without saying so). ## ✅ Logical Validity **Claims and their support.** - *Reliability is emergent from composition* — supported by one detailed incident whose mechanism is stated. Strong as an existence proof. - *Latency without errors costs completions* — one A/B observation, causal attribution by metric canvass. Plausible, single data point. - *Slow-moving incidents dominate high-impact failures* — asserted from experience, one example (0.4%). Unquantified. - *Frequent small deploys are safer* — argued from reasoning and reversibility; consistent with industry data he doesn't cite. - *Cost of quality has a global optimum* — asserted as a curve; no data shown. The over-alerting mechanism is sound. - *AI reinforces rather than changes the lessons* — asserted, no case. **Fallacies.** None structural. Risk of survivorship: a bank with 99.996% availability describing its practices may attribute the outcome to the practices without a control. **Internal consistency.** Consistent. The "move fast" section and the "cost of quality" section could conflict (speed adds reactive cost) but he resolves it via small, reversible changes. **Verdict.** Valid as practitioner argument with one well-specified mechanism (auto-remediation on stale state). Numbers are illustrative, not evidence. ## 🛡️ DARVO Analysis Not applicable to this source. There's no accusation or reversal. The speaker takes ownership of a major incident on stage, names the automation his organization built as a contributing cause, and argues for blameless postmortems. That is the opposite posture. ## 🎯 Conclusion The durable content is one mechanism and one ordering. The mechanism: automation that reads stale health state and acts at fleet scale turns a flawless upgrade into an outage, so reliability lives in interactions, not components. The ordering: decide how fast you'll notice before you decide how to prevent, then measure behavior and the tails. Everything else (300 deploys, three debt rules, cost of quality, postmortem culture) follows from those two. The numbers are Monzo's and unverifiable; the vocabulary travels to any system, including WordPress release management and any team putting an AI agent next to production. ## 🔄 Refactor Appendix — Building for reliability ### 📚 Literature Atoms (H3) #### [H1] A 100 ms regression with no errors cost 1% of completions > [!quote] ID:rw_01m1kmx2n320maxy3nv13tyaw2 > "we actually inadvertentlyintroduced an additional 100milliseconds into the loading time ofthat screen. And that's what caused theproblem. Now, this was a very subtlechange, and nothing bad really happenedhere, right? The system was functioning,but that does not mean that it wasreliable." Latency is a trust signal that surfaces in behavior, not in error rates. Tags: `#atom/literature/h1` #### [H2] Reliability is the composition of systems, tools, operators, and third parties > [!quote] ID:rw_01m1kmx2n320maxy3nv13tyaw2 > "reliability is not somethingthat you add to individual components.It is the composition of systems andtools and operators and third partiesthat must be reliable together. Soreliability emerges, or it doesn'tthrough how all of these componentsinteract." The system boundary includes humans and vendors; testing components can't test the composition. Tags: `#atom/literature/h2` #### [H3] High-impact incidents are slow movers detected in the tails > [!quote] ID:rw_01m1kmx2n320maxy3nv13tyaw2 > "a lot of high impactIncidents are not sudden large spikes. They're slow movers.Latency creeps up. Model correctnessdrifts.There's a slow decrease in successfulcustomer outcomes that doesn't have anobvious explanation. And the detectionand the diagnosis of those errors liesin the tails of the distributions." Aggregate dashboards hide the failures that matter; subgroup anomaly detection is the tool. Tags: `#atom/literature/h3` #### [H4] The goal is to break in a detectable, reversible manner > [!quote] ID:rw_01m1kmx2n320maxy3nv13tyaw2 > "So the goal is not to never break anything. The goal is to break in a detectable,reversible manner. That's the main goal. So, changeshould be as cheap as possible, andundoing that change needs to be evencheaper." Reframes release safety as reversibility cost rather than defect count. Tags: `#atom/literature/h4` #### [H5] Unknowing technical debt is just bad engineering > [!quote] ID:rw_01m1kmx2n320maxy3nv13tyaw2 > "you have to know you're takingon technical debt. If you don't, it'snot technical debt, it's just badengineering." Debt is a deliberate, costed, owned decision or it isn't debt. Tags: `#atom/literature/h5` ### 🧠 Permanent Candidates (H4) #### [P1] Automation acting on stale health state converts a routine change into a fleet-scale outage The Monzo incident: a rolling upgrade left "unhealthy" marks on healthy nodes; an auto-recovery loop replaced most of the cluster. The general form is any self-healing or agentic component that trusts a state signal and acts at scale without a blast-radius cap. Same class as the AI-agent risks in the Rudy Faile note. Links: [[Automation Blast Radius]] · [[Rudy Faile - The Big One Is Coming]] · [[Site Reliability MOC]] Tags: `#atom/zettel/z1` #### [P2] Decide how fast you'll notice before deciding how to prevent "Our first choice is actually how fast we notice." Detection design (behavioral metrics, tail anomaly detection) precedes prevention design because failure in composed systems is the default. *Candidate; the ordering is the speaker's, the generalization to non-infrastructure systems is mine.* Links: [[Measurement Before Prevention]] · [[Observability MOC]] Tags: `#atom/zettel/z2` ### ✏️ Fleeting Queue - "Cost of quality" is Crosby's term; check whether the speaker's over-alerting curve appears in any published source. `#atom/fleeting/f1` - Does WordPress core track any behavioral completion metric on admin flows, or only errors and timings? `#atom/fleeting/f1` - The three technical-debt rules as a Trac ticket template field: owner + payback plan. `#atom/fleeting/f1` ### → Things 3 (max 2 actions) 1. **Draft a short piece pairing this talk with the Rudy Faile note:** automation and agents that are "locally reasonable, globally harmful," with the blast-radius cap as the fix. `#action/h3` 2. **Add "know it, cost it, own it" to your project technical-debt checklist.** `#action/h3` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Building for Reliability.md|Building for Reliability by LeadDev]] ## Highlights - must be reliable together ([View Highlight](https://read.readwise.io/read/01m1kn9mpgp0r5d9z4e39jmr6m)) - Note: H2 — Reliability is emergent from the composition of systems, tools, operators, and third parties; the system boundary includes humans and vendors. #atom/literature/h2 - Tags: atom/literature/h2 - the tails of the distributions ([View Highlight](https://read.readwise.io/read/01m1kn9qwkv6k2ssytvpkfx0j3)) - Note: H3 — High-impact incidents are slow movers in the tails; subgroup anomaly detection caught a 0.4% card-acceptance drop invisible in aggregate. #atom/literature/h3 - Tags: atom/literature/h3 - The goal is to break in a detectable ([View Highlight](https://read.readwise.io/read/01m1kn9vdwmx4varn7nt10d9ts)) - Note: H4 — "Break in a detectable, reversible manner": release safety reframed as reversibility cost, backed by culture, stated risk appetite, and low-friction tooling. #atom/literature/h4 - Tags: atom/literature/h4 - So, reliability really matters. ([View Highlight](https://read.readwise.io/read/01m1kn9hfsjesh5xj4z5d7d5x1)) - Note: H1 — A 100 ms regression with zero errors cost 1% of completions on an adjacent screen; latency is a trust signal that shows up in behavior, not error rates. #atom/literature/h1 - Tags: atom/literature/h1