How we build

A real implementation process, not a sales sequence.

Five phases take you from a free conversation to a production system with a measured outcome. Fixed scope, agreed price, and a number we are trying to move.

Delivery process · five phases
  1. 01

    Consultation & feasibility

  2. 02

    Scoping

  3. 03

    Build & integrate

  4. 04

    Deploy & train

  5. 05

    Measure & improve

The five phases

From conversation to a measured outcome.

Phase 01

Consultation & feasibility

A free conversation about the process and the outcome

A 30-minute working session with a software engineer. You describe the workflow you want to change and the number you want to move. We tell you honestly whether AI is the right tool for it — and if it is not, we say so and suggest what would work.

Agreed problem, agreed target outcome, honest feasibility view.

Phase diagram
Consultation and feasibility: a discovery node connecting an engineer to a client workflow, highlighting the agreed problem, target outcome and feasibility view.

Phase 02

Scoping

Fixed scope, agreed price, one measurable outcome

We map the process end to end: the systems involved, the data available, the steps a human currently performs, and the measure we will move. You get a written scope with a fixed price. Nothing changes without your sign-off.

A fixed-scope plan: what we build, what it connects to, what number moves.

Phase diagram
Scoping: a project scope blueprint detailing system connections, data inputs and human action steps, locked to a fixed scope and agreed price card.

Phase 03

Build & integrate

We build it inside the software you already run

The engineering phase. We connect the system to your actual estate — CRM, ERP, databases, files, email, APIs — and build the AI into your existing workflows rather than beside them. Data stays in your boundary, secured to your standard.

A working system in your environment, connected to your real systems.

Phase diagram
Build and integrate: a central AI engine inside an enterprise boundary with CRM, ERP, SQL databases and APIs connected, with a lock showing data stays inside the customer boundary.

Phase 04

Deploy & train

Live in production, with your team trained on it

The system goes live under your governance: security reviewed, access controlled, documentation written. Your team learns to use it, read its output, and hand decisions to it with confidence. Launch is a milestone, not a cliff edge.

Production deployment your team actually uses.

Phase diagram
Deploy and train: a launch dashboard with governance controls, security gates, documentation nodes and a team training workflow.

Phase 05

Measure & improve

We report the outcome and keep improving it

After launch we report on the agreed measure, tune the system on real use, and maintain it. When the first number moves, we agree the next process to engineer — the architecture is already in place.

Reported results, continuous improvement, a roadmap to the next win.

Phase diagram
Measure and improve: a feedback loop where performance reporting feeds system tuning, with an arrow to the next process roadmap.

The engineering underneath

What the system actually does.

Behind the delivery process is a mechanism built around evidence, provenance and control — not “paste everything into a model and hope.”

Mechanism · five engineering stages
ENGINEERING STAGES · 01 → 05STAGE 01LOADSTAGE 02STORESTAGE 03MATCHSTAGE 04RETURNSTAGE 05EXPLAIN
Five engineering stages mechanism: Load, Store, Match, Return, Explain flowing along the process rail.
End-to-end flow · dashed line is the customer boundary
END-TO-END · AUTHORISED SIGNAL FLOWHOW IT WORKS · MECHANISMCUSTOMER ESTATE — your systems stay inside this line01LOADsource bus02STOREpath spine03MATCHmatch fan04RETURNjson envelopebrief05EXPLAINreads brief onlyAPPROVED MODEL · EXPLAIN ONLYHUMAN TEAM / WORKFLOWapproved outcome → path storerecords, paths and outcomes stay inside the dashed boundaryexplain sits on the boundary edge

Stage 01 · AUTHORISED SIGNALS IN

Authorised signals in

The system starts with the data you approve — records, tickets, usage, billing, documents — pulled from systems you already run. Not a free crawl, not an unbounded paste into a model.

01 · LOAD — AUTHORISED SIGNALS INapproved sourcesCRMEMAILSUPPORTBILLINGWEBOUTCOMESAUTHORISED ITEM BUSapproved · ordered · deduplicatedevery signal named and approved — no free crawl
Authorised signals in: secure, gated data pipelines pulling records, tickets, usage logs, billing and documents into an approved boundary gate.

Stage 02 · STORED AS TRACED PATHS

Stored as traced paths

Signals are kept as ordered, source-proven trails rather than a flat pile of documents, so the system can show why it recommends something.

02 · STORE — STORED AS TRACED PATHSOBJECT IDord_79421time →CRM01 · 09:12EMAIL01 · 14:05ERP02 · 08:40WEB02 · 11:22CSV03 · 10:03CUSTOMERPAYMENTORDERorder is part of the evidence — traced, not flattened
Stored as traced paths: an ordered, sequential provenance graph showing source-proven audit trails with identity links.

Stage 03 · MATCHED TO KNOWN OUTCOMES

Matched to known outcomes

The current situation is compared with past situations that had a known result — won, lost, saved, resolved — so recommendations follow evidence, not resemblance to a keyword.

03 · MATCH — MATCHED TO KNOWN OUTCOMESCURRENT PATHthis deal's contourCONVERTEDLOSTRETAINEDRANKED SIMILAR PATHSranked by outcome evidence
Matched to known outcomes: an evidence-matching engine categorising historical results as won, lost, saved or resolved.

Stage 04 · A CHECKED BRIEF OUT

A checked brief out

The output is a schema-validated brief: recommended next actions, supporting examples, confidence, and caveats. A model or a human can turn that brief into tickets, replies, or actions.

04 · RETURN — A CHECKED BRIEF OUTchecked brief · application/json{"top_examples": [ 2 shown ],"attribution_path": "crm→email→erp","confidence": 0.87,"caveats": [ 1 flag ],"next_tasks": [{ "action": "quote", "priority": "high" },]}SCHEMA-VALIDRAW EXPORTmachine-checked before anymodel or human reads ita checked brief out — never a raw data dump
A checked brief out: a schema-validated output card with recommended actions and a confidence rating, branching into human review and engineered action paths.

Boundary. The same checked brief feeds an approved model or a human team — your call. Records, paths and outcomes stay inside the dashed line, and nothing leaves without your approval. With the Elite version we also supply the open-source model, deployed inside your sovereign boundary and used only by this platform to turn the checked JSON into usable instructions.

Before you book

Straight answers to common questions.

How long does a pilot take?

A fixed-scope pilot on a single workflow is typically measured in weeks, not quarters. The exact timeline depends on the systems we need to integrate and how quickly we can get access.

Do we need to replace our existing software?

No. We build into the systems you already run. Integration with your existing estate is the core of the work, not an add-on.

Where does our data go?

Your operational data stays in your boundary. We work to your data and security requirements, and nothing is sent to a third party without your approval.

What if AI is not the right answer for our process?

We tell you in the consultation. We would rather turn down a project than build a system that does not earn its keep.

Your next step

Book a consultation. The first hour is free and honest.

Tell us the process you want to change and the number you want to move. We will tell you whether AI can do it — and give you a fixed-scope route to a pilot that proves it.

30 minutes with a software engineer, not a sales rep.

An honest feasibility view on your workflow.

A fixed-scope route to a measured outcome.