Quality or Health Scan¶
Diagnostic scan — instantiates Technical Debt Containment
An automated pass over the system that surfaces candidate debt — smells, stale records, risky dependencies, manual workarounds — and measures its drag, feeding provisional items into the register for human triage.
Much debt never gets logged simply because no one noticed it. Quality or Health Scan is the automated detector that closes that gap: a repeatable pass over the system that surfaces candidate debt at scale — code smells, stale records, out-of-date dependencies, configuration drift, undocumented workarounds — and attaches a rough measure of the drag each imposes. Its defining move is high-recall automated surfacing with judgment deferred: it finds and quantifies far more than a human sweep could, but it deliberately stops short of deciding what truly counts as debt, opening provisional entries for humans to triage rather than pronouncing verdicts. It generates signal and candidates; it does not rank, display trends, or rule on what is real. In the archetype it is the intake sensor that keeps invisible debt from staying invisible.
Example¶
A DevSecOps team runs a nightly scan across a company's cloud services. In one pass it flags dozens of dependencies past their end-of-life date, a handful of services carrying hardcoded credentials (a convenience workaround someone meant to remove), and a batch of infrastructure-as-code configurations that have drifted from the approved baseline. For each finding it records a drag proxy — how many known vulnerabilities the outdated dependency exposes, how long a config has been drifting — and opens provisional register entries grouped by cluster. Debt that would otherwise have surfaced only at the next annual audit is now visible continuously and pre-staged as candidate items. But the scan does not declare any of it "debt to fix": a human still triages the flags, discarding the false positives and the risks the team has consciously accepted, before anything becomes a governed item.
How it works¶
The scan applies a set of rules or heuristics across the system, emits findings, attaches a measurable drag proxy to each, and writes them as provisional candidate entries pending human triage. Its craft is the recall/precision balance — it aims to miss little, accepting that some flags will be noise, because a missed debt stays invisible while a false positive merely costs a triage glance. What distinguishes it from the dashboard is direction and timing: the scan looks outward at the system to discover new candidates at a point in time, whereas the dashboard looks inward at already-known debt to trend its cost. And what distinguishes it from the decision record is authority: the scan proposes, but the human ruling that a candidate is genuinely debt lives elsewhere.
Tuning parameters¶
- Rule set and sensitivity — how many patterns are checked and how aggressively. High sensitivity maximizes recall but floods triage with false positives.
- Scan frequency — continuous, nightly, or per-release. More frequent scanning catches drift early but generates more findings to process.
- Drag proxy — what stand-in measures the cost of each finding (vulnerability count, age, complexity). A good proxy focuses attention; a poor one misdirects it.
- Auto-triage thresholds — which findings auto-open a candidate entry versus which are held. Tighter thresholds cut noise but risk suppressing real debt.
- Suppression list — how accepted or known-benign findings are muted so they stop re-surfacing. Essential against fatigue, dangerous if it hides real risk.
When it helps, and when it misleads¶
Its strength is scale and continuity: it finds the invisible debt no manual review has time for, and it keeps finding it between audits. That makes it the natural feeder for the register and the raw source for the dashboard's trends.
Its failure mode is alert fatigue and mistaking flags for facts. A scan tuned too hot drowns the real signal in false positives until people ignore all of it, and a team that treats a green scan as proof of health forgets that the scan detects surface indicators, not debt itself — the archetype is explicit that human judgment still defines what counts. The apt real concept is the code smell (Kent Beck and Martin Fowler's term): a surface symptom that suggests deeper trouble worth investigating, not a defect proven by its presence.[n1] The classic misuse is gaming the scan — suppressing or reformatting findings to turn the report green without touching the underlying debt. The guarding discipline is to keep the scan high-recall but route every finding through human triage, and to actively tune down false positives so the signal stays trusted.
How it implements the components¶
interest_or_drag_signal— the scan measures a drag proxy for each finding (exposure, age, complexity), translating vague "possible debt" into quantified signal.debt_register— it auto-opens provisional candidate entries from its findings, feeding the inventory that a human then curates.
The scan detects raw signals but does not synthesize them — debt_heatmap and debt_service_ratio are the Debt-Service Dashboard, its nearest twin (the scan finds candidates; the dashboard trends confirmed cost) — and it flags candidates without ruling on them: debt_definition_boundary, the judgment of what actually counts as debt, is the Architecture or Process Decision Record and human triage.
Related¶
- Instantiates: Technical Debt Containment — the scan is the automated sensor that surfaces candidate debt for governance.
- Sibling mechanisms: Technical Debt Register · Debt Severity Rubric · Debt Budget Review · Debt-Service Dashboard · Architecture or Process Decision Record · Repayment Reserve · Sunset or Replacement Plan · Exception Expiry Date · Refactoring or Cleanup Sprint
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Quality or Health Scan operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it an automated pass over the system that surfaces candidate debt — smells, stale records, risky dependencies, manual workarounds — and measures its drag, feeding provisional items into the register for human triage.
Independent corroboration: The frozen evidence defines Quality or Health Scan as 'An automated pass over the system that surfaces candidate debt — smells, stale records, risky dependencies, manual workarounds — and measures its drag, feeding provisional items into the register for human triage', so its operative form is Assessment, Review & Assurance.
Nearest alternative: Monitoring, Sensing & Alerting — Quality or Health Scan includes features of ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response, but its defining operation is a bounded evaluation of existing evidence or work that produces a finding or disposition.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Automated scans for code smells, stale records, risky dependencies, and workarounds arise in software maintenance and static analysis.
Related originating lineages:
- Engineering & Design — Condition monitoring and preventive inspection supplied an older asset-health analogy.
- Organizational & Management Science — Technical-debt registers and human triage materially shape prioritization and ownership.
Review resolution: Both blind reviewers agree on computer_science as the primary origin. Explicit reconciliation resolves alternate_origin_disagreement, origin_mode_disagreement, encyclopedia_synthesis_disagreement. The merged alternate lineages retain only domains the reviewers identified as materially formative; domain_reach=specialized records later applicability separately from origin breadth.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A code smell — a term associated with Kent Beck and popularized by Martin Fowler — is a surface characteristic of code that hints at a deeper design problem without being a bug in itself. It captures exactly the epistemic status of a scan's output: an indicator worth investigating, not a proven defect, which is why scan findings require human triage before they become governed debt. ↩