AI-007·AI Track·Intermediate–Advanced·3–15 hrs saved

Stop Managing Technical Debt by Anecdote — Build an Evidence-Based Register You Can Actually Fund

An AI-assisted workflow to identify, quantify, and prioritize technical debt across code, architecture, security, operations, and cost — separating real liabilities from developer preference.

3Phases

14Prompts

3–15Hours saved

5Deliverables

Executive Brief

Your Challenge

Your team knows where the debt is — everyone can name the service nobody wants to touch. What you don't have is a defensible way to prove it, rank it against everything else competing for engineering time, and turn it into a roadmap leadership will fund. Technical debt gets managed through anecdote: "deployments always break," "we should rewrite this," "only one engineer understands billing." Those observations may point to genuine liabilities, but they aren't enough to prioritize, and they don't survive contact with a planning meeting.

Common Obstacles

Without a structured process, the failure modes are predictable and expensive. Teams rewrite stable, supported systems because the technology feels old, while material security debt sits unaddressed. Visible code cleanup gets prioritized over operational risk. Complexity metrics and line counts stand in for business impact. Estimates get converted into false financial precision that collapses under scrutiny. And the backlog fills with unowned items until the register becomes documentation instead of a management process — a list of things engineers dislike, not a portfolio of measurable liabilities.

The ABME Approach

This workflow does it in the right order: normalize a definition of technical debt, inventory the evidence, then classify every item across thirteen debt categories and separate it from defects, features, and preferences. AI assembles and classifies the evidence — code hotspots, incident history, delivery friction, security findings, dependency inventories — while confidence levels and a prioritization model keep the decisions grounded in business context. You end with a categorized register: each item carries evidence, risk, current and future cost, dependencies, an owner, and a review date, sequenced into a roadmap that reflects enabling work, not just priority scores.

Insight Summary

Technical debt is not a list of things engineers dislike. It is a portfolio of technical liabilities that create measurable cost, risk, or constraint — and should be managed with the same discipline as other business investments.

phase-1

Define technical debt before you measure it. Without criteria, every old system, code smell, and TODO comment becomes "debt," and the register becomes a backlog too large to act upon.

phase-1

"The code is old" is not a debt item. A debt item names a specific condition, the evidence it creates cost, the capability it affects, a remediation path, and why remediation hasn't happened yet.

phase-2

AI can assemble and classify evidence, but it will label ordinary complexity, old technology, and developer preference as debt if you let it. Every material finding needs a stated confidence level and human validation.

phase-2

Debt with high recurring interest — the cost paid every deployment, every incident, every week — may deserve priority even when the immediate risk is moderate.

phase-3

Priority and sequencing are not the same thing. The highest-scored item may not be actionable until enabling work completes; the roadmap must reflect dependencies, not only scores.

tactical

Shared ownership often means no ownership. When a system lacks an owner, ownership debt may itself be a high-priority finding.

The Journey

Three phases; each lists the tools you'll use there.

Define Debt and Inventory Evidence

Normalize what counts as technical debt, then gather the evidence needed to prove it before prompting.

Gather business priorities, application inventory, and the full evidence set
Establish the technical debt definition and classification criteria
Distinguish debt from defects, features, maintenance, modernization, and preference
Identify the values and sensitive findings that must not be exposed to AI
Note the questions a complete assessment must answer

Prerequisites Checklist

Identify and Classify with AI

Use the prompt pack to inventory, categorize, assess, and score debt across all thirteen categories.

Run the primary prompt with the assembled evidence
Apply targeted follow-up prompts by evidence source (codebase, incidents, delivery, dependencies, security, tests, docs)
Assign confidence, severity, and remediation categories to each item
Assess impact and cost dimensions and compute a prioritization score
Capture each item on the intake template

Technical Debt Prompt Pack Technical Debt Register Technical Debt Intake Template

Prioritize, Sequence, and Govern

Turn scored items into a dependency-aware roadmap with owners, metrics, and a review cadence.

Separate quick wins from strategic initiatives and document accepted and deferred debt
Map dependencies and sequence enabling work ahead of high-priority items
Assign owners, success metrics, and review dates
Run the validation checklist before accepting the assessment
Set the governance model and review cadence

Validation Checklist

What's Inside the Execution Layer

Numbered deliverables grouped by phase. Membership unlocks every tool.

2. PHASE 2Prompt Packprotected

Technical Debt Prompt Pack

One primary prompt and thirteen targeted follow-ups that identify, classify, assess, and prioritize technical debt across every evidence source.

Use this to

Produce a categorized, evidence-based debt register
Analyze specific sources — codebase, incidents, delivery, dependencies, security, tests, docs
Compare refactor/rewrite/replace options and build executive business cases and roadmaps

Included with membership — $20/mo

Primary Prompt

Start here with the full assembled evidence set.

You are a senior software architect, engineering leader, and technical debt analyst.

I will provide some or all of the following:
• Business priorities
• Application inventory
• Architecture diagrams
• Source code
• Dependency inventory
• Runtime versions
• Defect history
• Incident reports
• Security findings
• Audit findings
• Test results
• Coverage reports
• CI/CD metrics
• Deployment history
• Operational runbooks
• Monitoring data
• Cloud costs
• Support data
• Team feedback
• Product roadmap
• Ownership information
• End-of-life dates
• Existing technical debt items

Your task is to identify, normalize, assess, and prioritize technical debt.

Do not treat every old technology, code smell, defect, TODO comment, or stylistic preference as technical debt.

First:

1. Summarize the business and technical context.

2. Define the technical debt criteria being used.

3. Separate:
• Confirmed facts
• Reported observations
• Inferences
• Assumptions
• Unknowns

4. Inventory the available evidence.

5. Identify missing information that materially affects prioritization.

6. Distinguish:
• Technical debt
• Defects
• Features
• Routine maintenance
• Security vulnerabilities
• Modernization opportunities
• Preferences

7. Identify debt across:
• Code
• Architecture
• Tests
• Security
• Dependencies
• Infrastructure
• Operations
• Observability
• Data
• Documentation
• Process
• Cost
• Knowledge

