Service
AI strategy & discovery
A short, evidence-led piece of work that tells you what is feasible on your data and your infrastructure, what it will cost, and what you should not attempt.
Discovery done properly is mostly subtraction. Of the twenty candidate use cases an organisation arrives with, a handful are feasible now, several are feasible after a data problem is fixed, and the rest should not be attempted with current technology.
We look at the data as it actually is rather than as documented, classify the risk against the frameworks your regulator cares about, and produce a roadmap with costs and dependencies rather than a maturity curve.
What you get
Named artefacts, not a slide pack. Each one is a thing your team can open, run, or hand to an auditor.
| Artefact | What it contains |
|---|---|
| Opportunity register | Candidate use cases scored on value, feasibility, data readiness and regulatory exposure, with the reasoning recorded. |
| Data readiness assessment | What exists, what is accessible, what is permitted, and what would have to be fixed first, based on inspection, not interviews alone. |
| Risk classification | Each candidate mapped against the obligations that plausibly apply, with the uncertainty stated. |
| Build / buy / adapt analysis | Where an existing product is the better answer, including where it is a competitor to something we would otherwise build. |
| Costed roadmap | Sequenced work with hardware, effort and dependency estimates, and explicit decision points to stop. |
How it runs
01 · 1 week
Scoping
Stakeholders, constraints, and what a useful answer would look like.
02 · 2–3 weeks
Inspection
Data, infrastructure and process, examined directly rather than described.
03 · 1–2 weeks
Assessment
Feasibility, risk classification, and where relevant a technical spike to settle a genuine unknown.
04 · 1 week
Report
Written findings and a working session with the people who will act on them.
What we use
Chosen per engagement against your constraints. We have no reseller relationships and no incentive to recommend one of these over another.
Assessment
Governance frameworks
What we do not do
Knowing where our usefulness stops saves everyone a procurement cycle.
- We do not produce maturity models, capability heat maps, or strategy documents with no engineering content.
- We do not recommend ourselves by default. Several discovery engagements have concluded that the client should buy a product or do nothing yet.
- We do not estimate benefits we cannot evidence. Where a number would be a guess, we describe the measurement method instead.
Questions we are asked
How is this different from a consultancy assessment?
It is done by the engineers who would build the thing, it inspects systems directly rather than relying on interviews, and it includes technical spikes where a genuine unknown blocks a decision. The output is a costed roadmap with stopping points, not a maturity curve.
Will you tell us not to do it?
Regularly. The most valuable discovery output we have produced was a recommendation to fix a data pipeline for six months before attempting anything model-related.
Do we have to continue with you afterwards?
No, and the report is written to be usable by whoever delivers the work. Where a product would serve you better than a build, the report says so by name.
Start with the constraint.
Most of these projects are shaped by what you cannot do rather than what you want. Data that cannot leave the estate, a model you cannot host with a third party, a decision somebody has to justify to a regulator. Tell us yours and we will say honestly whether we can work inside it.