Two kinds of debt. One is invisible. Both compound.
The first kind is accidental. An AI agent makes a structural decision without awareness of the constraint it violated. The engineer who submitted the PR did not know about the ADR. No one checked. The drift entered the system silently. This is architectural drift — and a Continuous Design Audit gate eliminates it.
The second kind is intentional. The sprint is two days from the release date. The right architectural solution takes three more days. Someone — an engineer, a lead, an architect — makes a call: ship now, clean up later. The PR merges. A comment says “tech debt — revisit.” The release ships.
The comment is not a record. It has no owner. It does not specify what was violated. It does not state the known risk. “Clean up later” is not a commitment with a date or a person attached to it. The debt is real, the decision was deliberate, and the system that produced it has no memory of either.
What a debt acceptance record actually requires
A decision to accept architectural debt is a design decision. It has the same requirements as any other design decision: it needs to be recorded, attributed, and traceable. Without those three properties, the decision is not debt management. It is deferred blame allocation.
The specific Steering artifact — ADR, Policy, Compliance constraint — that the accepted deviation contradicts. Not a general description. The actual record, referenced.
A named person who made the judgment call and owns the consequence. Not a team. Not a process. A human decision-maker with accountability.
The stated justification: release date, resource constraint, known limitation. The reason the trade-off was deemed worth making at this point in time.
The anticipated consequence if the debt is not resolved: the service area at risk, the scenario under which the violation becomes an incident, the security or stability implication.
How rkito makes intentional debt a first-class record
When a CDA gate surfaces a Steering violation, the default path is to block the PR until the violation is resolved. But architectural practice is not binary. Some violations are worth blocking. Some represent a legitimate trade-off that an architect can evaluate and accept — with their name on the decision.
In rkito, an architect can approve a CDA finding rather than require remediation. That approval is not a workaround. It is a formal debt acceptance record, written into the Architecture Ledger:
This record is not documentation for its own sake. It is the answer to three questions that currently have no answer in any engineering organisation:
- —Who made this decision and when?
- —What was the stated justification at the time it was made?
- —What is the current status of the commitment to resolve it?
The cost accumulation problem
Every open debt acceptance record is a known risk that was deferred. Some are resolved in the next sprint. Most are not — because “clean up later” competes with feature delivery for the same sprint capacity, and delivery wins.
Without a register, you do not know how many open debt records exist. You do not know which ones are in the highest-risk service areas. You do not know which records are six months old and were never revisited. You cannot correlate a production incident to a specific approval made under sprint pressure two quarters ago.
The Architecture Ledger tracks approved exceptions as first-class entries alongside the system topology. Open debt is visible: by service area, by age, by the Steering artifact violated, by the person who approved it. The cost of accumulation is no longer invisible — it is a metric.
How many approved exceptions are currently unresolved — across all services, all pillars, all teams.
Which open records are oldest. The records that were approved 'temporarily' and never revisited are the highest-risk entries in the Ledger.
The rate at which intentional debt is being added versus resolved. A rising rate without resolution is an accelerating risk profile.
When a production incident occurs, whether it traces back to an open debt acceptance record — turning post-mortem archaeology into a lookup.
Accountability is not blame. It is traceability.
The architect who approved the exception in sprint 14 made a legitimate judgment call under real constraints. The record does not exist to assign fault. It exists so that six months later, when the consequence arrives, the post-mortem does not begin with “nobody knows who decided this.”
Traceability enables good decisions. When an architect knows their approval creates a named, time-stamped record that persists in the Architecture Ledger until the debt is resolved, they evaluate trade-offs more deliberately. When a team knows their “temporary” solution is an open record with their lead’s name on it, the conversation about resolution has a different character.
The record is not a punishment. It is the memory that makes architectural accountability possible — at the pace the system is now changing.
Every “we’ll clean this up later” is a decision. It deserves the same record as any other architectural decision — a name, a date, a stated reason, and a place in the system’s memory that outlasts the sprint it was made in.