The engineering technical debt triage decision record: why the triage model you chose determines your debt prioritization accuracy and your remediation velocity ceiling

A 14-person developer tools startup had been operating for three years without a systematic technical debt triage process. The team addressed technical debt opportunistically: engineers who encountered a particularly frustrating area of the codebase would propose a "debt sprint" in the next planning cycle, the team would agree, and a sprint would be blocked out for refactoring work in whatever area had prompted the proposal. The engineers who proposed debt sprints were, naturally, the engineers who had spent the most time working in a given area recently — the engineers who knew it well enough to find it frustrating. The debt items addressed in each sprint were the ones that the proposing engineer considered most important, which tended to be the ones that had been blocking their own recent work.

The startup's most experienced backend engineer, who had been with the company since the first year, left to join a Series B company. Her replacement took four weeks to reach the level of productivity at which the previous engineer had been operating. The engineering manager reviewed the support requests the new engineer had made during his first four weeks and found a consistent pattern: nearly all of them concerned the authentication subsystem, which had been built in the first year of the company and modified incrementally through three years of feature additions without ever being comprehensively refactored. The authentication subsystem had never been the subject of a debt sprint because the engineers who proposed sprints had all been hired after it was built and knew how to work with it — they had adapted to its idiosyncrasies and no longer found it frustrating. The new engineer had no context for those idiosyncrasies and had to derive them from first principles, which took four weeks of escalations and false starts.

The engineering manager's retrospective found that the authentication subsystem's debt score in their static analysis tool was in the middle quartile of the codebase — not the highest-debt component, but not the lowest either. It had never appeared in a debt sprint proposal because no currently employed engineer found it frustrating to work with. The four debt sprints conducted over the previous eighteen months had addressed components that the team's current engineers found actively problematic — the data pipeline, the API gateway middleware layer, the test fixture infrastructure — all of which were high-traffic development areas where current engineers spent significant time. The authentication subsystem's debt was invisible to the triage process because the engineers performing the triage were not the engineers who paid the cost of its debt: the cost was paid by engineers who were new to the company, and no one was collecting or aggregating that data in a form that would feed the triage prioritization.

A 38-person B2B SaaS had a well-maintained technical debt backlog managed through their static analysis toolchain. The engineering infrastructure team had configured SonarQube with a custom quality gate and exported the debt items into Jira as a dedicated epic. Items were scored using the SQALE (Software Quality Assessment based on Lifecycle Expectations) method: each debt item carried an estimated remediation time, and the backlog was ordered by SQALE score descending so that the highest-debt items — those requiring the most remediation effort to bring the component into compliance — appeared at the top. The team allocated 20% of each sprint to debt reduction, with engineers picking from the top of the backlog during sprint planning. The VP of Engineering reported the program to the board quarterly, showing the declining total SQALE score across the codebase.

A product manager whose team was experiencing an elevated customer defect rate in the billing module commissioned a review eighteen months into the debt program. The review compared the debt backlog ordering against the incident history for the same period and found an inverse relationship: the three services with the highest number of customer-visible defect incidents — the billing integration service, the webhook delivery service, and the payment reconciliation job — were all in the bottom tertile of the debt backlog by SQALE score. The top tertile, where the debt reduction work had been concentrated, contained the data transformation utilities, the report generation services, and the admin panel backend — components with high SQALE scores because they contained old, complex code that was expensive to bring into full compliance, but components that were rarely touched in normal operations, had low incident rates, and did not sit on customer-critical paths. The debt program had been making excellent progress against the metric it was optimizing — total SQALE score — and zero progress against the business cost the metric was intended to proxy.

The engineering lead's diagnosis: the SQALE scoring model estimated the cost to remediate each debt item to bring it into full compliance with the quality standard, which is the cost the debt creates for the engineering team rather than the cost the debt creates for the business. The highest-SQALE items were expensive to fix, not necessarily expensive to leave in place. The billing integration service had a moderate SQALE score because its debt consisted of a small number of targeted shortcuts — input validation gaps, missing error handling branches, a retry mechanism that did not handle a specific class of transient failures — rather than broad structural complexity. The shortcuts were cheap to fix individually and expensive to leave in place because each one was a potential defect path in a component where defects produced customer-visible billing failures. The data transformation utilities had high SQALE scores because they contained decades of accumulated complexity that would require significant refactoring effort to resolve, but their debt manifested as developer frustration rather than customer incidents. The triage model had optimized for the wrong cost.

