Freeze and inventory
Record deployments, repositories, branches, models, prompts, data, evaluations, infrastructure, vendors, accounts, costs, incidents, decisions, and current owners.
Enterprise AI project recovery
How should an enterprise diagnose and recover a stalled AI project?
Do not begin with a rewrite. Freeze the current state, preserve evidence, reconstruct the intended operating decision, and identify the smallest constraint that prevents value or safe operation. Then choose continue, narrow, redesign, transfer, or stop with a signed evidence record.
By Onyx Devs Lab · Published · Updated
PreserveState, evidence, assets, access, and obligations
DiagnoseValue, workflow, data, system, control, ownership
DecideContinue, narrow, redesign, transfer, or stop
Stabilise before changing the system
Recovery becomes harder when teams overwrite evidence, rotate people, or add features while the failure is still undefined.
Protect operations and access
Limit risky actions, preserve logs and records, rotate or revoke uncertain credentials, maintain necessary service, and document legal, data, supplier, and support obligations.
Reconstruct the claim
State the original user, workflow, baseline, promised outcome, scope, acceptance, authority, budget, timeline, and what evidence actually exists.
Diagnose the binding constraint
Symptoms such as poor answers or delays may originate in a different layer than the proposed fix.
Value and workflow
Check whether the problem is valuable, frequent, owned, adopted, and reachable through the intervention; identify workarounds and review burden.
Data and evaluation
Check source access, meaning, coverage, quality, labels, leakage, test representativeness, metric definitions, thresholds, and whether results reproduce.
System and governance
Check architecture, integration, identity, permissions, reliability, observability, recovery, cost, team capability, decision rights, vendor dependency, and exit.
How to run a recovery review
Create a verified state snapshot
Preserve code, configuration, data and test versions, deployed behaviour, logs, costs, access, contracts, decisions, and unresolved incidents.
Run an evidence review
Separate observed facts, provider claims, assumptions, missing evidence, and disagreements across business, product, engineering, data, security, and operations.
Test the smallest recovery hypothesis
Use a bounded experiment to determine whether one constraint can be removed without committing to a full rebuild.
Sign the disposition
Choose continue, narrow, redesign, transfer, pause, or stop; name owner, scope, evidence gate, budget, residual risk, asset handover, and review date.
Frequently asked questions
When should the system be rewritten?
Only when evidence shows the architecture blocks the required outcome or control and a migration path is more credible than targeted repair. A rewrite is not a substitute for diagnosis.
Can a new vendor assess the previous vendor?
Yes, but conflicts and evidence boundaries should be explicit. Give the assessor access to artefacts and stakeholders, and require reproducible findings rather than sales claims.
How do we distinguish a failed project from a failed hypothesis?
A well-run project may correctly prove that an intervention is not viable. Failure is more often the absence of a clear question, evidence, control, ownership, or decision after spending.
Start with one concrete operating problem.
We will first clarify the workflow, evidence, data boundary, and outcome standard before recommending the next step.
Contact Onyx