For each debt item, provide:
• Debt ID
• Concise title
• Category
• Affected system or component
• Technical condition
• Evidence
• Confidence
• Origin or likely cause
• Business impact
• Customer impact
• Security and compliance impact
• Operational impact
• Delivery impact
• Current recurring cost
• Future cost if deferred
• Likelihood of worsening
• Change frequency of affected area
• Dependencies
• Owner or recommended owner
• Remediation options
• Smallest useful intervention
• Full remediation
• Estimated effort
• Implementation risk
• Priority
• Recommended timeframe
• Success criteria
• Metrics
• Consequence of doing nothing
• Review date

Requirements:
• Cite the evidence supporting each finding.
• Do not invent financial values.
• Use ranges where estimates are uncertain.
• Do not recommend a rewrite without comparing alternatives.
• Do not prioritize code cleanliness over security, customer, regulatory, or operational risk.
• Account for remediation dependencies.
• Identify debt that should be accepted rather than remediated.
• Identify items that can be combined into one initiative.
• Identify quick wins.
• Identify high-impact long-term initiatives.
• Identify disputed or low-confidence items.
• Avoid duplicate debt entries.
• Keep defects separate unless they demonstrate a structural recurring liability.
• State when additional measurement is required.

Then produce:
1. Executive summary.
2. Technical debt definition.
3. Evidence assessment.
4. Categorized debt register.
5. Prioritized top ten.
6. Quick wins.
7. Strategic initiatives.
8. Accepted and deferred debt.
9. Dependency map.
10. Recommended roadmap.
11. Ownership model.
12. Success metrics.
13. Governance cadence.
14. Remaining unknowns.

Analyze a Codebase for Technical Debt

When source code is available for direct analysis.

Analyze the provided codebase for technical debt.
Focus on:
• Complexity hotspots
• Duplication
• Hidden dependencies
• Shared state
• Error handling
• Testability
• Dependency age
• Unsupported APIs
• Security-sensitive patterns
• Change frequency
• Ownership concentration
Separate confirmed evidence from heuristic indicators.

Analyze Technical Debt from Incidents

When incident history is the primary evidence source.

Analyze the incident history for recurring technical debt.
Identify:
• Repeated failure mechanisms
• Shared contributing factors
• Missing controls
• Manual recovery
• Weak observability
• Deployment fragility
• Unsupported dependencies
• Knowledge bottlenecks
Do not treat each incident as a separate debt item when a common structural cause exists.

Analyze Delivery Friction

When investigating slow or unreliable delivery.

Identify technical debt that slows software delivery.
Review:
• Build duration
• Test duration
• Flaky tests
• Environment setup
• Deployment approvals
• Manual steps
• Merge conflicts
• Rework
• Rollbacks
• Long-lived branches
• Integration delays
• Review bottlenecks
Connect each finding to measurable delivery impact.

Analyze Operational Toil

When reviewing recurring manual operational work.

Identify recurring operational work that should be considered technical debt.
For each task document:
• Frequency
• Duration
• Required skill
• Error risk
• Customer impact
• Automation potential
• Current owner
• Escalation risk
• Annual effort range
Do not invent effort values when data is unavailable.

Analyze Dependency Debt

When reviewing the dependency and runtime inventory.

Review the dependency and runtime inventory.
Identify:
• Unsupported versions
• Upcoming end-of-life dates
• Known vulnerabilities
• Abandoned libraries
• Deprecated APIs
• Custom forks
• Version conflicts
• Upgrade blockers
• Licensing concerns
• Vendor lock-in
Prioritize by exposure, usage, and upgrade complexity.

Analyze Security Debt

When focusing on security-related liabilities.

Identify security-related technical debt.
Assess:
• Unsupported software
• Privilege accumulation
• Authentication weaknesses
• Authorization inconsistencies
• Secret management
• Audit gaps
• Tenant isolation
• Encryption
• Unresolved findings
• Security testing gaps
Do not replace the formal vulnerability-management process. Cross-reference it.

Analyze Test Debt

When reviewing the test suite and quality process.

Analyze the test suite and quality process for technical debt.
Identify:
• Critical behavior without tests
• Flaky tests
• Excessive execution time
• Weak assertions
• Over-mocking
• Missing integration tests
• Missing regression tests
• Missing security tests
• Manual release validation
• Unsupported test frameworks
Estimate the delivery and defect impact where evidence exists.

Analyze Documentation and Knowledge Debt

When assessing documentation and knowledge concentration.

Identify documentation and knowledge debt.
Review:
• System ownership
• Architecture documentation
• Runbooks
• Onboarding
• Deployment instructions
• Data definitions
• Decision records
• Single-person dependencies
• Unsupported tribal knowledge
Prioritize knowledge that would materially affect recovery, delivery, security, or continuity.

Compare Refactor, Rewrite, and Replace

When deciding how to remediate a specific debt item.

Compare the following options for the identified debt:
• Continue maintaining
• Incrementally refactor
• Upgrade
• Isolate
• Replace
• Rewrite
• Retire
For each option include:
• Benefits
• Cost
• Delivery risk
• Migration risk
• Business disruption
• Compatibility impact
• Operational impact
• Time to value
• Reversibility
• Long-term constraints
Do not recommend a rewrite solely because the current system is old or complex.

Create a Technical Debt Register

To convert findings into a structured register.

Convert the findings into a technical debt register.
Use one row per distinct debt item.
Include:
• ID
• Title
• Category
• System
• Evidence
• Business impact
• Technical impact
• Security impact
• Current cost
• Future cost
• Effort
• Priority
• Owner
• Dependencies
• Recommended action
• Target period
• Review date
• Status

Create an Executive Business Case

When pitching the highest-priority initiative to leadership.

Create an executive business case for the highest-priority technical debt initiative.
Explain:
• Current business impact
• Evidence
• Risk of inaction
• Proposed intervention
• Alternatives
• Estimated effort range
• Expected benefit
• Success metrics
• Delivery approach
• Decision required
Avoid unnecessary engineering terminology.

Create a Quarterly Debt Roadmap

When sequencing remediation across quarters.

Create a four-quarter technical debt roadmap.
Balance:
• Critical remediation
• Quick wins
• Strategic initiatives
• Product delivery
• Security deadlines
• Dependency upgrades
• Operational improvements
• Team capacity
Identify dependencies and measurable outcomes for each quarter.

3. PHASE 2Templateprotected

Technical Debt Intake Template

A labeled structure for capturing each candidate debt item with the evidence, impact, and ownership needed to qualify it.