A 65-person enterprise SaaS had a formal technical debt triage process: a quarterly debt review meeting involving tech leads and the VP of Engineering, a scoring rubric that incorporated both remediation effort and business impact (weighted 40%/60%), dedicated 20% sprint capacity for debt work across all teams, and a shared Jira board where debt items from across the engineering organization were visible and prioritized in a single queue. The program had been running for two years, and the quarterly reports showed steady progress: the debt backlog count was declining, the rubric scores of addressed items were consistent with the prioritization, and 20% capacity was being maintained across teams.

The VP of Engineering who joined in the third year of the program conducted a business outcome review rather than a program review. He identified four categories of debt by their primary business cost: defect-rate debt (debt items whose failure modes produced customer-visible defects), velocity debt (debt items that slowed feature implementation in high-priority development areas), onboarding debt (debt items that increased the time for new engineers to reach productivity), and security debt (debt items that created vulnerability exposure). He then mapped the previous two years of debt remediation work against those four categories and against the business metrics they affected. The finding: the single-queue triage model had produced proportionally even coverage across all four categories — approximately a quarter of the addressed items fell into each category — with no category's highest-priority items addressed as a cohort. The defect rate had declined modestly over the two years; the feature velocity metrics had remained flat; the onboarding time metric had not been measured. The 20% capacity was being used — the program was not stalling — but the outcomes were below what concentrated remediation in a single category would have produced.

The structural cause: the single-queue model required the rubric to be calibrated so that items from all four categories could be compared in a single ordering, which required the impact scores to be commensurable across categories. The impact weighting was calibrated to the 40%/60% effort-impact ratio, but "impact" was defined broadly enough to accommodate items from all categories — a defect-rate item's impact was its expected incident reduction, a velocity item's impact was its expected cycle time improvement, an onboarding item's impact was its expected new-engineer ramp time reduction. These are incommensurable measures represented as commensurable numbers in the scoring rubric, and the commensurability was achieved by calibrating them all to the judgment of the engineers scoring the items rather than to measured outcomes. The result was a backlog where items from different categories interleaved according to scoring calibration rather than actual business cost, and sprints that addressed a mix of categories in each cycle. The VP's redesign replaced the single queue with four separate category queues, each allocated a specific proportion of the 20% capacity based on a quarterly assessment of which category's high-priority items were creating the highest current business cost — concentrating capacity by category until the highest-priority items in each were addressed before moving to the next tier.

Structural properties set by the technical debt triage decision

Two structural properties are determined by the founding decisions about debt classification, prioritization model, ownership assignment, and capacity allocation. Both are invisible when the system is small enough that the team can coordinate informally on which debt is creating the most friction; both become visible when the accumulated debt is creating categorically different costs in different parts of the organization and the triage model is not designed to distinguish between those costs or to concentrate remediation effort in a way that produces measurable business outcomes.

