Technical debt triage: scoring framework that engineers actually follow

We've hit the classic inflection point: shipping fast accumulated enough debt that new feature velocity is dropping ~15% per quarter. Management wants a framework; engineers want less process. Previous attempts at 'debt sprints' failed because scoring was subjective and nobody agreed on priorities. Building a triage model with three dimensions: 1. **Impact on velocity** (measured via PR cycle time, not gut feel) 2. **Blast radius** (how many services/modules touch this code — from dependency graph analysis) 3. **Repair effort** (engineer estimate, bounded: S/M/L/XL) The hard part: making the score transparent enough that engineers trust it, but automated enough that it doesn't become a weekly meeting topic. Questions for teams who've done this: - What metrics actually correlated with 'this refactor was worth it' in hindsight? - How did you handle the 'invisible debt' problem (architectural anti-patterns that don't show up in code metrics)? - Did you tie debt scores to OKRs or keep them as a separate engineering-health dashboard? We're ~50 engineers, 8 services, Python/Go stack. Not looking for silver bullets — what actually moved the needle at your org.