Use this to

Capture each debt item consistently
Force evidence and consequence-of-deferral for every entry
Assign an owner before an item enters the register

Included with membership — $20/mo

Debt Title

A concise description of the liability.

[...]

Affected System

Application, service, platform, data store, process, or dependency.

[...]

Technical Condition

What specifically exists today?

[...]

Evidence

What proves or suggests that the condition creates debt?

[...]

Business Impact

How does it affect revenue, customers, operations, compliance, or strategy?

[...]

Engineering Impact

How does it affect delivery, testing, reliability, maintainability, or staffing?

[...]

Current Workaround

How is the problem managed today?

[...]

Frequency

How often does the issue create cost or risk?

[...]

Proposed Remediation

What intervention is being considered?

[...]

Consequence of Deferral

What is likely to happen if no action is taken?

[...]

Owner

Who is responsible for the affected capability?

[...]

4. PHASE 2Matrixprotected

Technical Debt Register

A one-row-per-item register that turns qualified debt findings into a comparable, prioritized, ownable list.

Use this to

Consolidate all debt items into one comparable view
Track priority, effort, owner, and review date per item
Feed the roadmap and governance review cadence

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

ID	Title	Category	System	Evidence	Business Impact	Technical Impact	Security Impact	Current Cost	Future Cost	Effort	Priority	Dependencies	Recommended Action	Target Period
TD-001	Unsupported application runtime	Dependency/Security	Customer Billing Platform	Vendor EOL; cannot consume current security packages	High security and support risk	Cannot adopt supported package versions	High	Patch review, compatibility workarounds	Rising upgrade complexity	High	Critical	Database upgrade, driver replacement, regression tests	Upgrade	Begin planning immediately
TD-002	Manual deployment process	Operational/Process	Customer Billing Platform	Four manual deployment steps; three configuration-drift incidents	Configuration drift and release risk	Release risk and toil				Medium	High		Automate
TD-003	Missing reconciliation documentation	Knowledge	Customer Billing Platform	Only one engineer understands reconciliation	Single-person dependency	Recovery and onboarding risk				Low	High		Document
TD-004	Limited billing regression tests	Test	Customer Billing Platform	Automated tests cover only pricing calculations	High change and financial risk	Weak change safety				Medium	High		Refactor
TD-005	Database upgrade blocks runtime upgrade	Infrastructure/Dependency	Customer Billing Platform	Database upgrade required before runtime upgrade	Blocks critical remediation	Enabling dependency for TD-001				High	Critical		Upgrade

🔒 The full execution layer — every checklist, matrix, and the prompt pack — is included with ABME membership.

Unlock Full Blueprint

Full Playbook

Overviewpublic

Technical debt is the accumulated cost of design, implementation, operational, security, testing, documentation, and architectural decisions that make future work more difficult or risky.

Some technical debt is intentional. A team may knowingly accept a temporary shortcut to:

Meet a regulatory deadline
Validate a market opportunity
Restore service
Complete a migration
Support a customer commitment
Reduce immediate delivery risk

Other debt accumulates unintentionally through:

Repeated local fixes
Incomplete requirements
Framework changes
Staff turnover
Missing tests
Duplicated business logic
Outdated dependencies
Architectural drift
Inconsistent standards
Poor documentation
Weak observability
Unresolved security findings
Manual operational processes

The problem is not that all technical debt exists. The problem is that organizations often lack a reliable method to identify, quantify, compare, prioritize, own, and retire it.

This workflow uses AI to analyze code, architecture, defects, operational incidents, security findings, delivery metrics, dependency inventories, test coverage, documentation gaps, and team feedback to create an evidence-based technical debt register.

The workflow distinguishes technical debt from:

Ordinary defects
Feature requests
Modernization preferences
Cosmetic cleanup
Unsupported assumptions
General dissatisfaction with old code

The goal is to answer: “Which technical liabilities create the greatest business and engineering risk, and what should we address first?”

Business Problempublic

Technical debt is frequently managed through anecdote. Examples include:

“That module is a mess.”
“Nobody wants to touch the billing service.”
“We should rewrite this in a newer framework.”
“Deployments always break.”
“The test suite is unreliable.”
“We have too many dependencies.”
“The database cannot scale.”
“Only one engineer understands the system.”

These observations may point to genuine debt, but they are not sufficient for prioritization.

Without a structured process, organizations may:

Rewrite stable systems unnecessarily
Ignore high-risk security debt
Prioritize visible code cleanup over operational risk
Accumulate undocumented dependencies
Delay important upgrades
Spend engineering time on low-value modernization
Allow recurring incidents to continue
Lose critical institutional knowledge
Accept increasing cloud costs
Create roadmaps that cannot be funded
Treat all debt as equally urgent
Confuse developer preference with business value

Poor technical debt management increases:

Change failure rate
Lead time
Incident frequency
Security exposure
Cloud and infrastructure cost
Support effort
Testing effort
Release risk
Developer frustration
Onboarding time
Vendor dependence
Regulatory risk
Opportunity cost

AI can help assemble and classify evidence, but debt decisions must remain grounded in business context and engineering judgment.

Typical Use Casespublic

Use this workflow when:

Creating a technical debt register
Preparing quarterly engineering planning
Prioritizing modernization work
Reviewing a legacy application
Preparing a platform roadmap
Evaluating recurring incidents
Reviewing security findings
Planning dependency upgrades
Preparing an acquisition or technical due diligence review
Assessing an application portfolio
Improving developer productivity
Investigating slow delivery
Planning cloud cost reduction
Reviewing operational toil
Preparing for regulatory or audit requirements
Deciding whether to refactor or rewrite
Planning end-of-life remediation
Creating an engineering investment case
Reviewing AI-generated code accumulation

Do NOT Use This Workflow Whenpublic

This workflow is not intended to:

Label all old code as technical debt
Recommend rewrites by default
Replace defect management
Replace security vulnerability management
Replace architecture review
Replace capacity planning
Treat code-style differences as urgent debt
Prioritize work solely by developer preference
Produce exact financial estimates without evidence
Claim that complexity metrics alone determine business risk
Remove working systems merely because newer technology exists
Ignore contractual or regulatory constraints
Rank security findings only by remediation effort
Use line count as a proxy for debt
Treat every TODO comment as a validated debt item
Create a backlog too large to act upon

