The Repair LibraryRead · Learn · Master

Thinking in Trees — Structured Fault Isolation

Everything this volume has taught lives, so far, in method and memory: the workflow, the instruments, the campaigns. This closing chapter gives it a second home — structure. A troubleshooting tree is fault isolation written down as decisions: every node a test, every branch an outcome, every leaf a verdict or an action. It is the divide-and-conquer of Chapter 1 made external and repeatable — the half-split that used to live in a technician's judgment now drawn where a whole bench can follow it, criticise it, and improve it. This opening section is about thinking in that shape before building in it. What a tree actually is, and what separates it from a flowchart: a flowchart lists steps, while a tree's nodes are tests with discriminating power — each answer genuinely splits the space of possible faults, which is why a good tree finds in four questions what a checklist finds in forty. Why structure beats recall: consistency across tired days and different hands, teachability to the bench's newest member, and durability — the tree encodes the expensive lessons the case records paid for, so they stop evaporating with staff and time. What makes a single node good: a test that is cheap before expensive, decisive rather than suggestive, safe in its ordering, and measurable in its criterion — 'rail below 4.75 volts' branches cleanly where 'rail looks low' cannot. What makes a whole tree good: the likely and cheap near the top, the universal spine — power, then heartbeat, then path — before family specifics, and every leaf an action: a verdict, a repair, or an honest escalation. And what a tree is not: it is a map, not the territory — trees run out, age, and mislead when followed past their edges, which is why the chapter ahead teaches building them, using them, escaping them, and growing them from the bench's own records. By the end of this section you can read a tree the way the volume taught you to read a board — critically, node by node — and you are ready to build one.

IntermediateLow Risk20 min read

What You Will Learn

  • You will learn what a troubleshooting tree is — tests at the nodes, outcomes on the branches, verdicts at the leaves — and how it differs from a flowchart of steps.
  • You will learn why written structure beats recall: consistency, teachability, and durability of the bench's expensive lessons.
  • You will learn what makes a single decision node good — cheap, decisive, safe in its ordering, and measurable in its criterion.
  • You will learn what shapes a good tree — likely and cheap near the top, the universal spine before family specifics, and every leaf an action.
  • You will learn a tree's limits — a map that runs out, ages, and misleads past its edges — and how the chapter ahead builds, uses, escapes, and grows them.

What You Will Be Able To Do

  • You will be able to explain what a troubleshooting tree is — tests at the nodes, outcomes on the branches, verdicts at the leaves — and how it differs from a flowchart of steps.
  • You will be able to explain why written structure beats recall: consistency, teachability, and durability of the bench's expensive lessons.
  • You will be able to judge a single decision node — cheap, decisive, safe in its ordering, and measurable in its criterion.
  • You will be able to judge a tree's shape — likely and cheap near the top, the universal spine before family specifics, and every leaf an action.
  • You will be able to state a tree's limits — a map that runs out, ages, and misleads past its edges — and where the chapter ahead takes each of them.

Required Tools

  • Paper, index cards, or a whiteboard for drawing trees
  • A written repair procedure or service flowchart to convert
  • A few of the bench's case records to mine for nodes
  • The volume's own method notes — the route, the campaigns
  • A pencil with an eraser, because trees are revised, not carved

Section Overview

The volume's method has lived in memory and practice; this chapter writes it down as structure, and this section teaches the shape before anything is built in it (the-troubleshooting-process). A tree is fault isolation as decisions. A troubleshooting tree puts a test at every node, an outcome on every branch, and a verdict or action at every leaf — the divide-and-conquer of Chapter 1 made external, repeatable, and criticisable (fault-isolation-by-divide-and-conquer). It is not a flowchart. A flowchart lists steps; a tree's nodes carry discriminating power — each answer genuinely splits the space of possible faults, which is why a good tree finds in four questions what a checklist finds in forty. Structure beats recall for bench reasons. A written tree is consistent across tired days and different hands, teachable to the newest member, and durable — it encodes the expensive lessons the case records paid for (from-reproduction-to-verified-repair). Nodes have an anatomy. A good decision node holds a discriminating test — cheap before expensive, decisive rather than suggestive, safe in its ordering, and measurable in its criterion: "rail below 4.75 volts" branches cleanly where "rail looks low" cannot. Trees have a shape. The likely and cheap sit near the top, the universal spine — power, then heartbeat, then path — comes before family specifics, and every leaf is an action: a verdict, a repair, or an honest escalation (diagnosing-with-the-oscilloscope). And trees have edges. A tree is a map, not the territory — it runs out, ages, and misleads past its limits, which is what the rest of the chapter is for. Learn the shape, the node, the tree, and the edges — and the volume's method gains a second home that outlives the session.