Property 1: Debt prioritization accuracy. Debt prioritization accuracy is the degree to which the debt backlog ordering reflects the business cost of leaving each item unaddressed — bounded by three factors. First, debt type classification model: whether the triage process distinguishes between debt that increases defect rates, debt that slows feature velocity, debt that increases onboarding cost, and debt that creates security exposure. Each category creates costs through a different mechanism and is felt by different stakeholders on different timescales: defect-rate debt is felt by customers and by on-call engineers who respond to incidents; velocity debt is felt by product teams whose feature delivery timelines are constrained by the affected component; onboarding debt is felt by new engineers and by the senior engineers who spend time unblocking them; security debt is felt by the security team and by customers in the event of an exploitation. A triage model that does not distinguish between these categories will produce a backlog where items from all four categories compete for the same prioritization slots using a scoring rubric that cannot be equally well calibrated to all four simultaneously. The practical consequence — visible in the third story's single-queue program — is that capacity is spread across categories in proportion to their backlog share rather than in proportion to their current business cost, which produces shallow progress across all categories and measurable outcomes in none. Connect this to the technical debt decision record: the tolerance model specifies what types of debt the organization will accept at what rates and under what conditions; the triage model determines how the debt that has been accepted is subsequently prioritized for remediation; the two models must be aligned — if the tolerance model accepts shortcuts in a specific category (velocity shortcuts under feature deadline pressure) at a rate that the triage model does not account for, the triage model's prioritization will drift toward a backlog that is disproportionately composed of the accepted category's items while the model is calibrated to a different distribution. Second, business cost attribution model: whether the prioritization factors account for the specific failure modes each debt item enables rather than the size of the debt or the effort required to remove it. The second story's SQALE-score prioritization model is the canonical example of a cost attribution failure: SQALE measures the effort to resolve the debt, which correlates with code complexity and not with the business cost of leaving the debt in place; a component with high SQALE score and low incident rate has high remediation cost and low business cost, while a component with low SQALE score and high incident rate has the inverse — the backlog ordered by SQALE prioritizes the former over the latter, which produces a remediation program that reduces the metric without reducing the business cost. The business cost proxy should be selected because it correlates with actual cost in your specific system and calibrated against observed outcomes; the calibration evidence should be explicit in the triage model documentation rather than implicit in the scoring rubric. Third, staleness and reranking model: whether the prioritization is updated when the business context changes. A debt item's priority is a function of its current business cost, and that cost changes when the business context changes: a component that was low-traffic when its debt was classified becomes high-priority when the component is placed on a new critical customer path; a debt item that was classified as velocity debt becomes security debt when a new vulnerability disclosure identifies the debt's failure mode as an exploitation path; a component that was well-understood by the team becomes an onboarding-friction source when the engineers who built it leave and are replaced by engineers without their context. The triage model should specify what events trigger a reranking of the backlog — not just a quarterly review cycle, but specific business events that change the cost distribution — and should specify the update process that adds those context changes to existing debt item scores rather than leaving them at their initial classification until the next scheduled review.

Property 2: Remediation velocity ceiling. The remediation velocity ceiling is the rate at which high-priority debt items are addressed before new debt accumulates at the same rate — bounded by three factors. First, capacity and ownership model: whether there is explicit capacity reserved for debt remediation separate from feature delivery, and whether that capacity is assigned to the team that owns each affected component or pooled in a shared backlog that any engineer can pick up. Component-owner assignment produces higher remediation velocity because the engineers addressing the debt have the system context required to understand the failure modes the debt enables, to evaluate whether a proposed refactoring resolves the debt without introducing new failure modes, and to verify the fix against the component's specific behavior contract. A shared backlog with open pickup produces a different failure: engineers addressing debt in unfamiliar components take longer to understand the context, are more likely to produce refactorings that resolve the surface debt while missing the underlying failure mode, and are less likely to notice that the component has behavioral properties that constrain the refactoring approach. The ownership model also determines accountability for debt prevention: a team that owns its own debt backlog has an incentive to minimize new debt introduction because new debt items appear in the queue it is responsible for clearing; a team that contributes items to a shared backlog has a weaker accountability signal. Connect this to the technical debt quantification decision record: the quantification model determines how debt items are identified, measured, and recorded; the triage model determines how they are prioritized and addressed; the two models should share a classification taxonomy so that the quantification model produces items in the categories the triage model knows how to handle — if the quantification model identifies all debt as "technical debt" without category annotation, the triage model must perform category assignment as a separate step, which adds latency and is frequently skipped under scheduling pressure, leaving items in the backlog without the category information required for accurate prioritization. Second, debt gate model: whether there is a threshold for the rate at which new debt is introduced and a process for evaluating whether a proposed shortcut crosses that threshold. Without a gate, the remediation program operates against a backlog that is actively growing during the same sprint cycles the team is using to address it; if the introduction rate exceeds the remediation rate, the net debt accumulation is positive regardless of how well the triage model prioritizes the existing backlog. The debt gate is not a prohibition on shortcuts — shortcuts are often the right choice under specific delivery constraints — but a process for making the introduction of debt an explicit decision with a recorded rationale and a planned remediation path, rather than an implicit consequence of delivery pressure. The gate threshold should be defined by the categories the triage model uses: a team that is currently concentrating remediation capacity on defect-rate debt should have a lower gate threshold for new defect-rate debt than for new velocity debt, because the accumulation cost of adding new items to the category being actively addressed is higher than the cost of adding items to a category whose remediation is deferred. Third, category exhaustion model: whether the capacity allocation distributes work across all debt categories simultaneously or concentrates capacity on one category until the highest-priority items in that category are addressed. The third story's single-queue program produced even coverage across all categories at the cost of measurable outcomes in none; the VP's redesign concentrated capacity by category, which produces a different tradeoff — focused progress in one category while other categories' high-priority items remain unaddressed — but produces the measurable business outcome that validates the triage model and provides the empirical signal required to calibrate the rubric for the next category. The concentration model requires a quarterly assessment of which category's high-priority items are currently creating the highest business cost, which is a different question from which items in the unified backlog are scored highest under the rubric; it requires a category-level view of the business cost distribution rather than an item-level view, and it requires the organizational willingness to defer progress on lower-cost categories in order to concentrate on the highest-cost category — a different kind of decision than choosing the next item from a shared priority queue. Connect this to the engineering technical strategy decision record: the technical strategy specifies the architectural commitments and investment priorities that constrain which categories of debt are acceptable to leave unaddressed and for how long; the triage model is the operational mechanism that implements the strategy's debt tolerance policy at the item level — if the technical strategy commits to zero defect-rate debt in customer-critical payment components, the triage model's category allocation must ensure that defect-rate debt in those components is addressed before velocity or onboarding debt in other components, regardless of where those items rank in a unified scoring model.