Technical debt should represent a specific liability with measurable consequences.

Expected Outcomepublic

After completing this workflow, you should have:

A normalized definition of technical debt
An evidence inventory
A categorized technical debt register
Debt items linked to business impact
Risk and cost assessments
Confidence levels
Dependency relationships
Ownership recommendations
Quick wins
Strategic remediation initiatives
Deferred items with documented rationale
A prioritized roadmap
Suggested success metrics
A governance and review cadence
Areas requiring further investigation

🔒 The complete playbook — reference models, worked examples, and operational guidance — is included with ABME membership.

Unlock Full Blueprint

Technical Debt Objectivesprotected

A complete technical debt assessment should answer:

What specific liability exists?
What evidence demonstrates the liability?
Why is it considered debt rather than a defect or feature request?
What business capability does it affect?
What is the present cost?
What future cost is likely?
What risk does it create?
How often does it affect delivery or operations?
What happens if it is not addressed?
Who owns the affected system?
What dependencies exist?
What remediation options are available?
What is the smallest useful intervention?
What would success look like?
How should the item be prioritized relative to other work?
When should the item be reviewed again?

Definition of Technical Debtprotected

For this workflow, a technical debt item should include:

A specific technical condition
A reason the condition creates cost, risk, or constraint
Evidence of present or expected impact
An affected business or engineering capability
A remediation path
A reason remediation has not already occurred
An owner or ownership recommendation

Weak: The code is old.

Stronger: The customer-notification service uses an unsupported runtime version, preventing security updates and requiring manual deployment steps. Two incidents in the past six months were extended because the service could not be rebuilt through the standard pipeline.

Technical Debt Categoriesprotected

Code Debt

Examples:

Duplicated business logic
Large functions
Unclear ownership
Excessive complexity
Hidden side effects
Global state
Dead code
Inconsistent error handling
Fragile abstractions
Unsafe null handling
Unmaintainable generated code

Architectural Debt

Examples:

Shared database ownership
Cyclic service dependencies
Tight deployment coupling
Missing service boundaries
Excessive synchronous dependencies
Single points of failure
Inappropriate data ownership
Unsupported architectural assumptions
Monolithic release constraints

Test Debt

Examples:

Missing regression tests
Unreliable integration tests
Flaky tests
Long test execution
Weak assertions
Uncovered security behavior
No migration testing
No compatibility testing
Manual-only release validation

Security Debt

Examples (security debt should remain linked to formal security risk-management processes):

Unsupported dependencies
Weak authentication patterns
Excessive privileges
Missing secret rotation
Inconsistent authorization
Unresolved vulnerabilities
Missing audit events
Inadequate tenant isolation
Legacy cryptography
Publicly exposed administrative interfaces

Dependency Debt

Examples:

Unsupported frameworks
End-of-life runtimes
Unpatched libraries
Deprecated APIs
Abandoned packages
Conflicting dependency versions
Vendor SDK lock-in
Custom forks
Unsupported database drivers

Infrastructure Debt

Examples:

Manual provisioning
Configuration drift
Unsupported operating systems
Single-zone deployment
Snowflake servers
Missing infrastructure-as-code
Inconsistent environments
Poor resource sizing
Manual certificate renewal
Legacy network design

Operational Debt

Examples:

Manual recovery
Manual deployments
Excessive alerts
Missing runbooks
High operational toil
Unowned scheduled jobs
Unreliable backups
Weak disaster recovery
Incomplete monitoring
No capacity forecasts

Observability Debt

Examples:

Missing structured logs
No correlation identifiers
Missing distributed traces
Generic error classification
No service-level indicators
Missing business metrics
Poor alert routing
Insufficient retention
Inability to isolate customer impact

Data Debt

Examples:

Inconsistent schemas
Duplicate records
Missing constraints
Unowned data
Undefined retention
Manual correction
Legacy formats
Incomplete migrations
Poor data lineage
Unverified backups
Unbounded table growth

Documentation Debt

Examples:

Undocumented APIs
Missing architecture diagrams
Outdated runbooks
Unknown system ownership
Missing onboarding guides
Undocumented deployment steps
Incomplete data dictionaries
Missing decision records
Undocumented failure behavior

Process Debt

Examples:

No code review standard
Manual release approvals without evidence
Unclear ownership
Missing incident follow-up
Inconsistent definition of done
No dependency update process
No rollback testing
Excessive handoffs
Long-lived branches
Incomplete change documentation

Cost Debt

Examples:

Inefficient cloud architecture
Orphaned resources
Overprovisioned environments
Excessive data transfer
Duplicate platforms
Expensive proprietary dependencies
Inefficient queries
High support labor
Repeated manual work

Knowledge Debt

Examples:

Single-person dependency
Undocumented tribal knowledge
Incomplete ownership transition
No operational cross-training
Critical systems without maintainers
Unclear business-rule history
Missing rationale for architecture decisions

Technical Debt Versus Other Workprotected

Technical Debt

A structural or operational liability that increases cost, risk, or difficulty of future change.

Defect

A failure to meet intended behavior.

Feature

New or expanded user or business capability.

Maintenance

Routine work needed to keep a system operating, such as ordinary patching or certificate renewal.

Modernization

A coordinated effort to replace or upgrade technology, architecture, or operating practices.

Preference

A stylistic or technology choice without demonstrated impact. An item may belong to more than one category, but it should be classified by its primary purpose.

Debt Evidence Sourcesprotected

Source Code

Examples:

Complexity
Duplication
Dependency direction
Hidden state
Unsafe patterns
Obsolete interfaces
Code ownership
Change frequency

Version Control

Examples:

Hotspot files
Repeated rework
Frequent reversions
Long-lived branches
Large pull requests
Ownership concentration
Change failure patterns

Defect and Incident History

Examples:

Repeated failures
Long recovery time
Recurring root causes
Manual remediation
Escalation volume
Customer impact
Rollbacks

CI/CD Data

Examples:

Build duration
Test failure rate
Flaky tests
Deployment failure
Rollback frequency
Manual approval duration
Environment inconsistency
Package failures

Security Data

Examples:

Vulnerability findings
Unsupported versions
Privilege reviews
Penetration-test findings
Audit exceptions
Secret exposure
Policy violations

Operational Data

Examples:

