Quality-Risk Triage Rubric¶
Decision rubric — instantiates Technical Debt Buffering and Rework Absorption
Distinguishes tolerable, reversible, low-blast-radius debt from debt that threatens safety, trust, compliance, data integrity, or irreversible architecture.
A Quality-Risk Triage Rubric is the front door of the buffer: a fixed set of questions applied to each proposed compromise, at the moment of borrowing, that sorts it into borrowable-and-bounded versus not-borrowable-at-all. Its one defining move is drawing the exclusion line — the archetype insists that safety-critical, legal, privacy, security, and irreversible-architecture obligations are not ordinary debt, and the rubric is where that line is actually enforced, item by item, before anything is accepted. It forces two things to be said out loud: why we want to borrow here (the buffering intent) and what kind of risk this particular item carries (reversibility, blast radius, compounding). Unlike a ledger, it does not track anything over time and unlike a gate it does not measure aggregate load — it is a per-item admission test that runs once, at intake.
Example¶
A medical-device company is under deadline to ship a firmware update for an infusion pump, and the team is tempted to defer several pieces of work to make the date. They run each candidate through the triage rubric. Deferring the localized-language UI strings: reversible, low blast radius, no clinical effect — the rubric asks for a one-line intent statement ("buffering the certification deadline; English-only ships, translations follow"), classifies it low-risk reversible debt, and admits it inside the acceptable boundary. Deferring a rounding-fix in the dose-calculation path: the rubric's first screen — "does this touch patient safety, data integrity, or an irreversible decision?" — returns yes, and the item is stamped excluded, not debt. It does not get an intent statement or a due date; it simply cannot ship deferred.
The rubric's whole output is that partition: a short list of admitted, classified, intent-stated debts that may go into the buffer, and a hard-stop list of things that were never eligible. It never touches the aggregate — it does not know or care how much total debt the team is carrying. It only answers, for each item, may this be borrowed at all, and on what terms?
How it works¶
The rubric is a small, ordered decision tree applied per candidate item:
- Exclusion screen first. A short list of disqualifying questions — safety, legality, privacy, security-critical controls, irreversible architecture, high-trust commitments. Any "yes" ends the analysis: it is not debt, it is out of scope for the buffer.
- Require a buffering intent. For anything that passes, the borrower must state the pressure being bought down — the deadline, the learning, the continuity — in one sentence. No stated intent, no admission.
- Classify the surviving item. Score it on reversibility, blast radius, and compounding behaviour, producing a risk class the rest of the machinery can act on.
- Emit the partition. Return the admitted-and-classified set (for the ledger to record) and the excluded set (which must be done now or the release replanned).
It runs before the ledger and the ceiling gate; it is the intake filter, not the accountant.
Tuning parameters¶
- Exclusion-list breadth — how many categories are hard-excluded. A broad list is safer but can block legitimate buffering; a narrow one is permissive but risks admitting things that should never be debt.
- Risk-dimension set — which axes you score (reversibility, blast radius, compounding, detectability). More axes are more discerning but slower and more subjective.
- Threshold strictness — how a borderline item resolves (admit, admit-with-conditions, or refer up). Strict defaults protect quality; loose defaults protect flow.
- Who applies it — self-service by the borrowing engineer vs. a reviewer. Self-service scales but drifts; a reviewer is consistent but a bottleneck.
- Evidence required — a gut answer vs. a documented rationale per question. Documentation improves auditability and slows the front door.
When it helps, and when it misleads¶
Its strength is that it refuses the most dangerous move in the whole pattern — quietly treating a safety, trust, or irreversibility obligation as if it were a schedulable corner to cut. By making the exclusion explicit and per-item, it keeps the buffer legitimate. It also forces intent into the open, so debt is taken for a reason rather than by reflex.
Its failure mode is normalization of deviance[1]: each individual admission looks reasonable, the boundary creeps outward one defensible exception at a time, and eventually things that would have been excluded a year ago sail through as "the kind of debt we take." The classic misuse is running the rubric as after-the-fact justification — deciding to ship, then filling in the questions to bless it — which inverts an admission test into a rubber stamp. The guarding discipline is to keep the exclusion screen bright-line and non-negotiable, periodically re-audit admitted items against the original criteria to catch drift, and require the intent statement before the decision, not after.
How it implements the components¶
This mechanism fills the archetype's intake-decision slice:
acceptable_debt_boundary— its core: the per-item line between borrowable-and-bounded and categorically-excluded.debt_buffer_intent_statement— it requires each admitted item to name the pressure being bought down before it is allowed in.debt_item_inventory_and_classification— it produces the initial risk classification (reversibility, blast radius, compounding) that later mechanisms record and act on.
It does NOT implement debt_ceiling_and_saturation_threshold — the aggregate cap and its enforcement belong to Debt Ceiling Gate; the rubric judges each item on its merits at intake, the gate judges the total load. It also does not record ownership_and_accountability_record over time — that is Technical Debt Ledger.
Related¶
- Instantiates: Technical Debt Buffering and Rework Absorption — supplies the admission test that keeps non-borrowable obligations out of the buffer.
- Sibling mechanisms: Debt Aging Dashboard · Technical Debt Ledger · Debt Ceiling Gate · Exception Expiry Timer · Feature Flag or Containment Wrapper · Hardening Window · Rework Capacity Allocation Rule · Post-Release Rework Retrospective
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Quality-Risk Triage Rubric operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it distinguishes tolerable, reversible, low-blast-radius debt from debt that threatens safety, trust, compliance, data integrity, or irreversible architecture.
Independent corroboration: The frozen evidence defines Quality-Risk Triage Rubric as 'Distinguishes tolerable, reversible, low-blast-radius debt from debt that threatens safety, trust, compliance, data integrity, or irreversible architecture', so its operative form is Decision, Gate & Allocation.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Because the rubric explicitly triages technical debt by architectural lock-in, integrity, and software blast radius, software engineering is the closest primary lineage; SEI treats architectural risk and technical debt as a linked management problem.
Related originating lineages:
- Engineering & Design — Safety and reliability risk matrices supplied severity-based triage.
- Organizational & Management Science — Risk ownership and escalation rubrics supplied governance of remediation priority.
Review resolution: The blind reviewers disagreed on primary lineage. Light authoritative research resolves the defining form in favor of computer_science: Because the rubric explicitly triages technical debt by architectural lock-in, integrity, and software blast radius, software engineering is the closest primary lineage; SEI treats architectural risk and technical debt as a linked management problem. The other materially formative traditions are retained as alternates; current breadth of use remains separate as domain_reach=multi_domain.
Attribution caveat: The named rubric is an encyclopedia synthesis. The exact multi-factor rubric is a synthesized technical-debt instrument.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
References¶
[1] Vaughan, D. The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA. University of Chicago Press (1996). Describes repeated danger signals becoming acceptable through an incremental normalization of deviance. registry ↩