The engineering technical debt triage ADR: five sections

Section 1: Debt classification model. The classification model specifies the categories of technical debt the organization recognizes, the criteria for assigning each item to a category, and the primary business cost each category creates. The classification should be defined in terms of how the debt item's failure mode manifests as a business cost rather than in terms of code quality characteristics. Four categories that cover the primary business cost mechanisms for most engineering organizations: defect-rate debt, whose failure mode increases the probability or severity of customer-visible defects — authentication shortcuts that allow invalid tokens to pass validation, error handling gaps that allow unhandled exceptions to surface as 500 responses, retry logic failures that allow transient network errors to produce permanent failures in customer-facing operations; velocity debt, whose failure mode increases the time required to implement new features in a specific component — insufficient test coverage that makes engineers afraid to modify a component, tangled dependencies that require multiple teams to coordinate on changes to a single service, inconsistent internal abstractions that require engineers to learn a new pattern for each area of the codebase; onboarding debt, whose failure mode increases the time for new engineers to reach productivity in a component — implicit conventions that are not documented and must be derived from code reading, inconsistent naming that makes the intended behavior of functions non-inferrable from their signatures, architectural decisions that make sense only with context that exists only in the memories of engineers who built the component; security debt, whose failure mode creates vulnerability exposure — dependency versions with known CVEs, authentication patterns that are deprecated in the current threat model, input validation gaps that create injection surfaces. The classification criteria should be explicit enough that two engineers independently classifying the same item would reach the same category assignment. Items that span multiple categories should be classified by their primary failure mode — the failure mode whose business cost is highest — with the secondary category noted in the item description. The classification model should be reviewed when business outcomes fail to improve despite triage program progress: if defect rates are not declining despite debt reduction in the defect-rate category, the classification criteria are either misidentifying items as defect-rate debt when their primary failure mode is actually velocity debt, or the business cost proxy for defect-rate items is not correlating with the actual defect-producing failure modes.

Section 2: Prioritization model and business cost proxy. The prioritization model specifies the criteria for ordering items within each debt category, the business cost proxy used for each category, and the mechanism for updating scores when the business context changes. The prioritization criteria should differ by category because each category's business cost is measured differently. For defect-rate debt: priority by incident history (components with debt items that have contributed to incidents rank higher than components with equivalent debt that have not), severity of the failure mode (defect paths that produce data loss rank higher than defect paths that produce degraded performance), and traffic volume of the affected code path (a validation gap in a high-frequency API endpoint ranks higher than the same gap in a low-frequency administrative endpoint). For velocity debt: priority by development frequency of the affected component (debt in components that are modified in every sprint ranks higher than debt in stable components that are rarely changed), magnitude of the velocity impact (debt items that add more than one day of cycle time per sprint rank higher than debt items with marginal impact), and product roadmap priority of the features blocked by the debt (debt that is blocking a high-priority roadmap item ranks higher than debt in a component whose features are not currently planned). For onboarding debt: priority by turnover rate in the affected team (debt in components whose owning engineers left recently ranks higher), complexity of the component relative to its documentation coverage (components with high complexity and low documentation coverage produce the highest onboarding cost), and new-engineer escalation rate (components where new engineers generate support requests at a higher rate than the baseline are the components where onboarding debt is currently materializing). For security debt: priority by CVE severity and exploitability (Critical CVEs with available exploits rank highest), regulatory exposure of the affected component (debt in components that handle regulated data categories ranks higher), and the current threat model's assessment of the attack surface (debt items that sit on the external attack surface rank higher than equivalent items on internal surfaces). The business cost proxy should be calibrated against actual outcomes: if the incident history proxy for defect-rate debt is working, the components with the highest-ranked defect-rate items should be the components whose incident rate declines most rapidly as their items are addressed. If the correlation is weak, the proxy is misidentifying the high-cost items and should be recalibrated using a different input.