Why This Matters

A bench's diagnostic skill usually lives in one or two heads, and everything in those heads is one resignation, one vacation, or one tired Friday from being unavailable (the-troubleshooting-process). This matters because recall is inconsistent where structure is not: the same technician runs a different diagnosis at hour one and hour nine, but a written tree asks the same four questions every time — and the questions were chosen at leisure, not under pressure. This matters because trees compress diagnosis: a well-shaped tree halves the fault space at every node, so four good questions cover sixteen outcomes — the arithmetic of half-splitting, now drawn where it can be checked (fault-isolation-by-divide-and-conquer). It matters because the expensive lessons deserve permanence: the case records and recipe libraries from the intermittents campaign already hold which faults a family actually has; a tree is those records made navigable at speed (from-reproduction-to-verified-repair). It matters because teaching needs an artifact: the newest bench member cannot download judgment, but they can follow a tree today and understand it next month — the tree is the curriculum. And it matters because bad structure is worse than none: a flowchart of vague steps, or a tree followed past its edges, marches a diagnosis confidently to the wrong leaf — so reading trees critically comes before writing them (diagnosing-with-the-oscilloscope). Give the method structure, and the bench's best diagnosis becomes its normal one.

Required Prerequisites

  • Fault Isolation by Divide and Conquer — Section 1.4 taught half-splitting as a way of thinking; this chapter writes that thinking down, and this section is the grammar of the writing.
  • The Troubleshooting Process — Section 1.2 gave the workflow the tree exists to encode; a tree is that process specialised to a device family, one decision at a time.
  • Paper, index cards, or a whiteboard — to draw, rearrange, and erase trees without ceremony (fault-isolation-by-divide-and-conquer)
  • A written service flowchart or repair procedure — to practise converting steps into decisions
  • A handful of the bench's case records — to see where real traffic would flow through a tree (from-reproduction-to-verified-repair)
  • Sticky notes — to prototype nodes that are not yet sure of their place
  • A red pen — to mark the vague criteria and weak nodes this section teaches you to catch
  • No powered hardware is required — this section is paper thinking; the soldering waits for the trees to be worth following (the-troubleshooting-process)
  • A familiar device's service manual, if one exists — to read its flowcharts with this section's critical eye
  • The bench's own method notes — to find the universal spine already implicit in them (diagnosing-with-the-oscilloscope)
  • A folder of closed case records — to mine real nodes from real diagnoses (from-reproduction-to-verified-repair)
  • A printed copy of a public troubleshooting guide — to practise telling a tree of tests from a list of steps
  • A timer — to feel the four-questions-versus-forty difference on a worked example

Real-World Applications

Thinking in trees changes how a bench reads every guide it already owns. A technician handed a service manual's flowchart reads it critically for the first time — spotting that half its boxes are steps without discriminating power, and marking the three nodes that actually split the fault space (fault-isolation-by-divide-and-conquer). A bench owner watching two technicians diagnose the same model differently recognises the cost of recall and drafts the family's first tree from the better of the two routes (the-troubleshooting-process). Someone training a new hire hands over a one-page tree instead of a shadowing month — the hire runs real diagnoses in week one, and the questions they ask about the tree become its next revision. A repairer reading their own case records sees that nine of the family's last ten faults resolved through two branches — and moves those branches to the top, where the traffic is (from-reproduction-to-verified-repair). And a technician mid-diagnosis notices the manual's tree assuming a symptom their device does not show, recognises the edge of the map, and escapes to the volume's method instead of forcing the wrong branch (diagnosing-with-the-oscilloscope). The failures this prevents: a flowchart mistaken for a tree, a bench's knowledge walking out the door in one head, a new hire idle for a month, and a diagnosis marched confidently past a tree's edge to the wrong leaf.

Common Challenges

  • Steps masquerade as tests. "Check the fuse" is a step; "fuse continuity: intact or open?" is a test with two branches — the difficulty is rewriting habitual actions as decisions whose outcomes actually split the space (fault-isolation-by-divide-and-conquer).
  • Criteria drift toward vibes. "Looks low," "seems noisy," and "feels hot" cannot branch — the difficulty is forcing every criterion to a number or a yes/no observation, which the volume's measurement discipline makes possible but habit resists (the-troubleshooting-process).
  • The tree invites false completeness. A drawn tree looks authoritative, edges and all — the difficulty is holding the map/territory distinction: a tree encodes the faults its author knew about, and the device has not read it.

