Capability Equivalence Matrix¶
Decision artifact — instantiates Encapsulated Substitutability
Lays every role requirement in a grid against incumbent and candidate — with the evidence for each, the gaps, and the differences someone has explicitly signed off as acceptable.
Capability Equivalence Matrix is a structured comparison whose rows are the requirements of the role and whose columns are the incumbent and each candidate substitute. Each cell records the capability, the evidence behind the claim, and a verdict: meets, degrades acceptably, or gap. Its defining move is that it forces every requirement to be named and adjudicated before a swap, and it captures not merely "can it?" but "is the difference acceptable, and who agreed?" It is a decision artifact — the thing you can hand to an approver — not a test harness that generates evidence, nor a rollout that acts on it.
Example¶
An EV maker qualifying a second source for a battery cell (to escape single-supplier risk) builds a matrix. The rows are the role's real requirements — energy density, cycle life, thermal-runaway threshold, fast-charge curve, dimensional envelope, cost per kWh. The columns are the incumbent cell and two candidates. Each cell holds the number, its evidence grade (vendor datasheet vs. the maker's own abuse testing vs. "unverified"), and a verdict. Candidate A meets energy density but shows roughly 8% shorter cycle life — logged as an accepted degradation, signed off by the battery-safety lead with a note that pack sizing compensates. Candidate B's thermal-runaway threshold is unverified — a hard gap that blocks. The trade is now explicit and owned before any tooling is committed, rather than discovered after.
How it works¶
Three properties distinguish it. It is requirement-indexed — each row is a promise the role makes, so nothing is compared "in general." It is evidence-graded — a cell without evidence is a red flag, not a pass, which is what stops a datasheet claim from masquerading as a verified capability. And it separates three cell states rather than two: meets, acceptable degradation (with the degradation criteria and a sign-off recorded), and gap. The accepted differences do not vanish into silent tolerance; they become named exceptions, each with an owner and, ideally, an expiry.
Tuning parameters¶
- Requirement granularity — coarse rows are quick but hide sub-differences; fine rows catch more but bloat the grid and invite false precision.
- Evidence bar per row — a datasheet claim versus independent testing. Set a high bar for safety- or correctness-critical rows and a lower one for cosmetic ones.
- Equivalence threshold — how close counts as "equivalent," and how much shortfall counts as "acceptable degradation," row by row.
- Weighting (must vs. nice) — which rows are veto conditions (a single gap blocks) versus tradeable against strengths elsewhere.
- Exception expiry — whether an accepted difference is permanent or must be revisited by a set date or milestone.
When it helps, and when it misleads¶
Its strength is that it turns "seems comparable" into an auditable, owned adjudication: gaps surface before commitment, and every accepted difference carries a name. Its central blind spot is that the matrix can only reason over the rows someone wrote — the requirement nobody thought to list, which is exactly the undocumented behavior the archetype is built to defend against, never appears at all. This is a textbook case of What You See Is All There Is.[1] The classic misuse is filling the grid green after a supplier has been chosen, to manufacture a justification. The discipline that guards against both is to derive rows from the observable-behavior specification and real incident history rather than the incumbent's brochure, and to treat every empty-evidence cell as a gap until proven otherwise.
How it implements the components¶
Capability Equivalence Matrix fills the comparison-and-adjudication subset — the parts a decision artifact produces:
capability_matrix— it is the requirement-by-candidate grid, each cell carrying the capability and its evidence.equivalence_and_degradation_criteria— each row states what counts as equivalent and how much degradation is tolerable; the verdicts are those criteria applied.substitution_exception_register— the "accepted differences" become a register of signed-off deviations, each with an owner and expiry.
It does not generate the conformance evidence its cells cite — that is produced by Contract Test Suite, Golden Master or Trace Comparison, and live trials — and it does not decide go/no-go or execute the switch; the gate and the rollout belong to Supplier or Model Homologation and Blue-Green or Canary Replacement.
Related¶
- Instantiates: Encapsulated Substitutability — the matrix is where "does the substitute really fill the role?" is made explicit and owned.
- Consumes: Contract Test Suite and Golden Master or Trace Comparison supply the conformance evidence recorded in its cells.
- Sibling mechanisms: Blue-Green or Canary Replacement · Contract Test Suite · Adapter or Facade Layer · Dependency Injection or Plugin Slot · Fallback Switch or Kill Switch · Golden Master or Trace Comparison · Parallel Run Reconciliation · Service-Level Regression Monitor · State Migration Playbook · Supplier or Model Homologation
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: The mechanism lays role requirements against incumbent and candidate evidence with meets, accepted degradation, and gap states, so its operative form is an equivalence matrix.
Nearest alternative: Assessment, Review & Assurance — Evidence is judged to populate cells, but the persistent requirement-indexed comparison artifact is the mechanism.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Substitution and procurement practice established requirement-by-candidate matrices with evidenced gaps and signed exceptions.
Related originating lineages:
- Engineering & Design — Systems engineering supplies requirement-indexed verification, evidence, tailoring, and candidate qualification.
- Law & Governance — Formal approval, exception ownership, and expiry make accepted differences accountable rather than implicit.
- Operations Research — Structured multi-criterion comparison supplies the matrix form and explicit degradation tradeoffs.
Review resolution: Organizational management is primary because the matrix supports an accountable substitution decision across role requirements. Systems engineering contributes requirement-by-requirement evidence and acceptable tailoring, operations research contributes structured comparison, and law contributes explicit exception acceptance; the combined artifact is a multi-domain synthesis.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Sources consulted:
References¶
[1] Kahneman, D. Thinking, Fast and Slow. Farrar, Straus and Giroux (2011). Defines WYSIATI as constructing a coherent judgment from available information while neglecting evidence that is absent. registry ↩