Tool 5 of 32 · an afternoon
Convergence Test
Pairs of numbers that must agree, traced down to their shared root. The count of patches on the way down is the depth gauge.
Disagreeing pairs get flagged during Reality. The trace down to the shared root runs in Depth, before the working session that sizes the fix.
What it is for
To measure how deep a problem actually goes, by tracing two numbers that must agree down to their shared source and counting the patches on the way.
The failure it catches
Interviews can be managed; arithmetic cannot. Companies hide root-cause debt under patches until nobody knows which number is true.
Why it works
A pair that must agree, run both ways, reports disagreement as a fact. Counting every patch, special case and correction on the way down turns an argument about depth into a count.
How to run it
- Ask the team to name two or three pairs of numbers that must agree: two reports drawing on the same data, the same total computed two ways. You do not invent the pairs; they name them.
- Bias the search toward hard pairs. Money that leaves in a different shape from how it came in. Anything that crosses a boundary: currencies, entities, time zones, systems. A month nobody wants recomputed from raw data. A number two departments both report from their own systems. A spreadsheet somebody maintains by hand.
- Run both paths. When a pair disagrees, follow the disagreement down to its shared source.
- Count and date every patch, special case and correction you pass. Copied patches count separately.
- At the root, write the plain sentence for what is actually wrong down here.
How to read the result
The count of patches stacked on a root is the depth gauge. Zero or one is a healthy area. Two to four means the area is infected but can be fixed surgically. Five or more usually means rebuilding that area costs less than continuing to patch it, and the honest price of having waited includes re-fixing every symptom that was patched on top. Patch dates spread across months tell you how long the company has been paying interest on this. These cutoffs are our judgment from field cases, not laboratory science, and we say so. A pair that happens to agree proves little.
How to run it well
- You need to know what the number should be from first principles, or you cannot tell which path is wrong.
- Count layers, not people. Every codebase that has survived contact with customers has these.
Where it breaks
- A pair that happens to agree proves little, so pick hard pairs.
- Without knowing what the number should be top-down, you cannot tell which path is wrong.
- Needs read access. A pair you cannot actually run is not a trace.
What would prove it wrong
A depth-five trace whose area then behaves fine for months without rework would weaken the depth scale.
What we watch
Whether areas that read five-plus keep needing rework, or whether a deep count sometimes sits over a module that then stays quiet.
Ask yourself
- Name two numbers in this company that must agree and come from different places.
- Which report do you trust least, and what would you check it against?
- What number do two teams both report, each from their own system?
- Have you ever seen a number disagree with itself, and what explanation was given?
- If you deleted the special cases on the way down to the source, what would read wrong, and who would notice first?
Fed by: Recurrence Ledger, Diagnosis Bias Scan
Feeds: Patch Validity Test, Compounding Check, Leverage Layer, Stability Test, Room Bias Scan