Safety Notes

Risk Level: Low. This section is paper and thinking — but the trees it teaches will order real tests on real hardware, so safety enters as a design rule.

Professional Tips Before Starting

  • Read three trees before writing one. Service manuals, public guides, your own notes — the weaknesses you spot in theirs are the checklist for yours (the-troubleshooting-process).
  • Count the split at every node. Ask of each test: how much of the fault space does each answer eliminate? — a node that eliminates nothing is a step wearing a tree's clothes (fault-isolation-by-divide-and-conquer).
  • Draft in pencil, on purpose. The first tree is a hypothesis about the family's faults — the case records will revise it, so build for revision.

The Shape of Structured Isolation — Trees, Nodes, and Edges

Recap and Frame

Chapter 1 taught half-splitting as judgment; nine chapters exercised it; this chapter writes it down, and writing has a grammar (fault-isolation-by-divide-and-conquer). The tree is the written form. Fault isolation becomes a drawn structure: tests at the nodes, outcomes on the branches, verdicts and actions at the leaves — the same divide-and-conquer, now external to any one head. Externalising changes what the method can do. A written tree can be followed by another hand, criticised at leisure, taught in an afternoon, and improved by every case that flows through it — none of which recall can offer (the-troubleshooting-process). The volume already built the content. The route from the oscilloscope chapter — rails, then clock and reset, then the signal path — is a tree's top three nodes in prose, and the intermittents campaign's records are branch statistics waiting to be drawn (diagnosing-with-the-oscilloscope). This section is the grammar, not yet the writing. What a tree is, why it beats recall, what makes a node good, what shapes a whole tree, and where trees end — the judgment needed to read structure critically before building it (from-reproduction-to-verified-repair). And the edges are part of the grammar. A tree is a map of known faults; the chapter ahead teaches building, using, escaping, and growing them precisely because no map survives contact with every device. Hold the frame — a written form, new powers, content already earned, grammar before construction, edges acknowledged — and structured isolation starts from understanding rather than imitation.

The Tree Itself — Tests, Branches, and Leaves

The form is simple enough to draw on a card, and every part of it has a job (fault-isolation-by-divide-and-conquer). Nodes hold tests. Each node asks one question of the device — a measurement, an observation, a swap — and the question is the node's whole content: "5-volt rail at the regulator output: above 4.75 volts?" Branches hold outcomes. Each possible answer leaves the node on its own branch — yes and no for a threshold, three ways for a range test — and every outcome the test can produce must have a branch, because an answer with nowhere to go strands the diagnosis. Leaves hold actions. A path ends at a verdict ("regulator confirmed failing — replace and verify"), a next procedure ("run the family's charging-fault tree"), or an honest escalation ("mains-side work — isolation and experience required") — never at a shrug. The shape encodes the strategy. Which test sits at the root, which follow each branch — that ordering is the diagnosis strategy, written where it can be argued with; the drawing is the easy part and the ordering is the craft (the-troubleshooting-process). A flowchart fails this grammar. "Clean the contacts, then reseat the cable, then check the fuse" is a to-do list — no outcomes, no branching, no isolation — and most published "troubleshooting charts" are exactly this, which is why they run to forty boxes. Tests at nodes, every outcome a branch, every leaf an action, ordering as the strategy, and flowcharts recognised as impostors — that is the whole form. Draw the method as decisions, and the drawing starts doing method's work.

Why Structure Beats Recall

The tree's advantages are bench advantages — mundane, cumulative, and decisive over a year (the-troubleshooting-process). Consistency survives fatigue. Recall runs differently at hour one and hour nine; the tree asks the same questions in the same order every time, and the questions were designed once, calmly, instead of improvised under a deadline. Knowledge stops walking out the door. A bench's diagnostic edge usually lives in its most experienced head, and every departure takes it along — a tree is that edge written down, owned by the bench instead of the individual (from-reproduction-to-verified-repair). Teaching gets an artifact. A new hire cannot inherit judgment, but they can run a tree in week one — and the points where the tree confuses them are exactly where it needs revision, so teaching and improving become the same activity. Improvement gets an address. When a diagnosis goes wrong, "where did the tree mislead?" has an answer — a specific node, a vague criterion, a missing branch — and the fix lands in the structure, permanently, instead of in one person's memory (fault-isolation-by-divide-and-conquer). Speed follows from design. A tree built from half-splitting eliminates most of the fault space in its first two nodes, so the common cases resolve in minutes — not because anyone hurried, but because the ordering did the hurrying in advance. Consistent under fatigue, durable past departures, teachable in a week, improvable at an address, and fast by design — those are the reasons to write it down. The tree is the bench's memory given a spine.

