Technical debt describes the future cost of choices embedded in a system. Assertion debt describes the future cost of claims that were accepted before their evidence, scope, version, environment, and reviewer were resolved.
A build can pass while the intended user cannot complete the task. A platform comparison can look rigorous while its criteria changed after a preferred option emerged. A pilot can report success while identity, data, support, cost, and operating ownership remain outside the demonstration.
None of those statements is necessarily false. The debt appears because the record is too weak to determine what is true, under which conditions, and who accepted the remaining uncertainty.
Why it accumulates
Output scaled faster than verification.
AI-assisted work reduces the time required to create plans, code, evaluations, summaries, test cases, architecture diagrams, and status reports. The cost of checking whether those artifacts represent the deployed outcome has not fallen at the same rate.
That asymmetry rewards teams for producing convincing records of activity. It does not automatically create a record that can support a funding, release, risk, or operating decision.
Decision debt
The recommendation exists, but the criteria, weights, assumptions, alternatives, and dissenting considerations cannot be reconstructed.
Decision framework, evidence ledger, assumptions register, and signed decision record.
Delivery debt
The team can show activity, code, demonstrations, or generated reports, but cannot resolve those claims to the version and environment a user receives.
Outcome contract, version record, quality gates, exceptions, release evidence, and deployed verification.
Operating debt
A capability is released without a durable account of ownership, monitoring, support, cost, change, escalation, and rollback.
Operating owner, monitored conditions, response path, cost attribution, change record, and review date.
Why pilots stall
A demonstration proves the demonstration.
Pilots become difficult to scale when the conditions that made the demonstration possible are not connected to the conditions required for production use. The missing work often appears after enthusiasm has already become a commitment.
What the pilot can show
- A model or workflow can perform a bounded task
- A chosen data sample can support a useful answer
- A small group can complete a designed scenario
- A technical pattern can be implemented in one environment
What production still has to resolve
- Identity, permissions, privacy, retention, and audit
- Source quality, lineage, freshness, and exception handling
- Support, monitoring, cost, change, and rollback ownership
- The real user outcome under normal operating conditions
The right pilot does not avoid these questions. It names which questions it will answer, which remain outside scope, and what evidence is required before the next commitment.
Evidence architecture
Connect the claim to the decision it is meant to support.
Evidence architecture is the designed path from an assertion to the record that can confirm, qualify, or reject it. The path must survive handoff, version change, environment change, and review by someone who was not present when the work was produced.
- 01
Claim
State the decision or outcome in language that can be challenged.
- 02
Source
Name the primary record, observation, test, or operational measure that can answer it.
- 03
Threshold
Write the acceptance condition before the work is assessed against it.
- 04
Reviewer
Assign the person or role accountable for judging the evidence.
- 05
Decision
Record proceed, revise, return, accept an exception, or stop.
- 06
Follow-up
Set the next owner, action, and review point so the record remains usable.
The evidence may be a primary document, system record, evaluation result, direct observation, operational measure, or an agreed combination. Its value comes from its ability to answer the decision, not from how easily it can be generated.
The gates
Write the decision conditions before the work is judged.
Gates prevent the evidence standard from moving silently after a result is known. A gate names the question, evidence, reviewer, possible decisions, and treatment of exceptions. New information may justify a change, but the change and rationale remain visible.
Decision gate
Is the problem, owner, value case, constraint set, and decision criterion clear enough to fund work?
Build gate
Does the working slice satisfy the written behavioral, security, data, and integration conditions?
Release gate
Can the capability enter the target environment with the required identity, monitoring, support, and rollback path?
Outcome gate
Can the intended user complete the target task in the environment they actually receive?
What we publish
Publish enough of the record for the decision to be challenged.
Publishing does not mean exposing confidential data, private client material, security details, or raw internal discussion. It means preserving the decision record in a form that allows the relevant stakeholders to see what was asserted, what evidence was used, what remained unresolved, and who accepted the next step.
- The assertion or intended outcome
- The evidence source and acceptance condition
- The accountable reviewer and decision
- Exceptions, dissent, and unresolved constraints
- The exact version and environment under review
- The next owner, action, and review date
Exception record
Passing evidence with a known limitation is not the same as hiding the limitation.
An exception should name the affected condition, rationale, risk owner, compensating action, expiry or review point, and the decision it changes. An exception without an owner or review point is simply deferred uncertainty.
Operating checklist
Seven questions before accepting the next AI claim.
- 01
Can the decision be reconstructed by someone who was not in the room?
- 02
Can each material claim be resolved to a primary record or direct observation?
- 03
Were acceptance conditions written before the work was judged?
- 04
Does the evidence identify the exact version and target environment?
- 05
Are exceptions visible, owned, time-bound, and connected to a decision?
- 06
Can the intended user outcome be checked after deployment?
- 07
Are monitoring, support, cost, change, and rollback responsibilities named?
Assertion debt cannot be reduced by adding more confident reporting. It is reduced by making evidence, decisions, exceptions, and ownership part of the delivery system itself.