Section 3: Ownership and capacity model. The ownership model specifies which team is responsible for each debt item in the backlog, and the capacity model specifies how sprint capacity is allocated to debt remediation. The ownership model should assign each item to the team that owns the affected component — the team that is best positioned to understand the failure mode, implement the fix with knowledge of the component's behavior contract, and verify the fix against the component's test suite and operational characteristics. A shared pickup model — where any engineer can address any debt item — is appropriate for debt items that are small, self-contained, and require no component-specific context; it is not appropriate for structural debt items that require understanding of why the component was built the way it was and what constraints the fix must satisfy to be correct. The ownership model should include an exception process for debt items in components that are no longer actively maintained: when a component's owning team has been disbanded or its engineers have left, the debt items should be triaged for either transfer to the team that currently has the most context on the component, retirement if the component is being decommissioned, or explicit acceptance with a documented rationale if the debt item's business cost is too low to justify the context-building cost of addressing it. The capacity model should specify the allocation per team rather than per engineering organization: different teams have different debt distributions and different feature delivery pressures, and a uniform 20% allocation across all teams will produce suboptimal capacity use if some teams have high-priority debt backlogs that would benefit from higher allocation and other teams have low-priority backlogs where 20% is more than the debt load warrants. The capacity allocation should also specify the category concentration model: whether each sprint's debt capacity is distributed across all categories proportionally to their backlog share, or concentrated on the highest-priority category until the top tier is addressed. Connect this to the engineering code review culture decision record: code review is the first gate for preventing new debt from entering the codebase; the debt gate model and the code review culture are complementary mechanisms — the code review process identifies new debt being introduced, and the debt gate model determines whether a proposed shortcut is within the acceptable tolerance or requires an explicit debt record and remediation plan before it can be merged. A code review culture that approves shortcuts without recording them as debt undermines the triage model by creating a shadow backlog of items that are not in the triage system and not being tracked against the category thresholds.

Section 4: Debt gate model and accumulation rate management. The debt gate model specifies the threshold for what debt is acceptable to introduce during feature delivery and the process for making that introduction an explicit decision rather than an implicit shortcut. The gate is not a quality standard that must be met before code is merged — that is the code review's function — but a classification and documentation requirement for intentional shortcuts that fall below the code review's quality standard. A shortcut that a code reviewer approves as "good enough given the timeline" without recording it as a debt item creates invisible accumulation; the same shortcut with a recorded debt item is triage-visible and can be prioritized against other items in the same category. The gate model should specify three things: the classification trigger (what characteristics of a change make it a candidate for a debt record rather than just a code review comment), the debt record format (what information must be captured at introduction time to enable future triage — which component, which category, what the failure mode is, what the remediation approach would be, what triggered the shortcut), and the approval threshold (whether introducing a debt item above a specified priority threshold requires explicit sign-off from the team lead or VP of Engineering, to prevent the debt gate from being treated as a rubber-stamp formality). The accumulation rate should be measured per category and compared against the remediation rate per category quarterly: if defect-rate debt is accumulating at a higher rate than it is being addressed, the remediation capacity for that category is insufficient relative to the introduction rate, and the gate threshold for defect-rate debt items should be raised — requiring more explicit justification for introducing shortcuts in defect-rate-sensitive code — or the remediation capacity should be increased. The accumulation rate measurement requires the debt gate to be functioning: if shortcuts are not recorded as debt items when they are introduced, the measured accumulation rate will be lower than the actual accumulation rate, the comparison with the remediation rate will appear favorable, and the net debt growth will only become visible when it manifests as incidents or velocity drag rather than in the triage model's metrics.