The Good Node — Anatomy of a Discriminating Test

Trees are only as good as their nodes, and a node is only as good as its test (fault-isolation-by-divide-and-conquer). The test must discriminate. A discriminating test's answers split the fault space — each outcome eliminates a real set of suspects — and a test whose every answer leaves the same suspects standing is a step, not a node, however useful the step may be. Cheap comes before expensive. Of two tests with similar discriminating power, the one that costs seconds beats the one that costs disassembly — the node's price is paid on every diagnosis that reaches it, forever (the-troubleshooting-process). Decisive beats suggestive. A test that settles its question ("continuity: open") outranks one that hints ("resistance seems high-ish"), because a suggestive answer forks the diagnosis into interpretation instead of branches. Safe ordering is part of the test. A node inherits the volume's disciplines — discharge before touching, isolation before mains-referenced probing — and the tree sequences those checks before the tests that assume them, because the follower may not know what the author knew. The criterion must be measurable. "Rail below 4.75 volts," "the 47 µF output cap reads over 3 ohms ESR," "boots to logo: yes/no" — numbers and observations branch; "looks low" and "seems slow" cannot, and every vague criterion in a tree is a place where two followers will take two different branches (diagnosing-with-the-oscilloscope). Discriminating, cheap, decisive, safely ordered, and measurable — five checks that take a minute per node and decide whether the tree works. Interrogate every node like a suspect, and the tree earns its authority.

The Good Tree — Shape, Spine, and Leaves

Beyond good nodes, the whole tree has a shape that makes or breaks it (the-troubleshooting-process). Traffic and price order the tree. The tests that are cheap and the faults that are likely belong near the root — the case records say which branches carry the family's real traffic, and the top of the tree is where that traffic should flow (from-reproduction-to-verified-repair). The universal spine tops every tree. Power, then heartbeat, then path — the route the oscilloscope chapter assembled — is the device-agnostic opening every family tree shares, because nothing downstream means anything until the rails and the clock are cleared (diagnosing-with-the-oscilloscope). Depth beats breadth when nodes discriminate. Four good binary questions in sequence cover sixteen outcomes; a tree that goes wide instead of deep is usually hiding non-discriminating nodes — breadth is what steps look like when drawn as branches. Every leaf is an action. Verdict, procedure, or escalation — and the escalation leaf is a feature, not a failure: "beyond this tree — return to method" is the honest edge of the map, drawn on the map. The tree stays one page. A tree that outgrows a page is usually two trees — a universal top and a family procedure — and splitting them keeps both followable at bench speed. Ordered by traffic and price, opened by the spine, deep rather than wide, every leaf an action, and sized to a page — that is the shape. Shape the tree the way the volume shaped the method, and following it feels like being taught.

The Edges — What a Tree Is Not

The last piece of the grammar is the map's edge, because trees fail exactly where their authority feels strongest (the-troubleshooting-process). A tree encodes known faults. Its author drew the failures they had seen or filed; the device in the vice has not read the records, and a fault outside the tree's experience will be forced into the nearest wrong leaf by anyone following on autopilot (from-reproduction-to-verified-repair). Symptoms off the map are the tell. When the device's behaviour matches no branch — or matches a branch but the leaf's repair does not verify — the tree has run out, and the move is the one the volume spent nine chapters teaching: back to first-principles method, with the tree's progress kept as evidence (diagnosing-with-the-oscilloscope). Trees age. Board revisions change rails, suppliers change failure patterns, and last year's dominant branch goes quiet — an unmaintained tree drifts from map toward myth, which is why growing and pruning get their own section. Authority transfers, judgment does not. A tree lets a newer hand run an expert's ordering, but the expert's scepticism must be taught beside it — the follower who can say "this answer surprises me" is using the tree; the one who cannot is being used by it (fault-isolation-by-divide-and-conquer). And the chapter ahead is the edges' answer. Building trees (next), the universal tree, using and escaping them, and growing them from records — each section exists because of an edge this one has named. Known faults only, off-map symptoms as the tell, aging as drift, judgment untransferred, and the chapter as the answer — those are the edges. Trust the tree like a good map: completely, until the ground disagrees.