Alert volume
On-call effort
Manual tasks
Restart frequency
Resource exhaustion
Capacity limits
Recovery time
Service-level breaches

Financial Data

Examples:

Cloud cost
Licensing
Vendor support
Contractor reliance
Support labor
Incident cost
Opportunity cost
Repeated project overruns

Team Feedback

Team feedback is evidence, but it should be supported by observable examples where possible. Examples:

Difficult modules
Slow onboarding
High-risk deployments
Unknown ownership
Repeated workarounds
Testing pain
Local knowledge

Confidence Modelprotected

Confirmed

The technical condition and its impact are directly supported by evidence.

Unsupported runtime documented by the vendor
Repeated incidents linked to the same component
Test suite fails intermittently in CI
Manual deployment steps are documented and measured

Probable

The condition is well supported, but impact or cause has not been fully measured.

Possible

The condition is plausible but requires additional investigation.

Disputed

Stakeholders disagree about whether the condition constitutes debt or its impact.

Ruled Out

Evidence shows the suspected debt does not materially exist or has already been remediated.

Debt Impact Dimensionsprotected

Impact Dimensions

Evaluate each item across:

Business impact
Customer impact
Security impact
Regulatory impact
Availability impact
Data impact
Financial impact
Delivery impact
Developer productivity
Operational toil
Scalability
Maintainability
Strategic flexibility
Vendor dependence
Knowledge concentration

Debt Cost Dimensionsprotected

Current Cost

The cost already being paid.

Extra engineering hours
Manual deployment effort
Repeated incident response
Higher cloud cost
Additional support tickets
Slow test execution
Delayed releases

Future Cost

Expected cost if debt remains.

Larger migration
Increased vulnerability
Lost compatibility
Greater data volume
Higher licensing cost
Declining maintainability
More complex replacement

Remediation Cost

Estimated effort to reduce or retire the debt.

Delay Cost

The incremental cost created by postponing remediation.

Prioritization Modelprotected

Prioritization Factors

A practical prioritization score may consider:

Business impact
Security or regulatory exposure
Incident frequency
Delivery delay
Operational toil
Change frequency
Cost growth
Dependency urgency
Remediation effort
Confidence
Strategic alignment

Simple Weighted Model

Priority Score = (Business Impact × 3) + (Security and Compliance Risk × 3) + (Operational Impact × 2) + (Delivery Friction × 2) + (Frequency × 2) + (Cost Growth × 2) + (Strategic Importance × 2) + Confidence − Remediation Effort. Any formula should support discussion rather than replace judgment.

Severity Modelprotected

Critical

The debt creates an immediate or near-term risk of:

Security compromise
Regulatory failure
Data loss
Major outage
Unsupported critical platform
Irrecoverable operations
Significant financial error
Cross-tenant exposure

High

The debt creates:

Frequent incidents
Severe delivery delays
High operational cost
Significant scaling limits
Major upgrade blockers
Repeated deployment failures
High knowledge concentration
Material customer impact

Medium

The debt creates:

Recurring inefficiency
Moderate maintenance difficulty
Localized risk
Slower testing
Inconsistent behavior
Limited operational toil
Future upgrade complexity

Low

The debt creates (severity describes impact, not remediation effort):

Minor readability issues
Small documentation gaps
Local duplication
Limited inconvenience
Cosmetic inconsistency

Remediation Categoriesprotected

Retire

Remove the system, code, dependency, or process.

Replace

Substitute a different component or platform.

Refactor

Improve internal structure while preserving behavior.

Upgrade

Move to a supported version.

Isolate

Reduce the debt’s blast radius.

Automate

Replace recurring manual work.

Document

Reduce knowledge or operational risk.

Monitor

Add observability where immediate remediation is not justified.

Accept

Explicitly retain the debt with documented rationale.

Defer

Postpone remediation to a defined review date.

Example Inputprotected

System: Customer Billing Platform

Evidence:

The application runs on an unsupported runtime.
Releases require four manual deployment steps.
Automated tests cover only pricing calculations.
Three incidents in the past year involved configuration drift.
Only one engineer understands the reconciliation process.
A database upgrade is required before the application runtime can be upgraded.
The billing platform processes high-value customer transactions.

Example Debt Registerprotected

ID	Debt Item	Category	Impact	Effort	Priority
TD-001	Unsupported application runtime	Dependency/Security	High security and support risk	High	Critical
TD-002	Manual deployment process	Operational/Process	Configuration drift and release risk	Medium	High
TD-003	Missing reconciliation documentation	Knowledge	Single-person dependency	Low	High
TD-004	Limited billing regression tests	Test	High change and financial risk	Medium	High
TD-005	Database upgrade blocks runtime upgrade	Infrastructure/Dependency	Blocks critical remediation	High	Critical

Example Detailed Debt Itemprotected

TD-001 — Unsupported Application Runtime

Category: Dependency and Security Debt

Affected System: Customer Billing Platform

Technical Condition: The application runs on a runtime version no longer receiving standard security and reliability updates.

Evidence:

Vendor support documentation identifies the runtime as end-of-life.
The application cannot consume current security packages.
The runtime upgrade is blocked by the current database driver.

Confidence: Confirmed

Business Impact: A security or compatibility issue could affect billing availability and financial processing.

Engineering Impact: Engineers must maintain older tools and cannot adopt supported package versions.

Security Impact: High

Current Cost:

Additional patch review
Compatibility workarounds
Limited vendor support
Extended incident diagnosis

Future Cost: Upgrade complexity is likely to increase as dependencies continue to diverge.

Dependencies:

Database platform upgrade
Database driver replacement
Regression test expansion

Smallest Useful Intervention: Build a compatibility test environment and identify the minimum supported runtime upgrade path.

Full Remediation: Upgrade the database, driver, runtime, application dependencies, and deployment pipeline.

Priority: Critical

Recommended Timeframe: Begin planning immediately

Success Criteria:

Application runs on a vendor-supported runtime.
Supported security packages can be installed.
Regression suite passes.
Deployment process supports rollback.
No unresolved critical compatibility issues remain.

Example Prioritization Discussionprotected

TD-003, the missing reconciliation documentation, requires less effort than the runtime upgrade but should not automatically outrank it.

However, it may be a quick win because:

