Register of Socio-Technical Debt
Socio-technical debt (STeD) occurs when past social and/or technical decisions lead to inefficiencies or increased risks in designing, building, maintaining, managing or using digital solutions, which in turn hampers the organisation's ability to create value and reach its goals. The register collects every category of debt identified in my doctoral thesis and in literature published since, sorted by whether the debt resides in the technical artefact or in the social structures around it.
- 79 categories
- 46 technical debt
- 34 added after the thesis
- 26 sub-categories
- 4 umbrella concepts
- Visualisation of how it all fits together
- History of the concept
The register
Search by English or Swedish name, or by words in the description. Filter by domain (social or technical) and by the umbrella concept within which the category was originally defined. Each entry states the source of its definition.
The register covers the categories of the thesis plus 34 categories not included in the thesis, added in 2026 after a literature review and tagged New. 26 of the categories are arranged as sub-categories of another category, which is stated on the card with a link to the parent category. The arrangement is based on the literature review and my own assessment, and also applies to several of the thesis's original categories. All categories still have their own cards and can be searched.
About the names: the English terms are the established ones
The category names are the established English terms used in the research literature, and they are the names to use when referring to that literature. The Swedish names shown in parentheses are my own translations, used on the Swedish version of this page; they are not established Swedish terms.
Search and filters require JavaScript. All categories are shown below.
Showing 79 of 79 categories.
Technical debt (teknisk skuld)
46 categoriesTechnical debt is a collection of design or implementation constructs that are expedient in the short term but set up a technical context that can make future changes more costly or impossible. It presents an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability. It resides in artefacts such as code, architecture, databases and testing frameworks.
-
Accessibility debt (Tillgänglighetsskuld)
Accumulated accessibility barriers created when inclusive-design requirements are postponed and later require costly redesign or remediation.
A category in its own right, conceptually distinct from Usability debt.
Source: Indika et al., 2026; Lazar et al., 2026
-
Agentic technical debt (Agentisk teknisk skuld)
System-level debt specific to agentic AI, arising from autonomous reasoning, persistent memory, tool orchestration, multi-agent coordination, and evolving agent behaviour.
A standalone category for now. The literature describes it as an emerging umbrella concept that could in time group AI configuration debt, AI data debt and AI model debt, but that arrangement is not made yet.
Source: Tukur et al., 2026
-
AI configuration debt (AI-konfigurationsskuld)
Deficiencies around the configuration mechanisms of AI-based systems.
Sub-category of Configuration debt.
Source: Bogner et al., 2021
-
AI data debt (AI-dataskuld)
Deficiencies related to the collection, management and usage of data, both for training models and in production.
Sub-category of Data debt. The AI-specific form of data debt, tied to training and production data.
Source: Bogner et al., 2021
-
AI model debt (AI-modellskuld)
Suboptimal practices in the design, training and management of AI models.
Source: Bogner et al., 2021
-
Algorithm debt (Algoritmskuld)
Sub-optimal implementations of algorithm logic.
Sub-category of Code debt (implementation debt). Concerns sub-optimal implementation of algorithm logic.
Source: Liu et al., 2020
-
Architectural debt (Arkitekturskuld)
Problems encountered in product architecture that affect architectural requirements. It has a significant influence on system success and, left unchecked, can cause expensive repercussions. Upgrades to systems with high architectural debt require three times the effort of well-structured architectures, and early architectural shortcuts increase brittleness and later rework costs.
Source: Rios et al., 2018; Besker et al., 2016; MacCormack et al., 2012
-
Automation (build) debt (Automatiseringsskuld)
In today's fast-paced, release-oriented development, almost any manual step in building a software system indicates automation debt. It is both a source of and a resolution approach to technical debt (also called build or DevOps debt).
Sub-categories: Build debt, Pipeline debt. Groups debts in build, delivery and deployment flows.
Source: Rosser & Norton, 2021
-
Automation test debt (Testautomatiseringsskuld)
The work involved in automating tests of previously developed functionality to support continuous integration and faster development cycles, plus the accumulation of issues such as poorly maintained test scripts, outdated test cases and lack of proper test coverage.
Sub-category of Test debt (testing debt).
Source: Rios et al., 2018; Wiklund et al., 2012
-
Build debt (Byggskuld)
Issues that make the build task harder and unnecessarily time-consuming, for instance building and running unnecessary code and tests.
Sub-category of Automation (build) debt. Overlaps automation debt to a high degree.
Source: Rios et al., 2018; Morgenthaler et al., 2012
-
Code debt (implementation debt) (Kodskuld)
Problems found in the source code, that is poorly written code that violates best coding practices or coding rules, which reduces legibility and makes the code harder to maintain. This is Cunningham's original 1992 metaphor: ‘shipping first-time code is like going into debt’.
Sub-categories: Algorithm debt.
Source: Cunningham, 1992; Rios et al., 2018
-
Compatibility debt (Kompatibilitetsskuld)
A project's immature dependencies on other projects that cannot supply all qualified services, so that the current implementation is a temporary workaround.
Sub-category of Dependency debt. Defined by immature dependencies on other projects.
Source: Liu et al., 2020
-
Configuration debt (Konfigurationsskuld)
Incurred when configuration mechanisms are not controlled with the same rigour as the software, when differences between configurations cannot easily be determined, or when redundant or unused configuration data exists.
Sub-categories: AI configuration debt.
Source: Rosser & Norton, 2021
-
Cost debt (token debt) (Kostnadsskuld (tokenskuld))
Debt that arises when longer or inefficiently designed prompts increase token consumption and thereby the operating cost of systems built on large language models over time.
A category in its own right. Closely related to Prompt debt but focuses on the financial operating cost rather than prompt quality. The term token debt also appears in grey literature (HackerNoon).
Source: Aljohani & Do, 2025
-
Data debt (Dataskuld)
Technical debt in the data itself, separate from the software and the data storage system: quality issues such as missing values, biased distributions, poor metadata, untracked schema evolution or inconsistent preprocessing. Later causes model drift, fairness violations, reduced robustness and increased cost of retraining and integration.
Sub-categories: AI data debt. Distinguished from Information debt, which concerns the information layer on the social side, and from Database debt, which concerns the storage system. Semantic debt is closely related.
Source: Foidl et al., 2019; Tukur et al., 2026
-
Database debt (Databasskuld)
Accumulated through issues with data requirements, data architecture, database design, implementation and documentation, and through the typical dependence on a third party for the database package (commercial or open source).
Sub-categories: Database-design debt.
Source: Rosser & Norton, 2021
-
Database-design debt (Databasdesignskuld)
Immature or suboptimal database design decisions that lag behind the optimal or desirable ones.
Sub-category of Database debt. Database debt already covers database design.
Source: Al-Barak & Bahsoon, 2016
-
Defect debt (Defektskuld)
The trade-off between the short-term benefit of postponing bug-fixing and the long-term consequences of delaying it. Known defects that the development team agrees should be fixed but that are deferred due to competing priorities and limited resources.
Sub-category of Quality debt. Quality debt concerns the total effort to fix defects; defect debt the known defects that have been deferred.
Source: Akbarinasaji et al., 2016; Rios et al., 2018
-
Dependency debt (Beroendeskuld)
Accumulated liabilities caused by external libraries, services, models, components, or data dependencies that become difficult, risky, or costly to change.
Sub-categories: Compatibility debt. A category in its own right that fills a clear gap in figure 2 of the thesis.
Source: Sculley et al., 2015; Arpteg et al., 2018
-
Deployment debt (Driftsättningsskuld)
All the shortcuts, errors or mistakes that happen when deploying, for example rushed or incomplete deployment processes. More recent, mainly AI-related literature describes it as the accumulated engineering work created when prototypes or locally successful systems are repeatedly advanced without resolving the requirements for reliable production deployment and operation.
Pipeline debt is closely related but concerns the pipeline itself rather than the transition to production.
Source: Ernst et al., 2021; Asatiani & Torell, 2023; Costa, 2026
-
Depreciation debt (Föråldringsskuld)
Software systems that have longevity incur depreciation debt because the rate of technology change often overtakes even a well-written software system.
Source: Rosser & Norton, 2021
-
Design debt (Designskuld)
Tough time-to-market constraints and unanticipated integration or evolution issues lead to design trade-offs that cause flaws in the structure of a software system, such as violations of good object-oriented design principles or design shortcuts in customisation software. Design issues accumulate over time, making later modifications up to three times as costly as addressing them early.
Source: Marinescu, 2012; Rios et al., 2018; Rolland et al., 2018; Zazworka et al., 2014
-
Documentation debt (Dokumentationsskuld)
Missing, inconsistent, outdated or incomplete documentation, including outdated design specifications and lack of code comments. The only category recognised under all three umbrella concepts: technical, digital and non-technical debt.
Source: Rios et al., 2018; Ernst et al., 2021; Ahmad et al., 2024
-
Domain debt (Domänskuld)
The mis-representation of the application domain by an actual system.
Sub-category of Requirements debt (social debt). Mis-representation of the domain usually originates in requirements work. Placed under requirements debt although it sits on the technical side.
Source: Störrle & Ciolkowski, 2019
-
Energy debt (Energiskuld)
Accumulated energy inefficiency in software that increases the future effort required to bring energy consumption back to an acceptable level.
Sub-category of Sustainability debt.
Source: Couto et al., 2020
-
Explainability debt (Förklarbarhetsskuld)
The accumulated gap between the explainability, auditability, and stakeholder understanding required from an AI system and what the deployed system actually provides.
Sub-category of Transparency debt. The AI-specific form of transparency debt. Also closely related to AI ethics debt.
Source: Gandikota, Jegathesan et al., 2026
-
Infrastructure debt (Infrastrukturskuld)
Infrastructure issues that delay or hinder development activities, for example postponed upgrades. Deficiencies in infrastructure lead to potentially long lead times for future changes and require modernisation and new investment before new innovation with concrete benefits can be delivered.
Source: Rios et al., 2018; Alves et al., 2014; Magnusson et al., 2018
-
Integration debt (Integrationsskuld)
The effort involved in connecting systems or components together to achieve desired functionality. Non-standard connections, proprietary interfaces and niche standards increase the debt.
Sub-categories: Service debt.
Source: Rosser & Norton, 2021
-
Interoperability debt (Interoperabilitetsskuld)
Difficulties for systems, components or organisations to exchange and meaningfully use information and services, resulting from early choices of standards, interfaces and components in complex, distributed systems. According to Yang's taxonomy, a debt that can be detected already in the acquisition phase.
A category in its own right at the system-of-systems level. Integration debt is the artefact-level form (non-standard connections and proprietary interfaces), Semantic debt the informational form and Compatibility debt the dependency-related form. Especially relevant for the public sector, where Institutional debt in standards and regulations is often the root cause.
Source: Yang et al., 2023
-
Modelling and simulation debt (Modellerings- och simuleringsskuld)
As model-based engineering becomes standard practice, the models become part of the technical baseline and are themselves subject to technical debt.
Source: Rosser & Norton, 2021
-
Performance debt (Prestandaskuld)
Accumulated future cost caused by deferred performance, scalability, latency, throughput, or resource-efficiency improvements.
A category in its own right, with a smaller research base than code and architectural debt.
Source: Carvalho et al., 2026
-
Pipeline debt (Pipelineskuld)
Debt embedded in brittle, tightly coupled, poorly reproducible, or weakly governed build, data, ML, or deployment pipelines.
Sub-category of Automation (build) debt. Especially relevant for AI/ML systems.
Source: Brahmi et al., 2026
-
Privacy debt (Integritetsskuld)
The quantity of effort required for identifying, governing, controlling, communicating and protecting the software system with regard to data protection and regulatory compliance throughout the development lifecycle.
Sub-category of Compliance debt (social debt). Placed under compliance debt since the emphasis is on regulated data protection. Also closely related to Security debt.
Source: Larrucea et al., 2021
-
Prompt debt (Promptskuld)
Debt in the design, configuration and optimisation of prompts in systems built on large language models. The primary source of LLM-specific self-admitted technical debt; instruction-based prompts are affected because of their dependence on instruction clarity and few-shot prompts because of example quality.
A category in its own right. Closely related to Configuration debt, since prompts act as configuration of the model, and belongs to the same emerging area as Agentic technical debt.
Source: Aljohani & Do, 2025; Ehsani et al., 2026
-
Quality debt (Kvalitetsskuld)
The measure of the effort to fix the defects, discovered or undiscovered, that exist within a system at a given point in time.
Sub-categories: Defect debt.
Source: Rosser & Norton, 2021
-
Reproducibility debt (Reproducerbarhetsskuld)
The accumulated cost that arises when computations and results of a software system can no longer be reproduced, as a consequence of complexity and continuous evolution in code, data, dependencies and environments. Formally defined for scientific software, with a taxonomy of 37 causes and 63 effects in seven categories.
A category in its own right. Its causes largely lie in Documentation debt, Versioning debt, Dependency debt and Pipeline debt; especially relevant for research software and AI/ML systems.
Source: Hassan et al., 2024; Hassan et al., 2025
-
Security debt (Säkerhetsskuld)
A solution that compromises the security of the system, for example by introducing a particular breach of security. Technical debt containing a security risk.
Source: Silva et al., 2016; Rindell et al., 2019
-
Semantic debt (Semantisk skuld)
Accumulated inconsistencies, ambiguity, and incompatible meanings in schemas, ontologies, and shared data concepts that make integration increasingly costly.
Sub-category of Information debt (social debt). Placed under information debt although it sits on the technical side. Potentially very relevant for information infrastructure.
Source: Mukherjee, 2026
-
Service debt (Tjänsteskuld)
The inappropriate selection and substitution of web services that leads to a mismatch between the service features and the applications' requirements. Relevant for service-oriented architectures.
Sub-category of Integration debt.
Source: Rios et al., 2018
-
Sustainability debt (Hållbarhetsskuld)
Accumulated future cost and risk caused by architectural or design decisions that defer environmental, economic, social, individual, or technical sustainability requirements.
Sub-categories: Energy debt. Well established since 2016.
Source: Ojameruaye et al., 2016
-
System evolution debt (Systemevolutionsskuld)
Debt that arises when a complex system cannot evolve in step with changing needs, technology and surrounding systems, leading to obsolescence and in the worst case programme cancellation. According to Yang's taxonomy, a consequence of premature decisions in early life-cycle phases.
A category in its own right. Depreciation debt is the software-level form of the same phenomenon; Infrastructure debt and Dependency debt are common causes.
Source: Yang et al., 2023
-
Test debt (testing debt) (Testskuld)
Shortcuts, that is wrong or non-optimal decisions, related to testing, and issues found in testing activities that can affect the quality of those activities.
Sub-categories: Automation test debt.
Source: Samarthyam et al., 2017; Rios et al., 2018
-
Transparency debt (Transparensskuld)
The fact that the code is closed leads to transparency issues regarding what data is stored about citizens and what algorithms are used when cases are evaluated. Identified in the thesis's first study of the building-permit systems of a Swedish municipality.
Sub-categories: Explainability debt. Explainability debt is the AI-specific form.
Source: Persson et al., 2023 (publication I)
-
Usability debt (Användbarhetsskuld)
Inappropriate usability decisions that will need to be adjusted later, such as lack of usability testing, poor interface design and complex navigation structures that increase users' cognitive load. In web applications, usability debt incurred early has been shown to increase redesign costs by 50 per cent.
Accessibility debt is conceptually distinct and is kept as its own category.
Source: Rios et al., 2018; Alves et al., 2016; Rodriguez et al., 2023
-
Variability debt (Variabilitetsskuld)
Defects and sub-optimal solutions in the implementation of variability management in software systems, for example opportunistic reuse that brings short-term benefits regardless of technical and architectural drawbacks in the medium and long term.
Source: Wolfart et al., 2021
-
Versioning debt (Versionshanteringsskuld)
Problems in source-code versioning, such as unnecessary code forks.
Source: Rios et al., 2018
No categories match your search. Try another word or clear the filters.
- TD
- Technical debt in the traditional sense, mainly per Rios et al. (2018) and later additions.
- AI
- AI-specific forms of technical debt per Bogner et al. (2021).
- DD
- Digital debt per Rolland et al. (2018), Ernst et al. (2021) and Asatiani & Torell (2023).
- TyD
- Technology debt per Magnusson & Bygstad (2014) and Magnusson et al. (2018).
- NTD
- Non-technical debt per Saeeda et al. (2023) and Ahmad et al. (2024).
- Own
- Category identified in the thesis's own studies.
- New
- Category not included in the thesis, added to the register in 2026 after a literature review (sources 2015–2026).
How the debts interrelate
The division into two domains gives analytical clarity, but in practice the debts reinforce each other. Weak governance and siloed decision-making produce inconsistent architectures and fragmented codebases, and outdated systems frustrate users, create resistance to change and erode trust between IT and the business. Social debt is often the fuel for technical debt, and persistent technical debt in turn breeds new social debt.
The whole structure, with every category and its sub-categories in each domain, is available as a single diagram on the page How it all fits together.
Example: technical debt drives social debt
Persistent technical debt in outdated systems frustrates users, creates resistance to change and weakens trust between the IT function and the business, that is user-satisfaction and reputation debt.
The thesis's municipal studies show that the debt is above all social: fragmented governance, procurement dependencies and organisational inertia drive it more than deficiencies in the code.
History of the concept: from technical to socio-technical debt
The debt metaphor was born in the world of programming but has over three decades grown into a way of describing the whole socio-technical system in which software is developed, maintained and used. The timeline summarises the development described in the thesis's introductory chapters (section 2.2), which culminates in the unifying concept of socio-technical debt.
-
1992
The metaphor is coined
Ward Cunningham describes ‘quick-and-dirty’ programming as a loan: a little debt speeds up development, provided it is paid back promptly with a rewrite.
‘Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. […] Every minute spent on not-quite-right code counts as interest on that debt.’
The metaphor gains power because it also helps non-technical decision-makers in finance and management understand the risks of poor practice. Lutz (1993) shows that the debt can also be strategically viable, like borrowing capital in the business world.
-
2003 and 2009
Interest, principal and Fowler's quadrant
Martin Fowler simplifies the metaphor to the choice between a ‘messy but quick’ and a ‘clean but time-consuming’ solution. Just like a loan, the debt demands interest payments in the form of extra effort in all future development, until the principal is paid down by refactoring. Fowler later distinguishes deliberate from inadvertent, and prudent from reckless, debt. The concept thereby becomes a shared language for developers, architects and managers.
-
2012–2013
Expansion and a warning against dilution
Kruchten et al. (2012) and Tom et al. (2013) expand technical debt to the architectural and process levels, but also note that inconsistent terminology risks weakening the concept's analytical precision.
-
2014 and 2018
Technology debt (TyD)
Magnusson and Bygstad define technology debt as ‘the accumulated obligation owned by the current CIO (debtor) to a future CIO (creditor), where previous decisions limit prospective decisions’. The debt does not arise in the code but between the artefacts, in paths and dependencies: a proprietary enterprise system allows rapid deployment but locks the organisation into costly upgrade cycles. Three main groups are described (organisation, users, technology) with subtypes such as competence, work-environment, user-satisfaction, reputation, infrastructure, shadow-IT and governance debt (Magnusson et al., 2018).
-
2015
Social debt
Tamburri et al. define social debt as ‘a cumulative and increasing cost in the current state of things, connected to invisible and negative effects within a development community’. It is the first distinct formulation of the idea that debt can reside in collaboration and relationships rather than in code.
-
2016
The research field agrees on a definition
Leading debt researchers meet at a seminar to harmonise the concept. The outcome (Avgeriou et al., 2016) defines technical debt as design or implementation constructs that are expedient in the short term but set up a technical context that can make future changes more costly or impossible, with impact limited to internal system qualities. Three key elements are highlighted: the debt (the suboptimal constructs), the interest (future extra effort) and the principal (the cost of removing the debt). It is this definition that delimits the technical domain in the register above.
-
2018
A taxonomy of 15 types, and digital debt (DD)
Rios et al. compile, in a tertiary study, a taxonomy of 15 sub-types of technical debt, from requirements and testing to documentation, process and people, while warning that the concept is being used as a ‘catch-all’ for any obstacle in development. The taxonomy has since been substantially extended and forms the backbone of appendix 1 of the thesis.
The same year, Rolland et al. define digital debt as ‘an organization's cumulative build-up of technical and informational obligations related to the maintenance and evolvability of its platform and infrastructure’. The concept shifts focus from individual technical flaws to the systemic outcome of postponed modernisation, and extends the metaphor to the information layer. Ernst et al. (2021) and Asatiani & Torell (2023) specify eight sub-categories, of which deployment, social and information debt are the most distinctive.
-
2021
AI-specific debts
Bogner et al. map technical debt in AI-based systems and describe four new types: AI configuration, AI data, AI model and AI ethics debt. The metaphor follows into a new generation of technology.
-
2023–2024
Non-technical debt (NTD)
Saeeda et al. define non-technical debt as the accumulation of suboptimal or immature decisions, compromises or workarounds in the non-technical aspects of development: poor communication, inefficient processes, misaligned teams, weak leadership. Five sub-categories are arranged (process, people, cultural, social and organisational debt), and Ahmad et al. (2024) add documentation debt. Non-technical debt often acts as an amplifier: when processes, structures or human factors fail, even well-built systems do not deliver value.
The overlaps now become clear: process debt appears in both the TD and NTD literature, cultural debt aligns closely with socio-technical debt, and documentation debt is recognised under all three rubrics. The field needs a framework that orders the categories without diluting the metaphor.
-
2023
Transparency debt in a municipal context
The thesis's first study (Persson et al., 2023) identifies transparency debt: closed code makes it hard to know what data is stored about citizens and which algorithms are used when cases are evaluated. The study of the building-permit systems of a Swedish municipality also shows that departments work in silos and that citizens have only a passive role as system users.
-
2024
Socio-technical debt (STeD) as a unifying concept
The debate on the metaphor's boundaries continues: one side holds that the expansion is necessary to capture the socio-technical reality (Ahmad & Al-Baik, 2024; Avgeriou et al., 2025), the other that the concept is groaning under ever more categories (Tom et al., 2013; Besker et al., 2016). Riquet et al. (2024) propose socio-technical debt as a unifying construct: organisations cannot meaningfully separate technical debt in artefacts from the organisational and social dynamics that shape development.
‘A phenomenon that occurs when past social and/or technical decisions lead to inefficiencies or increased risks in designing, building, maintaining, managing, or using software engineering artifacts. This, in turn, hampers an organization's ability to create value, achieve strategic goals, or pursue the best course of action.’
The debt has three defining characteristics: it is cumulative (the longer it remains, the higher the cost), it is costly to eliminate, and it is inevitable in practice since trade-offs and compromises are part of all development work.
-
2025
The thesis: the categories are sorted into two domains
Using Riquet's framework as a lens, the thesis arranges all previously articulated categories into two overarching domains: artefact-related debt (technical debt in code, architecture, databases and testing frameworks) and social-related debt (debt accumulated through social decisions about communication, governance and resource allocation). Categories previously counted as technical, such as requirements, process and AI ethics debt, are placed on the social side because their roots lie in social contexts. That is the classification reproduced in the register on this page.
The framework is then used as a diagnostic tool in five studies and 25 complementary expert interviews in the Swedish municipal sector. Nine problems driving the accumulation of debt are identified and mapped to design principles and architecture blueprints. The conclusion: in the municipalities, the debt is above all social. The classification is not complete, since the metaphor keeps evolving as new contexts and technologies emerge.
-
2026
The register is extended with post-thesis categories
A review of literature published after the thesis, and of a few older categories not included in figure 2, adds further categories to the register tagged ‘New’. On the social side these include consensus, team, management, compliance, knowledge and institutional debt; on the technical side dependency, pipeline, performance, accessibility, sustainability, explainability and semantic debt, as well as agentic technical debt. Several of them are arranged as sub-categories of others, which is stated on the respective card. At the same time, some of the thesis's original categories are arranged in the same way, for example database-design debt under database debt and shadow-IT debt under governance debt.
In a second round, reproducibility, data, ethical and prompt debt were added from recent software research, together with interoperability, system evolution and organic debt from Yang's taxonomy for systems engineering and acquisition.
In a third round, four social categories were added from research on AI-assisted development: intent, comprehension and epistemic debt, all closely related to cognitive debt, together with agentic literacy debt, which operates at the societal level. On the technical side, cost debt (token debt) was added, concerning the operating cost of systems built on large language models.
The four umbrella concepts
Before socio-technical debt was introduced, research had created several parallel umbrella concepts to distinguish between different layers and sources of debt. They do not replace technical debt in its traditional sense but complement it at different levels of abstraction, from code quality to organisational strategy. The register states for each category which of the concepts it was defined within.
-
TD
Technical debt
Debt in the software itself: code, design, architecture, testing, documentation. The harmonised definition (Avgeriou et al., 2016) limits the impact to the system's maintainability and evolvability. Rios et al. (2018) provide the taxonomy.
-
DD
Digital debt
An organisation's cumulative build-up of technical and informational obligations related to the maintenance and evolvability of its platform and infrastructure. An impediment to digital transformation that also covers the information layer.
-
TyD
Technology debt
Obligations arising from strategic, infrastructural, organisational and governance choices, often at executive level: procurement strategies, vendor dependencies and governance models that bind future decisions.
-
NTD
Non-technical debt
Suboptimal decisions, compromises and workarounds in the non-technical aspects of development: processes, people, culture, social relations and organisational structure. Often an amplifier of technical debt.
Sources
The register is based on appendices 1 and 2 and section 2.2 of the thesis Managing Socio-Technical Debt: Causes and Design-Science Solutions for Citizen-Centred Digital Public Services (University of Gothenburg, 2025). The category names are the established English terms from the literature; the Swedish names are my translations. The descriptions are summaries of the cited definitions. The works cited on this page are listed below.
- Ahmad, M. O., & Al-Baik, O. (2024). Beyond technical debt: Unravelling organisational debt concept. Proceedings of the 39th ACM/SIGAPP Symposium on Applied Computing, 802–809.
- Ahmad, M. O., & Gustavsson, T. (2022). The Pandora’s box of social, process, and people debts in software engineering. Journal of Software: Evolution and Process, 36(2), e2516.
- Ahmad, M. O., Gustavsson, T., Katin, A., Taušan, N., & Mandić, V. (2024). Non-technical aspects of technical debt in the context of large-scale agile development: A qualitative study. 50th Euromicro Conference on Software Engineering and Advanced Applications.
- Akbarinasaji, S., Bener, A. B., & Erdem, A. (2016). Measuring the principal of defect debt. 5th International Workshop on Realizing Artificial Intelligence Synergies in Software Engineering, 1–7.
- Al-Barak, M., & Bahsoon, R. (2016). Database design debts through examining schema evolution. IEEE 8th International Workshop on Managing Technical Debt, 17–23.
- Alves, N. S., Ribeiro, L. F., Caires, V., Mendes, T. S., & Spínola, R. O. (2014). Towards an ontology of terms on technical debt. 6th International Workshop on Managing Technical Debt, 1–7.
- Alves, N. S., Mendes, T. S., De Mendonça, M. G., Spínola, R. O., Shull, F., & Seaman, C. (2016). Identification and management of technical debt: A systematic mapping study. Information and Software Technology, 70, 100–121.
- Asatiani, A., & Torell, J. (2023). Balancing digital debt and digital options: Challenges of digital transformation at Green Cargo. Journal of Information Technology Teaching Cases, 13(2), 154–164.
- Avgeriou, P., Ernst, N. A., Nord, R. L., & Kruchten, P. (2016). Technical debt: Broadening perspectives. Report on the seventh workshop on managing technical debt (MTD 2015). ACM SIGSOFT Software Engineering Notes, 41(2), 38–41.
- Avgeriou, P., Ozkaya, I., Koziolek, H., Codabux, Z., & Ernst, N. (2025). Reframing technical debt (Dagstuhl Perspectives Workshop 24452). Dagstuhl Reports, 14(11), 16–39.
- Besker, T., Martini, A., & Bosch, J. (2016). A systematic literature review and a unified model of ATD. 42nd Euromicro Conference on Software Engineering and Advanced Applications, 189–197.
- Bogner, J., Verdecchia, R., & Gerostathopoulos, I. (2021). Characterizing technical debt and antipatterns in AI-based systems: A systematic mapping study. IEEE/ACM International Conference on Technical Debt, 64–73.
- Cunningham, W. (1992). The WyCash portfolio management system. Addendum to the Proceedings on Object-Oriented Programming Systems, Languages, and Applications, 29–30.
- Ernst, N., Kazman, R., & Delange, J. (2021). Technical debt in practice: How to find it and fix it. MIT Press.
- Fowler, M. (2003). Technical debt. martinfowler.com. Fowler, M. (2009). Technical debt quadrant. martinfowler.com.
- Hacks, S., Höfert, H., Salentin, J., Yeong, Y. C., & Lichter, H. (2019). Towards the definition of enterprise architecture debts. IEEE 23rd International Enterprise Distributed Object Computing Workshop, 9–16.
- Kruchten, P., Nord, R. L., & Ozkaya, I. (2012). Technical debt: From metaphor to theory and practice. IEEE Software, 29(6), 18–21.
- Larrucea, X., Santamaría, I., & Graña Romay, M. (2021). Towards a privacy debt. IET Software, 15(6), 453–463.
- Li, Z., Avgeriou, P., & Liang, P. (2015). A systematic mapping study on technical debt and its management. Journal of Systems and Software, 101, 193–220.
- Liu, J., Huang, Q., Xia, X., Shihab, E., Lo, D., & Li, S. (2020). Is using deep learning frameworks free? Characterizing technical debt in deep learning frameworks. ACM/IEEE 42nd International Conference on Software Engineering: Software Engineering in Society.
- Lutz, M. J. (1993). A maturing field on display at OOPSLA. IEEE Software, 10(1), 113–116.
- MacCormack, A., Baldwin, C., & Rusnak, J. (2012). Exploring the duality between product and organizational architectures: A test of the ”mirroring” hypothesis. Research Policy, 41(8), 1309–1324.
- Magnusson, J., & Bygstad, B. (2014). Technology debt: Toward a new theory of technology heritage. Proceedings of the Scandinavian Conference on Information Systems, 5–18.
- Magnusson, J., Juiz, C., Gómez, B., & Bermejo, B. (2018). Governing technology debt: Beyond technical debt. Proceedings of the 2018 International Conference on Technical Debt, 76–84.
- Marinescu, R. (2012). Assessing technical debt by identifying design flaws in software systems. IBM Journal of Research and Development, 56(5), 9:1–9:13.
- Martini, A., Besker, T., & Bosch, J. (2020). Process debt: A first exploration. 27th Asia-Pacific Software Engineering Conference, 316–325.
- Morgenthaler, J. D., Gridnev, M., Sauciuc, R., & Bhansali, S. (2012). Searching for build debt: Experiences managing technical debt at Google. 3rd International Workshop on Managing Technical Debt, 1–6.
- Persson, P. (2025). Managing Socio-Technical Debt: Causes and Design-Science Solutions for Citizen-Centred Digital Public Services. Doctoral thesis, University of Gothenburg.
- Persson, P., Zhang, Y., Asatiani, A., Lindman, J., & Rudmark, D. (2023). Technical debt in the municipality sector: The missing link with citizens and silofication. 14th Scandinavian Conference on Information Systems. (Publication I.)
- Rindell, K., Bernsmed, K., & Jaatun, M. G. (2019). Managing security in software: Or, how I learned to stop worrying and manage the security technical debt. 14th International Conference on Availability, Reliability and Security, 1–8.
- Rios, N., Mendonça Neto, M., & Spínola, R. (2018). A tertiary study on technical debt: Types, management strategies, research trends, and base information for practitioners. Information and Software Technology, 102, 117–145.
- Riquet, N., Devroey, X., & Vanderose, B. (2024). Debt stories: Capturing social and technical debt in the industry. 7th ACM/IEEE International Conference on Technical Debt, 40–44.
- Rodriguez, A., Gardey, J. C., Grigera, J., Rossi, G., & Garrido, A. (2023). UX debt in an agile development process: Evidence and characterization. Software Quality Journal, 31(4), 1467–1498.
- Rolland, K., Mathiassen, L., & Rai, A. (2018). Managing digital platforms in user organizations: The interactions between digital options and digital debt. Information Systems Research, 29(2), 419–443.
- Rosser, L. A., & Norton, J. H. (2021). A systems perspective on technical debt. 2021 IEEE Aerospace Conference, 1–10.
- Saeeda, H., Ahmad, M. O., & Gustavsson, T. (2023). Multivocal literature review on non-technical debt in software development: An exploratory study. 19th International Conference on Evaluation of Novel Approaches to Software Engineering.
- Samarthyam, G., Muralidharan, M., & Anna, R. K. (2017). Understanding test debt. In Trends in Software Testing, 1–17. Springer.
- Silva, M. C., Valente, M. T., & Terra, R. (2016). Does technical debt lead to the rejection of pull requests? XII Brazilian Symposium on Information Systems.
- Störrle, H., & Ciolkowski, M. (2019). Stepping away from the lamppost: Domain-level technical debt. 45th Euromicro Conference on Software Engineering and Advanced Applications, 325–332.
- Tamburri, D. A., Kruchten, P., Lago, P., & van Vliet, H. (2015). Social debt in software engineering: Insights from industry. Journal of Internet Services and Applications, 6(1), 10.
- Tom, E., Aurum, A., & Vidgen, R. (2013). An exploration of technical debt. Journal of Systems and Software, 86(6), 1498–1516.
- Wiklund, K., Eldh, S., Sundmark, D., & Lundqvist, K. (2012). Technical debt in test automation. IEEE 5th International Conference on Software Testing, Verification and Validation, 887–892.
- Wolfart, D., Assunção, W. K. G., & Martinez, J. (2021). Variability debt: Characterization, causes and consequences. XX Brazilian Symposium on Software Quality, 1–10.
- Zazworka, N., Vetro, A., Izurieta, C., Wong, S., Cai, Y., Seaman, C., & Shull, F. (2014). Comparing four approaches for technical debt identification. Software Quality Journal, 22(3), 403–426.
Sources for categories added after the thesis
References for the categories added after the thesis.
- Ahmad, M. O. (2026). Comprehension debt in GenAI-assisted software engineering projects. International Conference on Evaluation and Assessment in Software Engineering (EASE 2026). arXiv:2604.13277.
- Aljohani, A., & Do, H. (2025). PromptDebt: A comprehensive study of technical debt across LLM projects. Proceedings of the 29th International Conference on Evaluation and Assessment in Software Engineering (EASE '25). ACM. https://doi.org/10.1145/3756681.3756976
- Admile, A., Choudhari, M., Kakade, A., Bidve, O., Kulkarni, D., Patil, P., & Jadhav, A. (2025). CodeGuardian: A multi-agent RAG framework for collaborative code understanding optimization and software engineering.
- Arpteg, A., Brinne, B., Crnkovic-Friis, L., & Bosch, J. (2018). Software engineering challenges of deep learning. 2018 44th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), Prague, Czech Republic, 50–59.
- Brahmi, Z., Ouni, A., Sayagh, M., & Saied, M. A. (2026). Characterizing self-admitted technical debt generated by AI coding agents. ACM.
- Butt, T. A., Iqbal, M., & Arshad, N. (2025). From policy to pipeline: A governance framework for AI development and operations pipelines. IEEE Access.
- Carvalho, L., Biazotto, J. P., Feitosa, D., et al. (2026). Technical debt management in continuous software engineering: State of the art and research agenda. Journal of Software: Evolution and Process.
- Costa, F. F. (2026). The deployment wall: A diagnostic framework and instrument for enterprise AI in the deployment era. arXiv preprint arXiv:2607.29089.
- Couto, M., Maia, D., Saraiva, J., & Pereira, R. (2020). On energy debt. Technical Debt Workshop.
- Ehsani, R., Rawal, S., Cai, Y., & Chatterjee, P. (2026). Faster code, deeper debt? A multivocal literature review on technical debt and its early signs in LLM-assisted software development. ACM Transactions on Software Engineering and Methodology. arXiv:2606.14796.
- Dayan-Akman, P., Özcan-Top, Ö., & Temizel, T. T. (2025). People and management debt in ML-integrated software projects: Structuring industry insights. IEEE Access.
- de Souza Santos, R., Fronchetti, F., Freire, S., et al. (2025). Software fairness debt: Building a research agenda for addressing bias in AI systems. ACM Transactions on Software Engineering and Methodology.
- Foidl, H., Felderer, M., & Biffl, S. (2019). Technical debt in data-intensive software systems. 2019 45th Euromicro Conference on Software Engineering and Advanced Applications (SEAA). arXiv:1905.13455.
- Fırat, M. (2026). Cognitive debt in the age of generative AI: A reflective review with an illustrative netnographic case. SSRN.
- Gandikota, L. R., Jegathesan, V., et al. (2026). Quantifying explainability debt in production AI systems: A metric framework for responsible deployment. IEEE.
- Hassan, Z., Treude, C., Norrish, M., Williams, G., & Potanin, A. (2024). Reproducibility debt: Challenges and future pathways. Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering (FSE Companion '24).
- Hassan, Z., Treude, C., Norrish, M., Williams, G., & Potanin, A. (2025). Characterising reproducibility debt in scientific software: A systematic literature review. Journal of Systems and Software, 222, 112327.
- Indika, A., Kazman, R., & Peruma, A. (2026). Practitioner views on mobile app accessibility: Practices and challenges. arXiv:2601.14131.
- Kapiyasheva, D., Özcan-Top, Ö., et al. (2026). A process-centric mapping of non-technical debt instances to ISO/IEC 5338 in AI-enabled projects. Software Quality Journal.
- Lavallée, M., Beaulieu, G., & Famelis, M. (2017). Supporting consensus-based software development: A vision paper. MoDELS Satellite Events.
- Lazar, J., Shachmut, K., Drummond, A., Wyant, J., Rosenblum, H., & Eng, K. (2026). A born-accessible approach to technology design. Interactions, 33(5), 26–31.
- Mukherjee, S. (2026). A formal model for ontology-driven data architecture: Complexity analysis, semantic grounding and multi-agent coordination. 2026 IEEE 3rd International Conference on Big Data Science and Engineering (ICBDSE), Kunming, China, 1–7.
- Nama, R. (2026). Agentic literacy debt: A structural problem the AI literacy field has not yet named. AI and Ethics. Springer. arXiv:2605.27396.
- Norling, K. (2024). The Consensing Approach to Strategizing: The Dynamics of Dialogue in Public Sector Digital Transformation. Doctoral dissertation, University of Gothenburg. GUPEA.
- Ohno, K., & Hashimoto, S. (2026). Bridging the “ten walls” of Japanese healthcare data: A comprehensive semantic mapping … and institutional gap analysis. medRxiv.
- Ojameruaye, B., Bahsoon, R., & Duboc, L. (2016). Sustainability debt: A portfolio-based approach for evaluating sustainability requirements in architectures. Proceedings of the 38th ICSE Companion.
- Petrozzino, C. (2021). Who pays for ethical debt in AI? AI and Ethics, 1, 205–208.
- Ramamoorti, S., Boumediene, S., Doty, M., Koritala, B., Masten, L. B., & Miller, R. (2026). The intelligence may be artificial but the liability is real: The golden age of AI and the three hidden risks. Journal of Information Technology Case and Application Research, 1–7.
- Sankaranarayanan, S. (2026). Mitigating “epistemic debt” in generative AI-scaffolded novice programming using metacognitive scripts. arXiv:2602.20206.
- Sculley, D., Holt, G., Golovin, D., et al. (2015). Hidden technical debt in machine learning systems. Advances in Neural Information Processing Systems 28.
- Storey, M.-A. (2026). From technical debt to cognitive and intent debt: Rethinking software health in the age of AI. ACM Queue. arXiv:2603.22106.
- The epistemic debt of generative AI. (2026). Nature Machine Intelligence. https://www.nature.com/articles/s42256-026-01294-w
- Token debt is the new technical debt. (n.d.). HackerNoon. https://hackernoon.com/token-debt-is-the-new-technical-debt
- Tsai, S. (2026). Ghost intent: An effect of traceability collapse in GenAI-assisted SDLCs (March 5, 2026). Available at SSRN.
- Tukur, M., Adeyemo, H. B., Chen, T., Ali, N., Zarrad, A., et al. (2026). From AI technical debt to agentic technical debt: A systematic mapping of root causes and manifestations in agentic AI systems. arXiv:2608.01001.
- Tukur, M., Adeyemo, H. B., Chen, T., Ali, N., Zarrad, A., Kazman, R., Agus, M., & Bahsoon, R. (2026). On AI safety and security technical debt in engineering AI-enabled systems. arXiv:2607.23365.
- Yang, Y., Verma, D., & Anton, P. (2023). Technical debt in the engineering of complex systems. Systems Engineering. https://doi.org/10.1002/sys.21677
A living register
The debt metaphor remains a popular and evolving tool, and new categories are continually proposed as researchers apply it to new contexts. The register reflects the state of the thesis and will be extended as new categories become established in the literature or in practice.
Want to use the register to map the debt in your own organisation? See services for technical-debt analysis and advisory work (in Swedish).