Common Mistakes

  • Drawing steps and calling them nodes. "Clean the connector" has no outcomes and splits nothing — every node must hold a test whose answers eliminate suspects (fault-isolation-by-divide-and-conquer).
  • Writing criteria that cannot branch. "Looks low" sends two followers down two branches — force every criterion to a number or a yes/no observation (the-troubleshooting-process).
  • Burying the likely faults deep. A tree that reaches the family's most common failure at node nine wastes every diagnosis — let the case records order the tree, traffic first (from-reproduction-to-verified-repair).
  • Ending paths in shrugs. A leaf that says "?" strands the follower — every leaf is a verdict, a procedure, or an honest escalation.
  • Following past the edge. Forcing an off-map symptom into the nearest branch marches confidently to the wrong leaf — when nothing matches, escape to method and keep the tree's progress as evidence (diagnosing-with-the-oscilloscope).

Troubleshooting Guidance

Thinking in trees comes down to form, reasons, nodes, shape, edges. If a guide's boxes list actions without outcomes: it is a flowchart — mine it for tests, but do not follow it as isolation (fault-isolation-by-divide-and-conquer). If two technicians run the same model differently: the bench needs the better route written down — that difference is the cost of recall (the-troubleshooting-process). If a node's answers all leave the same suspects: it is a step in tree's clothing — replace it with a test that splits. If a criterion says "looks" or "seems": rewrite it to a threshold or a yes/no before two followers diverge on it. If the family's common fault sits deep in the tree: reorder — the case records say where the traffic is, and traffic belongs near the root (from-reproduction-to-verified-repair). If a path has no good ending: write the honest leaf — verdict, procedure, or escalation — because a shrug strands whoever trusted the tree. If a device's behaviour matches no branch: the map has ended — return to the volume's method, carrying the tree's progress as evidence (diagnosing-with-the-oscilloscope). If the tree has outgrown its page: split it — a universal top and a family procedure follow better than one sprawling drawing. The throughline: read every tree — including your own — node by node, split by split, edge by edge, exactly the way the volume taught you to read a board.

Verification & Testing Methods

Confirm the grammar landed before the chapter builds on it:

  • [ ] I can define a troubleshooting tree — tests at nodes, every outcome a branch, every leaf an action — and tell it from a flowchart by asking whether each box's answers actually split the fault space.
  • [ ] I can give the bench reasons structure beats recall — consistency under fatigue, durability past departures, teachability, improvement with an address, and speed by design — and say which one my own bench needs most.
  • [ ] I can interrogate a decision node with the five checks — does its discriminating test split the space, is it cheap before expensive, decisive rather than suggestive, safely ordered, and measurable in its criterion?
  • [ ] I can judge a tree's shape — traffic and price ordering, the universal spine on top, depth over breadth, action leaves, one page — and say what each violation costs the follower.
  • [ ] I can state the edges — known faults only, off-map symptoms as the tell, aging as drift, judgment untransferred — and name where the chapter ahead answers each.

Then try the practice exercises below — paper tree work; scenarios differ from the quiz.

Practice Exercises

  1. Convert a flowchart into a tree (5 minutes, paper). Take a service manual's or public guide's troubleshooting chart and rewrite five of its steps as decision nodes — one test each, every outcome a branch — marking which original boxes turned out to be steps with no discriminating power (fault-isolation-by-divide-and-conquer).
  2. Interrogate three nodes (5 minutes, paper). For three nodes — one from your conversion, two invented — run the five checks: split, price, decisiveness, safe ordering, measurable criterion; rewrite any criterion that says "looks" or "seems" into a threshold (the-troubleshooting-process).
  3. Order a tree by traffic and price, and say what the structure buys (5 minutes, paper). Given six tests for an imagined device family and a tally of its last ten faults, arrange them into a tree — spine first, traffic-heavy branches high, expensive tests deep — write one honest escalation leaf, and finish by naming the one bench reason this written ordering buys over recall — consistency, durability, teachability, an improvement address, or speed — and for whom (from-reproduction-to-verified-repair).
  4. Find the edge (5 minutes, paper). Walk a given mini-tree against a scenario whose fault its author never filed, mark the exact node where the map runs out, and write the escape: what evidence the tree's progress has already produced, and where the volume's method resumes (diagnosing-with-the-oscilloscope).

