Technical Debt Inventory and Attributes

Section A — Sourcing and Harvesting

Before building the Technical Debt Inventory from scratch, assess whether candidate conditions and partial records can be harvested from systems already operating in the enterprise. Common sources include engineering and delivery backlogs, Architecture Exception repositories, Security Finding and vulnerability-management platforms, Risk systems, IT service management Issue records, Asset and configuration repositories, application and technology portfolio tools, code-quality and testing platforms, observability systems, cloud and infrastructure management tools, modernization plans, roadmaps, Project and Release systems, audit reports, and controlled spreadsheets.

Harvested records are candidates, not automatically Technical Debt Items. Automated findings, Defects, Problems, Disruptions, Risks, Security Findings, Architecture Exceptions, obsolescence notices, and backlog tasks remain in their authoritative systems unless qualification confirms an independently governable Technical Debt condition. Candidate harvesting should preserve the source identifier, source system, evidence, discovery date, proposed Assets, and provisional classification so practitioners can validate, merge, split, reject, monitor, or register the condition appropriately.

AI agents can help identify candidate Technical Debt from technical Documentation, Architecture records, Asset inventories, support notices, dependency data, source repositories, configuration records, Project artifacts, and operational evidence. AI-generated candidates must remain reviewable suggestions, and the generation method, source materials, confidence, assumptions, and human validation should be recorded through Provenance and Audit Attributes.

Where harvesting is not possible, manual inventory governance is viable. Teams may create candidate records from structured reviews, lifecycle assessments, modernization planning, incident and Issue analysis, Architecture and Security governance, or direct practitioner identification. The priority is an accurate and actively maintained inventory; broader integration and automation can follow.

Section B — Ownership and Accountability

Every inventory must have a named owner—an individual or function accountable for the accuracy, completeness, schema, stewardship, integration, and governance of the Technical Debt Inventory as a whole. Inventory ownership is distinct from Technical Debt Item ownership: the Technical Debt Owner is accountable for progressing one item through qualification, assessment, decision, remediation or other treatment, validation, closure, and possible reopening.

A natural organizational home may be Enterprise Architecture, Engineering Governance, Technology or Application Portfolio Management, an enterprise Technical Debt Management function, or another cross-functional governance capability. Regardless of organizational placement, the model must preserve Asset Owner accountability for aggregate debt exposure and ensure that Architecture, Security, Risk, Operations, Finance, Product, Portfolio, and Delivery authorities participate according to their decision rights. Ownership by committee without a named accountable individual is not recommended.

Section C — Lifecycle and Review Cadence

The Technical Debt Inventory is a living governance artifact. Technical Debt Items move through the approved lifecycle statuses: Suspected, Under Qualification, Validated, Under Assessment, Awaiting Decision, Accepted, Deferred, Approved for Remediation, Planned, In Remediation, Awaiting Validation, Closed, Rejected, and Reopened. Paths may vary by materiality and disposition, but every transition must preserve appropriate identity, ownership, evidence, authority, dates, and history.

Reconciliation cadence should reflect materiality, status, expiration, Asset criticality, dependency reach, and change. At minimum, enterprises should review expiring acceptance and deferral decisions, overdue qualification and decisions, stale assessments, missed remediation milestones, changed provider support, new dependencies, new Security or regulatory evidence, repeated reopening, and related-record changes. Crawl implementations may reconcile quarterly, Walk implementations monthly or event-driven, and Run implementations continuously or near-continuously with human review of exceptions and decisions.

Section D — Data Quality and Starting Approach

Do not attempt to populate every advanced attribute for every Technical Debt Item at initial capture. Begin with the minimum viable record: stable identity, name, condition statement, source, discovery date, at least one governed Asset, evidence, status, proposed type, and provisional ownership. Complete qualification information before the item becomes Validated; complete assessment information before Awaiting Decision; complete acceptance or deferral terms before those statuses; complete plan, owner, funding, milestones, dependencies, outcomes, and validation criteria before Planned; and complete actual validation evidence before Closed.

Populate Crawl attributes consistently across all active records before relying on Walk or Run analytics. Records that cannot be validated against authoritative evidence should carry explicit confidence and data-quality indicators. Duplicate, merge, split, rejected, and reopened histories must be preserved so the inventory does not create false counts or erase decision history.

Section E — Access Control

The Technical Debt Inventory contains governance-sensitive technical, financial, Security, Risk, Asset, ownership, and decision information. Read access should be broad enough for legitimate governance and planning, while write access should be limited to authorized owners, stewards, decision authorities, validators, and controlled integrations. Highly sensitive evidence may remain in its authoritative source with access-controlled references rather than being copied into the inventory.

Schema changes should be restricted to the inventory owner and governing body. At Crawl maturity, a protected shared spreadsheet with controlled edit rights and an auditable change process may be adequate.

Section F — Change Management

The Technical Debt Item schema and its controlled value sets are governed artifacts. Additions, removals, renames, value-set changes, lifecycle changes, calculation changes, and relationship changes should follow a controlled process: Propose → Review → Approve → Implement → Communicate. Changes must preserve compatibility with existing records, reports, integrations, historical values, and the Enterprise Model.

Material reclassification or relationship changes at the item level should preserve prior values and trigger reassessment when ownership, materiality, priority, acceptance, remediation, validation, or closure may be affected.

Section G — Archival and Retention

Closed and Rejected Technical Debt Item records are not deleted. Retain their condition, Assets, evidence, decisions, validation, closure or rejection rationale, relationships, and audit history so the enterprise can support compliance, trend analysis, prevention, learning, and reopening. Merged and split records must retain links to the surviving or resulting items.

Archived records should remain queryable but may be excluded from active governance reporting. Retention should align with regulatory, contractual, Security, audit, litigation-hold, Asset-lifecycle, and enterprise record-management requirements. Records associated with major investments, critical Assets, significant incidents or Issues, regulatory obligations, Security events, acquisitions, divestitures, or enterprise-level decisions may require indefinite or extended retention.