It reduces a single-person dependency.
It supports the runtime and database upgrade.
It improves incident recovery.
It can be completed while larger remediation planning occurs.

This demonstrates why priority and sequencing are not always identical.

Analysis Conceptsprotected

Technical Debt Hotspots

A hotspot combines:

High change frequency
High complexity
High defect rate
High business importance
Low test coverage
Concentrated ownership

A complex file that rarely changes may be less urgent than a moderately complex module changed every week.

Change Frequency

Assess:

Commits per period
Number of contributors
Repeated bug fixes
Reverts
Merge conflicts
Release impact
Number of dependent systems

Debt in frequently changed components usually creates greater recurring cost.

Cost of Delay

The cost of delay may include:

More expensive future upgrades
Increased incident exposure
Security deadlines
Lost vendor support
Growing data volume
Higher cloud cost
Accumulating workarounds
Reduced market responsiveness
Increased staffing risk

Use evidence and ranges. Do not create false precision.

Debt Interest

Technical debt “interest” is the recurring cost paid because the debt remains.

Examples:

Thirty extra minutes per deployment
Repeated manual reconciliation
Slower pull-request validation
Additional incident diagnosis
Repeated compatibility work
Increased cloud consumption
Duplicated changes across modules

Debt with high recurring interest may deserve priority even when the immediate risk is moderate.

Remediation Effort

Use relative estimates where precise estimates are unavailable:

Very Low
Low
Medium
High
Very High

Or use broad ranges:

Less than one engineer-week
One to four engineer-weeks
One to three engineer-months
Multiple quarters
Program-level initiative

Include uncertainty and dependencies.

Planning and Sequencingprotected

Quick Wins

A quick win should have:

Clear value
Low implementation risk
Low or moderate effort
Few dependencies
Measurable outcome

Examples:

Documenting a critical manual process
Adding correlation IDs
Automating one deployment step
Removing an unused unsupported package
Adding a regression test for a recurring defect
Creating ownership metadata
Configuring dependency alerts
Fixing a noisy critical alert

Do not allow quick wins to consume all capacity while strategic risks remain.

Strategic Debt Initiatives

Strategic initiatives may include:

Runtime and framework upgrades
Database modernization
Service-boundary remediation
Test-platform overhaul
CI/CD modernization
Identity redesign
Multi-tenant isolation
Observability platform adoption
Data-governance improvements
Retirement of legacy systems

These require:

Executive sponsorship
Product coordination
Capacity planning
Migration strategy
Success metrics
Incremental milestones

Accepted Debt

Some debt should be accepted when:

Remediation cost exceeds expected value
The system will be retired soon
Exposure is low
A compensating control is effective
Remediation would disrupt critical delivery
The technology remains supported
The condition is stable and understood

Accepted debt should include:

Rationale
Owner
Compensating controls
Review date
Retirement trigger
Conditions that would change the decision

Acceptance is a decision, not neglect.

Deferred Debt

Deferred debt should include:

Reason for deferral
Dependency
Current controls
Reassessment date
Trigger for escalation
Expected cost growth
Owner

Avoid using “backlog” as an indefinite holding area.

Dependency Mapping

Debt items frequently depend on one another.

Example:

TD-005 Database upgrade
        ↓
TD-001 Runtime upgrade
        ↓
TD-006 Dependency modernization
        ↓
TD-004 Expanded regression testing
        ↓
TD-002 Deployment automation

The roadmap should reflect enabling work, not only priority scores.

Ownership

Every debt item should have:

Business capability owner
Technical owner
Remediation owner
Decision authority
Review date

Shared ownership often means no ownership. When a system lacks an owner, ownership debt may itself be a high-priority finding.

Technical Debt Roadmap

A practical roadmap may include:

Immediate

Critical security and support risks
Imminent end-of-life deadlines
High-risk operational gaps
Essential measurement
Knowledge preservation

Near Term

High-interest recurring debt
Deployment and test improvements
Dependency upgrades
Observability gaps
Repeated incident causes

Medium Term

Architectural remediation
Platform consolidation
Data improvements
Major automation
Framework modernization

Long Term

System replacement
Portfolio rationalization
Major platform migration
Business-process redesign

Success Metrics

Each remediation initiative should define measurable success.

Examples:

Deployment time reduced
Manual steps removed
Change failure rate reduced
Incident frequency reduced
Runtime supported
Critical vulnerabilities eliminated
Test execution stabilized
Onboarding time reduced
Cloud cost reduced
Recovery time improved
Alert noise reduced
Single-person dependency removed
Upgrade lead time reduced
Customer support volume reduced

Technical Debt Scorecardprotected

Example:

Category	Condition	Trend	Primary Concern
Code	Moderate	Worsening	High-change billing module
Architecture	High	Stable	Shared database coupling
Tests	High	Worsening	Missing integration coverage
Security	Critical	Worsening	Unsupported runtime
Operations	High	Stable	Manual deployment
Documentation	Medium	Improving	Runbook initiative underway
Knowledge	High	Worsening	Single reconciliation expert

A scorecard should summarize evidence, not replace detailed items.

Portfolio-Level Analysisprotected

For multiple applications, evaluate:

Business criticality
Technical health
Security exposure
Operating cost
Change demand
Strategic fit
Retirement plans
Vendor support
Data sensitivity
Integration complexity
Ownership

Portfolio decisions may include:

Invest
Maintain
Modernize
Contain
Replace
Retire

Refactor Versus Rewriteprotected

Favor Incremental Refactoring When

Core behavior is valuable
Tests can be added
Architecture can be improved gradually
Migration risk is high
Business continuity is essential
Components can be isolated

Consider Rewriting When

Requirements have fundamentally changed
The platform is unsupported
Architecture cannot satisfy critical needs
Incremental remediation cost is greater than replacement
Behavior can be specified and tested
A migration path exists
Organizational capacity exists

A Rewrite Should Include

Behavior inventory
Data migration
Parallel validation
Cutover
Rollback
Legacy retirement
Operational readiness

Financial Framingprotected

Technical debt business cases may include:

Current labor cost
Incident cost
Support cost
Cloud cost
Licensing cost
Lost delivery capacity
Cost of delayed features
Risk exposure
Upgrade cost growth

Use transparent assumptions.

Example:

Manual deployment effort:
6 deployments per month
× 3 engineers
× 1.5 hours
= 27 engineering hours per month

