Transfer and development

Moving it into the company is the actual work.

Three routes, sequential by design. Each answers a different question, and none makes sense before the previous one has been answered.

01 / Route one

Resident programme.

Format

A programme run inside the company, with its full management team, on its own cases. Not training with worked examples: the actual work is the material.

Available training is canned — the same content for a component manufacturer, an insurer and an agency. It teaches tools. A management team's problem is not which tool to use, but which decisions of their business change now that the tool exists.

  • Levelling and dismantling: separating what the technology does from what is claimed
  • Mapping the decisions of each area, and where the bottleneck is information rather than judgement
  • Working real files and data in the room, which is where the objections that matter appear
  • Building the team's own criterion for telling a solid AI proposal from a dressed-up one
  • A follow-up session that checks what is genuinely used weeks later
Guarantee If the management team considers the programme did not deliver, 80% of the fee is returned, net of travel. The risk should sit with whoever makes the claim, not with whoever contracts it.
02 / Route two

Diagnostic and roadmap.

Method

Once the board can evaluate, the question changes: it stops being what is possible and becomes where to start. Most AI projects fail by choosing the wrong problem, not by executing it badly.

  1. 01

    Elicitation by area

    Structured sessions with the actual owners of each process, not only with the board. We record how the process really runs, including the exceptions nobody documents.

  2. 02

    Inventory of pains and initiatives

    Each pain becomes one or more candidate initiatives, described in enough detail to be estimated. The resulting catalogue is cross-cutting: it includes what no single area asked for because it affects several.

  3. 03

    Scoring and matrix

    Each initiative is scored against explicit criteria — economic impact, urgency, technical feasibility, data dependency, organisational resistance — and placed on an impact-priority matrix. The score is arguable; arbitrariness is not.

  4. 04

    Triple planning

    Every prioritised project is planned three times: a minimum version solving most of it at the lowest cost, a standard one, and an ambitious one that takes on the whole problem. The board chooses with all three in front of it.

  5. 05

    Sequenced roadmap

    Order is set by dependencies, not by score alone: some projects cannot start until another has tidied a data source. The roadmap makes those dependencies explicit.

Ownership The diagnostic is delivered complete and belongs to the company, scoring criteria included, so it can re-evaluate initiatives a year later without depending on whoever produced it. It can be executed with its own team, another supplier, or us.
03 / Route three

System development.

Build

The projects the diagnostic prioritises get built. Each is designed around the company's real process, with its exceptions and its regulations, not around a sector template. This is where the laboratories come in: a development enters through the lab that owns its domain, and returns evidence to it.

Condition

Closed scope

Every development has an acceptance criterion defined before starting and a date on which it is checked. No open scope, no indefinite billing.

Condition

Client ownership

Code, data and generated knowledge belong to the company, delivered with enough documentation for another team to maintain them.

Condition

Measured from day one

Which indicator must move, and how it will be measured, is agreed before the first line is written. If it cannot be measured, it does not get built.

  1. LAB.01 Industrial Technical knowledge locked in catalogues and documentation
  2. LAB.02 Health & Pharma Assisted formulation and regulated decision support
  3. LAB.03 Marketing Reconciling campaign and revenue data for prediction
  4. LAB.04 Electoral Voting behaviour, party systems and forecast models
  5. LAB.05 Agentic Systems How multi-agent systems are designed to survive production