A visual introduction

x → f() → y

A design can pass every test we give it and still fail to produce the change we wanted.

The Fit Check Error Model makes the chain from framing to outcome inspectable, one idea at a time, with one example all the way through. Scroll, or tap Next.

By Matt Lane

The catalog team and all numbers in this guide are fictional teaching examples.

Part 1 · The claim1 / 32
Skip to recap ↓
or use ← → keys

Your turn

Find the fault

In the story, a missing requirement caused the miss. But the same visible symptom—effect only partly—can begin at different points in the chain. Watch examples travel forward, then hide one and diagnose backward.

    Real failures can have more than one cause, and later checks can miss a break. Each case here starts from one.

    What to remember

    1. x→f()→yIt’s a claim. Test it; don’t assume it.
    2. Eᶜ · EᵉTwo different judgments. Conformance asks whether the design—and later the built thing—meets R under M. Effect asks whether reality moved toward y and what supports attribution. They can disagree.
    3. x · y · M → RFrame without the answer. Keep the reason, model the operating world explicitly, and give every requirement a source.
    4. ✓ ✗ ?Compare real options. An unknown isn’t a pass, and a missed must-have can’t be averaged away. Passing makes an option eligible, not chosen, and building nothing is always an option.
    5. parts × RTurn the table. Every part needs a reason; an empty row exposes a missing justification. Account for each requirement through a mechanism or a separate constraint check. A full table still isn’t proof.
    6. vs.Judge effect against a comparison, and check who got measured.
    7. ← ← ←Diagnose backward before you blame the build. Then version what changed, and rerun what depended on it.

    Build forward. Verify locally. Diagnose backward. Correct against reality.

    Run a Fit Check Use the full shaping skill Practice with the flash cards

    The catalog example and its numbers are made up to illustrate the model.

    Use it

    Run a Fit Check

    Phase 1 · Fit Check: hold x, y, M, and R fixed. Requirements run down the rows; candidate paths in S run across the columns. Judge each whole path against the same requirements. Phase 2 · Reverse Fit: rotate the selected path. Put its meaningful parts down the rows and R across the columns to see what covers each requirement—and what justifies each part. It opens on the catalog example, so change anything. Meaningful edits flag affected judgments for review.

    Your problemExample: the catalog editors

    Read across a requirement row to compare paths; read down a candidate column to check its whole fit. A path must clear every must-have to remain eligible. Tap a cell to judge it: ✓ meets it, ✗ misses it, ✗? not known yet (counts as ✗), ✓! risk accepted (counts as ✓).

    ↻ means a previous judgment needs review. Scroll wider tables sideways.

    Draft saved in this browser. It is not synced to another device. Download or copy Markdown to keep a separate record.

    Show the Markdown