DEFINE THE DECISION
“Repair or rebuild” may hide several different choices.
The practical options may include clarification, stabilisation, targeted repair, partial replacement, complete rebuild, migration, temporary containment or deferral.
Define the product outcome and the decision horizon before evaluating the implementation. A short-term demonstration and a maintainable Production system require different evidence.
ESTABLISH EVIDENCE QUALITY
Know which conclusions are observed and which are assumed.
List the sources available: product behaviour, code context, tests, architecture, deployment records, issue history, provider configuration, user feedback and stakeholder claims.
Assign confidence and record missing evidence. A recommendation based only on screenshots or a generated summary should be qualified accordingly.
ASSESS THE PROJECT DIMENSIONS
Evaluate more than code quality.
- Product
- Does the software solve the right problem for the intended user?
- Architecture
- Can the current structure support the required change and operating model?
- Implementation
- Which defects, dependencies and technical debt are critical, recoverable or cosmetic?
- Operations
- Can the project be built, tested, deployed, observed, recovered and maintained responsibly?
- Ownership
- Are repositories, providers, domains, data, credentials and operational assets under authorised control?
- Evidence
- Can important claims be reproduced or verified?
DECISION FRAMEWORK
Evidence quality and decision balance
Evidence quality
- Unverified claim
- Supplied record
- Observed behaviour
- Reproduced result
- Direct technical evidence
Decision dimensions
- Product fit
- Architecture
- Implementation
- Operations
- Ownership
- Evidence
- Risk
- Recoverability
Recoverable debt and critical failure
Recoverable debt
The product and architecture remain sound, failures are bounded and valuable behaviour can be reproduced.
Critical failure
The required outcome is blocked by structural failure, irrecoverable ownership or evidence that cannot be reproduced.
Compare the options
| Option | Best fit | Principal risk |
|---|---|---|
| Clarify | The project state is too uncertain for a technical commitment | Delay without resolving the missing evidence |
| Stabilise | The system has value but is operationally unreliable | Treating stabilisation as feature delivery |
| Repair | Failures are bounded and the architecture remains viable | Expanding the repair beyond the agreed boundary |
| Partial rebuild | A specific subsystem blocks progress | Creating an unclear boundary between old and new |
| Full rebuild | Product intent is valid but the implementation foundation is unsuitable | Recreating old assumptions and losing proven behaviour |
| Defer or stop | Evidence, ownership or economics do not support responsible work | Avoiding a decision that later becomes more expensive |
RECOVERABLE DEBT OR CRITICAL FAILURE
Not every weakness justifies replacement.
A rebuild becomes more credible when the current architecture blocks the required outcome, critical dependencies cannot be supported, ownership is irrecoverable, evidence cannot be reproduced or repair would preserve the same structural failure.
Repair or stabilisation may be stronger when the product and architecture remain sound, failures are bounded and the current system contains valuable, reproducible behaviour.
COMPARE THE OPTIONS
Compare the options
RECORD THE DECISION
Preserve the rationale, confidence and conditions.
Record the recommended option, rejected alternatives, evidence, risks, assumptions, missing information and conditions that would change the decision.
The decision should lead to a roadmap and, where appropriate, a bounded Build Specification with acceptance criteria and ownership targets.
HOW AIRCHOR FITS
How Airchor fits
The current Airchor foundation structures supplied existing-project context into assessment, risk, recovery and handoff outputs. The Control Plane direction extends this into one Project Model, visible Work Items, technical evidence, execution and independent verification according to the roadmap.