Technical Debt Register¶
Record artifact — instantiates Technical Debt Containment
A maintained inventory of known debt items — each with a source, an owner, and an intended repayment path — that turns scattered, tacit shortcuts into one visible, queryable list.
Before debt can be capped, prioritized, or repaid, it has to exist somewhere you can see it. Technical Debt Register is the inventory artifact that makes the debt stock legible: one maintained list where every known shortcut, workaround, deferred cleanup, or brittle dependency gets a row, and each row carries the few fields that let it be governed — source, affected surface, an accountable owner, expected drag, and an intended repayment path. Its defining move is aggregation with attribution: it does not judge how bad an item is, decide what gets fixed, or measure live drag — it simply guarantees that the debt is written down in one place and that no item is ownerless. Everything else in the archetype (the rubric that scores, the review that funds, the dashboard that trends) reads from this list; without it they have nothing to operate on.
Example¶
A team maintaining a consumer mobile app keeps rediscovering the same "we'll fix it later" comments, but nobody can say how much of that there is or who is on the hook for any of it. They stand up a register — a single shared table with fixed columns: source, affected surface, owner, expected drag, repayment path, status. Each known shortcut becomes a row: the hand-rolled auth-token cache (owner: the platform lead), the untyped analytics payload that breaks silently, the forked third-party SDK three versions behind. When the auth cache later causes a login outage, the row is already there — it names the owner and the intended fix, so the incident does not start from zero. The register did not decide the cache was the biggest risk (that is the severity rubric's job) or reserve time to fix it (the reserve's job). It did the one thing that had to happen first: it turned a fog of tacit debt into a list someone owns.
How it works¶
The register is an act of enumeration and attribution, not of judgment. Each item is captured as a structured record with a small, fixed schema, and the non-negotiable field is the owner — an item with no accountable steward is not really registered, because there is no one to review, escalate, or close it. Open items collectively describe the current debt stock; closed items preserve a trail of what was repaid or accepted. What distinguishes it from an ordinary task backlog is that every row records a future obligation created by past expedience, not a unit of new work — the register is the memory of shortcuts, deliberately separated from the feature queue so the two are not silently traded against each other.
Tuning parameters¶
- Field schema — a minimal three-field row versus a rich record with links, estimates, and history. More fields capture more but raise the friction that leaves debt unlogged.
- Entry threshold — how large a shortcut must be to earn a row. A low bar catches everything and drowns; a high bar keeps the list actionable but misses accreting small debts.
- Ownership granularity — an owner per item versus an owner per debt class or surface. Per-item ownership is precise; per-class ownership scales better on a large stock.
- Freshness discipline — how aggressively stale or resolved rows are pruned. Left ungroomed, the register rots into a graveyard that people stop trusting.
- Visibility — who can see and edit it. A single shared source has authority; parallel private lists quietly defeat the whole point.
When it helps, and when it misleads¶
Its strength is that it converts an unmanaged fog into a governed stock: debt becomes countable, attributable, and referenceable, which is the precondition for every other move in the archetype. It is also what gives an incident or a planning conversation a shared factual base instead of competing anecdotes.
Its characteristic failure is debt theater — a register that grows steadily while nothing is ever repaid, so it becomes elaborate documentation of decline rather than a lever on it. A register with no cap and no reserved repayment capacity behind it is passive by construction. The metaphor it rests on is Ward Cunningham's original technical debt[1]: a shortcut is a loan, and a loan you merely list but never service still accrues interest. The classic misuse is weaponizing the list — using rows to assign blame for constraints people inherited, which teaches everyone to stop logging debt at all. The discipline that keeps it honest is to pair the register with real repayment capacity and a closure rule, and to groom it so it stays a live inventory, not an archive.
How it implements the components¶
debt_register— the register is this component: the maintained, queryable inventory of known debt items and their attributes.accountable_debt_owner— every row names an accountable steward, which is what connects a recorded item to eventual review, escalation, and closure.
The register lists items but does not score them — severity_classification is the Debt Severity Rubric, its nearest twin — nor does it measure live drag or maintain the ordered repayment queue: interest_or_drag_signal and debt_service_ratio belong to the Debt-Service Dashboard, and repayment_backlog to the Repayment Reserve.
Related¶
- Instantiates: Technical Debt Containment — the register is the visibility substrate the rest of the archetype reads from.
- Consumes: Quality or Health Scan feeds candidate items into the register for human triage.
- Sibling mechanisms: Debt Severity Rubric · Debt Budget Review · Debt-Service Dashboard · Architecture or Process Decision Record · Quality or Health Scan · Repayment Reserve · Sunset or Replacement Plan · Exception Expiry Date · Refactoring or Cleanup Sprint
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Technical Debt Register operates as a persistent ledger, log, register, or case record that preserves history and traceability because it a maintained inventory of known debt items — each with a source, an owner, and an intended repayment path — that turns scattered, tacit shortcuts into one visible, queryable list.
Independent corroboration: The frozen evidence defines Technical Debt Register as 'A maintained inventory of known debt items — each with a source, an owner, and an intended repayment path — that turns scattered, tacit shortcuts into one visible, queryable list', so its operative form is Record, Log & Register.
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: The defining operation is: A maintained inventory of known debt items — each with a source, an owner, and an intended repayment path — that turns scattered, tacit shortcuts into one visible, queryable list. In the computer_science lineage, that operation is specifically evidenced by authoritative or primary work that defines technical-debt items, causes, consequences, affected artifacts, and the need for explicit identification and management. This makes computer_science the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins.
Related originating lineages:
- Accounting & Auditing — accounting_auditing supplies a historically relevant parallel or contributing practice for the defining operation—A maintained inventory of known debt items — each with a source, an owner, and an intended repayment path — that turns scattered, tacit shortcuts into one visible, queryable list—but the evidence does not make it the best primary lineage.
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: a maintained inventory of known debt items — each with a source, an owner, and an intended repayment path — that turns scattered, tacit shortcuts into one visible, queryable list.
- Library & Information Science — Library and information-science stewardship supplies a parallel or contributing lineage for the mechanism's defining operation: a maintained inventory of known debt items — each with a source, an owner, and an intended repayment path — that turns scattered, tacit shortcuts into one visible, queryable list.
- Organizational & Management Science — Organizational management's coordination, workflow, and capability tradition provides a formative adjacent lineage for the same technical debt register operation.
Review resolution: The blind reviewers disagree on primary lineage (accounting_auditing versus computer_science), so I adjudicated the mechanism rather than inheriting either label. The defining operation is: A maintained inventory of known debt items — each with a source, an owner, and an intended repayment path — that turns scattered, tacit shortcuts into one visible, queryable list. In the computer_science lineage, that operation is specifically evidenced by authoritative or primary work that defines technical-debt items, causes, consequences, affected artifacts, and the need for explicit identification and management. This makes computer_science the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins. The cited CMU SEI, The Future of Managing Technical Debt directly supports the mechanism-specific operation and its disciplinary lineage. I retain all independently explained historical alternates without a numeric cap. origin_mode=cross_disciplinary_synthesis records how the mechanism arose; domain_reach=multi_domain separately records how broadly it can now be applied.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
The register's authority comes entirely from being the single source of truth. The moment teams keep their own private shadow lists — a spreadsheet here, tickets there — the archetype fractures, because caps and reviews are then operating on a partial stock. Consolidating to one register is often the highest-leverage first step, ahead of any scoring or dashboarding.
References¶
[1] Cunningham, W. "The WyCash Portfolio Management System". Addendum to the Proceedings on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA 1992), 29–30 (1992). Introduces technical debt as the loan-like cost of shipping expedient, not-quite-right code. registry ↩