Do not convert risk into exact dollars without a defensible model.

Engineering Capacity Allocationprotected

Organizations may reserve capacity for:

Security remediation
Reliability
Dependency upgrades
Test improvement
Technical debt
Platform investment

A fixed percentage can be useful but should not override critical business or security priorities.

Alternative models include:

Dedicated debt sprints
Quarterly initiatives
Debt work embedded in feature delivery
Platform-team ownership
Risk-based allocation
Trigger-based remediation

Debt Preventionprotected

Technical debt cannot be eliminated, but its accumulation can be managed.

Preventive controls may include:

Definition of done
Architecture decision records
Test requirements
Dependency update process
Code ownership
Automated quality checks
Security review
Observability standards
Runbook requirements
Deprecation policy
Platform standards
Post-incident follow-up
Expiration dates for temporary workarounds

Temporary Workaroundsprotected

A temporary workaround should include:

Owner
Reason
Date created
Risk
Expiration date
Replacement plan
Monitoring
Removal criteria

Temporary code without an expiration mechanism often becomes permanent debt.

TODO and FIXME Commentsprotected

Review comments such as:

TODO
FIXME
HACK
TEMP
WORKAROUND

Do not automatically classify each as debt.

Validate:

Is the code still active?
Is the comment current?
Is there impact?
Is remediation needed?
Is the issue already tracked?
Is the workaround still necessary?
Who owns it?

AI-Generated Code Debtprotected

AI-generated code may create debt when:

It duplicates existing functionality
It introduces unsupported dependencies
It lacks tests
It ignores project conventions
It adds excessive abstraction
It includes fabricated APIs
It weakens error handling
It creates inconsistent security behavior
It lacks ownership
It is accepted without review

Track AI-generated code through the same engineering controls as human-written code.

Technical Debt Metricsprotected

Useful metrics include:

Critical debt items
High-risk unsupported dependencies
Debt items without owners
Debt items past review date
Recurring incident causes
Deployment manual steps
Flaky test rate
Build and test duration
Change failure rate
Mean time to recovery
Operational toil hours
Single-person dependencies
Percentage of systems with current architecture documentation
Percentage of debt items with success metrics
Debt retired
Debt accepted
Debt reopened
Cost savings from remediation

Avoid using the total number of debt items as a performance target.

Governance Recommendationsprotected

Define:

Technical debt criteria
Intake process
Evidence requirements
Severity model
Priority model
Ownership
Review cadence
Acceptance authority
Security escalation
End-of-life policy
Temporary workaround expiration
Documentation standards
Roadmap integration
Product-management participation
AI-generated assessment review
Metrics
Closure criteria

Suggested Review Cadenceprotected

Monthly

Review:

Critical and high-risk items
New security debt
Upcoming end-of-life dates
Blocked remediation
Debt linked to active incidents

Quarterly

Review:

Full prioritized register
Roadmap progress
Accepted debt
Deferred debt
Ownership
Trends
Capacity allocation

Annually

Review:

Application portfolio
Strategic modernization
Platform consolidation
Retirement candidates
Governance effectiveness
Debt cost model

Automation Opportunitiesprotected

Quarterly engineering reviews
Application portfolio management
Architecture governance
Security remediation
Dependency management
Incident follow-up
CI/CD dashboards
Cloud cost reviews
Engineering planning
Technical due diligence
Developer experience programs
AI code governance
A mature workflow could: collect data from repositories and delivery systems, identify code and dependency hotspots, correlate defects and incidents, measure operational toil, retrieve security and audit findings, generate candidate debt items, require human validation, score and prioritize approved items, assign owners and review dates, and track remediation outcomes over time.

Pro Tipsprotected

Define technical debt before measuring it.
Require evidence for every debt item.
Separate debt from defects, features, and preferences.
Prioritize business, security, and operational impact.
Consider change frequency.
Measure recurring debt interest.
Use ranges instead of false precision.
Identify the smallest useful intervention.
Compare refactor, upgrade, replace, and retire options.
Do not recommend rewrites by default.
Map dependencies before sequencing work.
Treat knowledge concentration as real risk.
Preserve critical documentation before staff transitions.
Record accepted debt explicitly.
Give deferred debt a review date.
Connect debt remediation to measurable outcomes.
Combine related debt into strategic initiatives.
Balance quick wins with long-term risks.
Assign one accountable owner.
Review the register regularly.
Remove resolved items.
Require human validation of AI-generated findings.

Common Mistakesprotected

Treating Old Technology as Debt Automatically — A stable, supported system may not create meaningful debt.
Prioritizing by Engineer Frustration Alone — Frustration is an important signal, but priority should include business and operational evidence.
Creating One Giant "Legacy System" Item — Break broad concerns into specific liabilities with separate evidence and remediation paths.
Mixing Defects and Debt — A defect may be one-time. Repeated defects caused by structural conditions may demonstrate debt.
Ignoring Security Debt — Low-effort code cleanup should not outrank material security exposure.
Recommending Rewrites Too Quickly — Rewrites introduce migration, compatibility, and operational risk.
Using False Precision — Debt cost and effort estimates are often uncertain. Use ranges and assumptions.
Ignoring Dependencies — The highest-scored item may not be actionable until enabling work is completed.
Filling the Backlog Without Ownership — An unowned debt register becomes documentation rather than a management process.
Never Removing Resolved Items — The register should reflect current liabilities, not become a permanent archive.
Accepting Debt Informally — Accepted risk should be documented and reviewed.
Measuring Only Code Quality — Operational, security, infrastructure, data, process, and knowledge debt may be more important.
Ignoring Product Roadmap Context — Some debt becomes urgent because upcoming features will increase load or change usage.
Solving Symptoms — Automating a restart may reduce toil without addressing the reason the service repeatedly fails.

Security Considerationsprotected

Technical debt assessments may contain sensitive information about vulnerabilities, unsupported systems, architecture weaknesses, privileged access, internal dependencies, incident history, regulatory findings, recovery limitations, and single points of failure.
Before sharing evidence with an AI system: remove credentials, tokens, and private keys.
Before sharing evidence with an AI system: remove customer data and sanitize internal identifiers where required.
Follow vulnerability-handling rules and confirm the platform is approved.
Confirm retention and training settings before submitting evidence.
Restrict distribution of the final register and classify sensitive debt items appropriately.
Do not publish security debt in broadly accessible planning systems without appropriate controls.

Brian Diamond

Founder, BrianOnAI

Twenty-five years designing, operating, and governing enterprise infrastructure — from MSP operations across dozens of client environments to enterprise infrastructure leadership. This blueprint codifies the operating model he's implemented in production, not theory.

Related Blueprints

Perform an AI-Assisted Code Review Analyze and Diagnose a Software Defect Perform an Application Architecture Review Generate Unit and Integration Tests Refactor Code Safely Generate API and Developer Documentation Review a Technical Design Modernize a Legacy Application Build and Maintain Development Prompts Explain a Legacy PowerShell Script Generate Pester Tests for a PowerShell Script Refactor PowerShell for Readability and Maintainability

⚠ Normalization Warnings — 11 for review

CLASSIFICATION TO CONFIRM: 'Prerequisites' classified as a checklist TOOL (gather-before-start items are completable). Alternative: body/prose.
CLASSIFICATION TO CONFIRM: 'Testing Recommendations' classified as a checklist TOOL named 'Remediation Test Plan' (per-category test items are verifiable/selectable). Alternative: body/reference. Display name changed from source heading — confirm.
RESTRUCTURE: 'Primary Prompt' and 'Follow-Up Prompts' (two source H1s) combined into one prompt_pack tool with 14 prompts; 'when' guidance lines are editorial additions, prompt text verbatim.
NEW TOOL DERIVED: 'Technical Debt Register' matrix built from the 'Create a Technical Debt Register' follow-up prompt's column list plus the 'Example Debt Register' table. Columns are the prompt's stated fields; example_rows are reconstructed from the doc's own Example Input / Example Debt Register / Example Detailed Debt Item (blank cells where the doc gave no value). Confirm columns and rows — some example_row cells were left empty rather than invented.
MATRIX RUBRIC left empty: the doc defines a Prioritization Model formula and Severity Model but does not tie them to the register table as a scoring rubric per the schema's rubric field — kept those as reference sections instead. Confirm.
RESTRUCTURE: 'Security Considerations' and 'Common Mistakes' mapped to playbook flat lists (prose subsections flattened to strings) rather than body groups, since each is short single-sentence guidance. Confirm vs. keeping as body groups.
CLASSIFICATION: 'Debt Register Matrix' assigned phase 2 (produced during identification/classification); the empty-download skeleton_rows:0 rule applied.
AI-007 has no explicit Quick Wins or Roadmap H1 tail sections in the standard playbook shape — 'Quick Wins', 'Strategic Debt Initiatives', and 'Technical Debt Roadmap' are treated as body/prose planning guidance (grouped under 'Planning and Sequencing'), so playbook.quick_wins and playbook.roadmap are intentionally empty.
GROUPING: The many mid-doc concept sections were grouped into 'Analysis Concepts' and 'Planning and Sequencing' to avoid a flat list of 40+ sections. Remaining standalone sections (Financial Framing, Capacity Allocation, Debt Prevention, Temporary Workarounds, TODO/FIXME, AI-Generated Code Debt, Metrics, Governance) left ungrouped as they are distinct tail topics — confirm grouping boundaries.
REFERENCE vs PROSE: 'Technical Debt Categories', 'Debt Versus Other Work', 'Evidence Sources', 'Confidence Model', 'Severity Model', 'Remediation Categories', 'Refactor Versus Rewrite', 'Review Cadence', 'Impact/Cost/Prioritization Models' classified as body/reference (consulted taxonomies/tiered models). Confirm.
RELATED: Both AI-series and PS-series related workflows combined into seo.related as slugs.

SEO Block

Title tag: Identify & Prioritize Technical Debt | ABME (43 chars)
Meta: Turn "that module is a mess" into a prioritized, evidence-based technical debt register with owners, risk, cost, and a roadmap you can fund. (140 chars)
Schema: HowTo · noindex: false
Related: ai-001, ai-002, ai-003, ai-004, ai-005, ai-006, ai-008, ai-009, ai-010, ps-001, ps-004, ps-005, ps-006, ps-008, ps-009, ps-010
Keywords: technical debt, technical debt register, prioritize technical debt, technical debt assessment, code debt, security debt, debt remediation roadmap, refactor vs rewrite, technical debt prioritization model, engineering debt management, dependency debt, operational toil

Copied

Stop Managing Technical Debt by Anecdote — Build an Evidence-Based Register You Can Actually Fund

Executive Brief

Your Challenge

Common Obstacles

The ABME Approach

Insight Summary

The Journey

Define Debt and Inventory Evidence

Identify and Classify with AI

Prioritize, Sequence, and Govern

What's Inside the Execution Layer

Prerequisites Checklist

Technical Debt Prompt Pack

Primary Prompt

Analyze a Codebase for Technical Debt

Analyze Technical Debt from Incidents

Analyze Delivery Friction

Analyze Operational Toil

Analyze Dependency Debt

Analyze Security Debt

Analyze Test Debt

Analyze Documentation and Knowledge Debt

Compare Refactor, Rewrite, and Replace

Create a Technical Debt Register

Create an Executive Business Case

Create a Quarterly Debt Roadmap

Technical Debt Intake Template

Debt Title

Affected System

Technical Condition

Evidence

Business Impact

Engineering Impact

Current Workaround

Frequency

Proposed Remediation

Consequence of Deferral

Owner

Technical Debt Register

Validation Checklist

Remediation Test Plan

Code Debt

Architecture Debt

Dependency Debt

Infrastructure Debt

Operational Debt

Security Debt

Full Playbook

Overviewpublic

Business Problempublic

Typical Use Casespublic

Do NOT Use This Workflow Whenpublic

Expected Outcomepublic

Technical Debt Objectivesprotected

Definition of Technical Debtprotected

Technical Debt Categoriesprotected

Code Debt

Architectural Debt

Test Debt

Security Debt

Dependency Debt

Infrastructure Debt

Operational Debt

Observability Debt

Data Debt

Documentation Debt

Process Debt

Cost Debt

Knowledge Debt

Technical Debt Versus Other Workprotected

Technical Debt

Defect

Feature

Maintenance

Modernization

Preference

Debt Evidence Sourcesprotected

Source Code

Version Control

Defect and Incident History