These core steps — telling trees from flowcharts, interrogating nodes, shaping by traffic and spine, and respecting the edges — are tested in the Chapter Quiz at the end of this chapter, where a score of 80% is required to continue.

Key Takeaways

  • A troubleshooting tree is fault isolation written down as decisions — tests at nodes, every outcome a branch, every leaf an action — half-splitting made external, repeatable, and criticisable; a flowchart of steps is not a tree, however it is drawn (fault-isolation-by-divide-and-conquer).
  • Structure beats recall for bench reasons: consistency under fatigue, knowledge that survives departures, a teaching artifact for the newest hand, improvement with an address, and speed designed in — the tree is the bench's memory given a spine (the-troubleshooting-process).
  • A good decision node holds a discriminating test — its answers genuinely split the fault space — and passes five checks: cheap before expensive, decisive rather than suggestive, safely ordered, and measurable in its criterion, because "looks low" sends two followers down two branches.
  • A good tree is shaped: traffic and price order it, the universal spine — power, heartbeat, path — opens it, depth beats breadth, every leaf acts, and one page is the limit — past that it is two trees (diagnosing-with-the-oscilloscope).
  • A tree is a map, not the territory: it encodes only its author's known faults, ages as devices and failure patterns drift, and transfers authority without judgment — off-map symptoms mean escape to method, and the chapter ahead teaches building, using, escaping, and growing the maps (from-reproduction-to-verified-repair).

Skills Learned

  • You can now explain what a troubleshooting tree is — tests at the nodes, outcomes on the branches, verdicts at the leaves — and how it differs from a flowchart of steps.
  • You can now explain why written structure beats recall: consistency, teachability, and durability of the bench's expensive lessons.
  • You can now judge a single decision node — cheap, decisive, safe in its ordering, and measurable in its criterion.
  • You can now judge a tree's shape — likely and cheap near the top, the universal spine before family specifics, and every leaf an action.
  • You can now state a tree's limits — a map that runs out, ages, and misleads past its edges — and where the chapter ahead takes each of them.

Glossary Additions

  • troubleshooting tree — fault isolation written down as a decision structure: a test at every node, a branch for every outcome the test can produce, and an action at every leaf — a verdict, a next procedure, or an honest escalation. The tree is divide-and-conquer made external: the ordering of its nodes is the diagnosis strategy, designed once at leisure and then followed consistently across tired days and different hands, taught to new technicians as an artifact, and improved at a specific address whenever a case shows a node misleading. It differs from a flowchart in one decisive way — a flowchart lists steps, while a tree's nodes carry discriminating power, each answer eliminating real suspects — and it remains a map rather than the territory: it encodes the faults its author knew, runs out at its edges, and ages as devices and failure patterns drift.
  • decision node — a single point in a troubleshooting tree holding one test of the device, with a branch leaving it for every outcome the test can produce. A good node passes five checks: its test discriminates (each answer genuinely splits the space of possible faults — otherwise it is a step, not a node), it is cheap before expensive (its price is paid by every diagnosis that reaches it), decisive rather than suggestive (the answer settles the question instead of inviting interpretation), safely ordered (discharge, isolation, and access precautions sequenced before the tests that assume them, because the follower may not know what the author knew), and measurable in its criterion — "rail below 4.75 volts" branches cleanly where "rail looks low" sends two followers down two different branches.
  • discriminating test — a test whose possible answers each eliminate a real set of fault suspects, so that performing it genuinely shrinks the space of what could be wrong; the property that separates a troubleshooting tree's nodes from a flowchart's steps. Discriminating power is what makes half-splitting arithmetic work — four good binary tests cover sixteen outcomes — and it is judged by asking, for each possible answer, "what does this rule out?": a test for which every answer leaves the same suspects standing has no power, however useful it is as an action. Among tests of similar power, the cheap, fast, and safe one wins the earlier place in the tree, because a node's cost is paid on every diagnosis that flows through it.

Suggested Next Sections

Must read next:

  • Building a Troubleshooting Tree — Section 10.2 turns the grammar into construction: choosing the root, mining tests from the volume's methods and the family's records, drafting the branches, and walking the first cases through to find the weak nodes.

Recommended: