How we work
Frame, Prove, Build, Hand over
Our engagements run in four phases, with the exit criteria agreed at the outset rather than negotiated at the end. Defining the handover in advance has a direct bearing on how the preceding three phases are designed and delivered.
01 · 1–2 weeks
Frame
Establish what is actually constrained, what success would look like, and whether we should proceed at all.
- Inspect the data and infrastructure directly rather than relying on documentation.
- Classify risk against the frameworks your regulator cares about.
- Agree the exit criteria in writing, before any code exists.
- Cost the options, including doing nothing.
Out · Feasibility note · Risk register · Costed options · Written exit criteria
02 · 3–6 weeks
Prove
Get one thin end-to-end path running on your infrastructure, with measurement attached from the first week.
- Build the narrowest slice that touches every layer, including identity and logging.
- Construct the evaluation set with your subject-matter experts.
- Deploy into your environment early, so integration pain surfaces now rather than in month four.
- Record architecture decisions as they are made.
Out · Working vertical slice · Evaluation baseline · Architecture decision records · Revised estimate
03 · 8–16 weeks
Build
Turn the slice into something that can be operated, audited and changed by people who were not there.
- Harden identity, authorisation, observability and release.
- Extend evaluation into a regression gate that can block a merge.
- Load-test against your peak, not your average.
- Security review, adversarial testing and rollback rehearsal.
Out · Deployed system · Regression gate in CI · Runbook from the incident log · Security review record
04 · 2–4 weeks
Hand over
Demonstrate (not assert) that your team can deploy, diagnose, evaluate and explain the system.
- Your engineers drive; we observe and take notes.
- Injected failure in staging, handled by your team.
- Your team extends the evaluation set and interprets the result.
- Final documentation written wherever they hesitated.
Out · Demonstrated capability · Completed runbook · Agreed support arrangement, if wanted
Who is on the team
Not every role is present throughout the engagement, and the composition of the team changes by phase. In our experience, involving the governance specialist from the Frame phase rather than shortly before go-live is the single adjustment that most reliably improves the outcome.
| Role | Present from | What they own |
|---|---|---|
| Engagement lead | All phases | Owns the outcome and the honest status report. Usually also writing code. |
| AI engineer | Prove onward | Serving, retrieval, tool integration, and the software engineering around the model. |
| Data scientist | Frame onward | Evaluation design, adjudication process, agreement measurement, analysis. |
| Platform engineer | Prove onward | Deployment path, observability, release and rollback, in your tooling. |
| Governance specialist | Frame onward | Risk classification, oversight design, evidence pack. |
| Data engineer | As needed | Pipelines, contracts, lineage where the substrate needs work first. |
Working agreements
- · We work within your repositories, under your review process and to your engineering standards, rather than in a parallel codebase transferred at the end of the engagement.
- · Architecture decision records are produced for all material decisions, including the options that were rejected and the circumstances that would justify revisiting them.
- · Progress is demonstrated weekly through working software rather than through a status presentation.
- · Changes to scope are recorded and costed openly, so that nothing is added or removed without agreement.
- · Problems are reported as soon as they are identified. An estimate that is slipping is considerably more useful to you in week three than in week nine.
Engagements we decline
We will not take on work where an on-premises approach is clearly unsuitable and a hosted service would serve the client better; where the requirement is for an agent holding standing authority to take irreversible action without human oversight; where the proposed timeline is only achievable by omitting evaluation; or where the underlying problem is a data platform that needs to be addressed first.
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.