Section 5: Triage health model and calibration mechanism. The triage health model specifies how the triage program is measured and how it is calibrated over time. A triage program that is not measured against business outcomes will optimize for triage metrics — backlog count, SQALE score, coverage rate — rather than for the business cost reductions those metrics are intended to proxy. Three measurement dimensions for a healthy triage program. Business outcome correlation: for each debt category, is the business metric that category affects improving as the highest-priority items in that category are addressed? Defect-rate debt addressed should produce declining incident rates in the affected components; velocity debt addressed should produce declining cycle times for features in the affected components; onboarding debt addressed should produce declining new-engineer escalation rates and ramp time in the affected components. If the correlation is absent — the highest-priority items are being addressed and the corresponding business metric is not improving — the prioritization model is misidentifying the high-cost items, and the calibration mechanism should produce a scoring adjustment. Accumulation-to-remediation ratio per category: is each category's net debt accumulation declining over time? A triage program that is making progress against the backlog while the introduction rate keeps pace produces a stable backlog size rather than a declining one; the stability is not a sign that the program is working but that it is treading water. The ratio should be measured quarterly per category and used to set the capacity allocation for the following quarter: categories where the ratio is greater than 1.0 (accumulation exceeding remediation) receive increased capacity; categories where the ratio is below 0.5 receive reduced capacity so that the released capacity can address higher-ratio categories. Prioritization staleness rate: what proportion of items in the backlog have not been reviewed for score updates in more than one quarter, and how many items have been reprioritzed based on business context changes? A backlog that has not been updated for stale items is being managed as a fixed list rather than as a living prioritization — the business context changes that should update priorities are not being captured. The staleness rate provides a signal for the reranking model's effectiveness: if the rate is high, the events that should trigger reranking are not being tracked or are not flowing through to the backlog update process, and the classification of debt items is drifting away from current business reality. The calibration review should be scheduled quarterly and should produce specific rubric adjustments — category weight changes, proxy recalibrations — based on the three measurements, rather than producing qualitative assessments of the program's health without changes to the prioritization criteria.

FAQ

Further reading

• Technical debt decision record — the tolerance model specifies what types of debt the organization will accept at what rates and under what conditions; the triage model is downstream of the tolerance model — it determines how the debt that has been accepted is subsequently prioritized for remediation; the two models must be aligned so that the categories the tolerance model accepts at higher rates are the categories the triage model has the highest remediation capacity for, and so that the debt gate threshold in the triage model reflects the tolerance boundaries the tolerance model establishes rather than being calibrated independently.
• Technical debt quantification decision record — the quantification model determines how debt items are identified, measured, and recorded in the backlog; the triage model determines how they are prioritized and addressed; the two models should share a classification taxonomy so that the quantification model produces items in the categories the triage model knows how to handle — if the quantification model identifies all debt as undifferentiated "technical debt" without category annotation, the triage model must perform category assignment as a separate step, adding latency that is frequently skipped under scheduling pressure and leaving items without the category information required for accurate prioritization.
• Engineering technical strategy decision record — the technical strategy specifies the architectural commitments and investment priorities that constrain which categories of debt are acceptable to leave unaddressed and for how long; the triage model is the operational mechanism that implements the strategy's debt tolerance policy at the item level — if the technical strategy commits to zero defect-rate debt in customer-critical components, the triage model's category allocation must ensure that defect-rate debt in those components is addressed before velocity or onboarding debt in other components, regardless of where those items rank in a unified scoring model calibrated for the full codebase.
• Engineering code review culture decision record — code review is the first gate for preventing new debt from entering the codebase; the debt gate model and the code review culture are complementary mechanisms — the code review process identifies new debt being introduced and the debt gate model determines whether a proposed shortcut requires an explicit debt record before it can be merged; a code review culture that approves shortcuts without recording them as debt items undermines the triage model by creating a shadow backlog of items that are not triage-visible and not being tracked against the category accumulation rate thresholds that the triage health model monitors.
• Open-source extractor — the reasoning behind technical debt triage design decisions — why the categorization uses four categories calibrated to business cost mechanism rather than code quality dimensions, what proxy was chosen for each category and why the SQALE-score proxy was rejected, how the capacity allocation was set to concentrate by category rather than distribute uniformly, what the accumulation rate measurement revealed about the introduction rate that required adjusting the debt gate threshold — is reasoning conducted in AI chat sessions when engineering leads work through the gap between what the debt program was supposed to produce and what it is producing; running those sessions through the extractor produces the triage decision record that allows the next engineering lead to inherit the analysis that shaped the current model, not just the rubric and backlog that resulted from it.