01 / Rescue
AI project rescue
A clear route from stalled prototype to dependable production service.
The work
What this engagement is designed to do.
We take over AI and automation systems that have lost momentum, failed review, or become too risky to change. We establish what exists, make the critical decisions visible, and turn the viable parts into a controlled delivery plan.
Good fit
When to bring us in.
- 01
A supplier delivered a convincing demonstration but not a production-ready system.
- 02
The original team has moved on and ownership is unclear.
- 03
Security, architecture, or governance review has blocked release.
- 04
The system is live, but its decisions cannot be reconstructed or defended.
Deliverables
Concrete outputs, tied to ownership.
The exact scope is agreed before delivery. These are the outputs that normally make the engagement useful after it ends.
- Deliverable 01Technical and operational baseline
- Deliverable 02Prioritised defect and risk schedule
- Deliverable 03Target architecture and remediation plan
- Deliverable 04Costed delivery scope with acceptance criteria
- Deliverable 05Implementation, handover, and support options
Expected outcomes
What should be different.
- 01
Continue with a bounded remediation plan
- 02
Rebuild only the parts that cannot be made safe
- 03
Stop before more budget is committed
Typical defect schedule
Ten recurring reasons an AI system is not ready to operate.
This is the complete working frame, not a claim about any one client. An assessment replaces these examples with referenced findings from the system in front of us.
| Reference | Observed defect | Severity |
|---|---|---|
| D-01 | The system authenticates as a named person, invalidating both its audit trail and its access review. | Critical |
| D-02 | Tool and API permissions are unbounded, with no recorded definition of what the system is allowed to do. | Critical |
| D-03 | Production data is accepted without a documented source, retention rule, or boundary for sensitive information. | Critical |
| D-04 | There is no evaluation set, so changes cannot be compared and releases cannot be defended. | Major |
| D-05 | Model inputs and outputs are not logged, leaving incidents and customer complaints impossible to investigate. | Major |
| D-06 | Consequential actions can run without an approval step, confidence threshold, or route to a human operator. | Critical |
| D-07 | Prompt, model, and dependency changes are not versioned together, so behaviour cannot be reproduced or rolled back. | Major |
| D-08 | Development and production share data, credentials, or configuration, allowing test activity to affect the live service. | Critical |
| D-09 | Retries are not idempotent, so a timeout can repeat an external action without the operator knowing. | Major |
| D-10 | No named owner, runbook, service level, or cost limit exists for operating the system after release. | Minor |
Not ready for the full assessment
Triage
£950, one working day. Read-only access, verbal findings on a call, plus a one-page written summary.
Not the full assessment: no defect schedule and no remediation quote. It is for deciding whether a full assessment is worth commissioning.
Bring us the difficult part
We can define the right starting point together.
Send us the context, the current constraint, and the decision you need to make.
Start a conversation