A layered framework — not a matrix. Three filters, four lenses, five tiers.
Most attempts to systematize engineering judgment end up as scoring grids: rate the change on five axes, sum the score, ship. These don't work. They flatten decisions that have structure. They produce inconsistent verdicts across people. They don't teach the reasoning underneath them.
Seven binary axes produce 128 cells, and 128 cells is a lookup table — not a framework. Lookup tables don't scale, don't teach, and don't degrade gracefully when reality presents an attribute the table didn't anticipate.
A working framework isn't a wider matrix. It's a sequence of filters — each one resolving a different question, each one narrowing the field for the next.
Every change passes through three screening questions before any heavier process runs.
Can this break customer trust if it goes wrong?
Data integrity, money, availability, privacy. Anything where the failure mode reaches the customer.
Does this commit the company to a path that takes more than one quarter to walk back?
Vendor lock-in, architectural irreversibility, organizational restructuring, public commitments.
Does this require coordination across teams or with non-engineering functions?
Product, legal, finance, support, executive — anyone outside the change's home team.
Three "no"s — it's a normal pull request. Any "yes" — the change earns a heavier analysis and proceeds to Layer 2.
The dominant lens drives the decision. The question is which one is the binding constraint for this change.
Cost Lens — Input
What does this take to build?
Lead time and effort are merged because they correlate strongly. Cases where they diverge are themselves a signal — typically of coordination cost, which is its own diagnostic.
Blast Lens — Downside
What's the worst plausible damage if this fails?
Customer visibility is a modulator on this lens, not a separate axis. Visibility multiplies trust damage but doesn't generate it independently. An invisible data corruption is still a trust event when it surfaces.
Recovery Lens — Response
How fast can we get back to a safe state?
MTTD and undo effort compound. Slow detection means the damage has accumulated before the revert button is reached. Fast MTTD with painful undo is recoverable. Slow MTTD with cheap undo often isn't.
Commitment Lens — Optionality
How much future flexibility does this consume?
This is the lens most frameworks miss. Some changes preserve optionality; some consume it. The cost is real even when nothing "goes wrong" — it's paid in lost ability to choose differently later.
Each tier maps to a real artifact and a real approval surface.
Not a replacement for prioritization or strategy tools — it sits downstream of them, at the point where a change is already in scope and the question is how much process it earns.
Frameworks exist to make decisions consistent across people, teachable to newcomers, and resilient to the absence of the person who invented them. A framework that requires its author to interpret it has failed. The test of this one is whether two engineers using it independently arrive at the same tier.
Daniel Brasileiro