How we deploy

Four stages, and a gateat the end of each one.

A stage is not finished because a demo worked. It is finished when its gate is passed and the number has moved. Any of them can end in us telling you to stop, and the earlier that happens the less it costs you.

01

Discover

We measure what the work costs you today.

We map how it actually runs rather than how the process document says it runs, score every source of data for what it can carry, and take the baseline. Then we rank the candidates and tell you which ones we would not automate.

GateA baseline you have signed, and a ranked list

02

Prove

We run it on a slice of your real data before you commit.

We build the evaluation set from real failures first, then ship the thinnest end-to-end version and run it against the baseline. If it cannot beat the old way on your own data at acceptable cost, we stop here, which is the cheapest place to stop.

GateA fixed build scope, or an honest no

03

Build

The review lane gets built before the clever part.

The job ships into your real workflow with a named person approving every single output. Autonomy is a dial, not a switch, and nothing turns it up except measured accuracy on your own cases.

GateLive, under full human review

04

Run

It earns its autonomy, then it keeps earning it.

Full review, then spot checks, then exceptions only. In regulated work the checking never fully stops, it just gets cheaper. Every month you get one page saying what it returned.

GateGraduated, with a measured number

What you get, and when

Everything arrivesbefore you ask for it.

The difference between a supplier who has done this before and one who has not is whether the document exists when you need it or gets written after you ask. Here is the whole list, in the order it reaches you.

First callThe domain packWe arrive fluent in your nouns, your exception path, your regulator.
ScopingA one-page scope, with exclusionsIncluding the work we are advising you not to automate, and why.
Security reviewThe security pack, already writtenData flow, access tiers, where data rests, what leaves, sub-processors, DPA, and how to revoke it.
Before the buildThe signed job specOne page. The named reviewer, and the accuracy number that would earn it more autonomy.
Go-liveAcceptance on your own samplesMeasured against the baseline taken before anything changed.
Every month afterThe pageHours, accuracy, money, with the log behind it, including the months the number went down.
Year twoThe handover packCode in your repository, decision records, your people running it.
After it goes live

These things degradequietly, not loudly.

Ordinary software fails in a way somebody notices. This gets a little worse at its job while everyone assumes it is fine. Four things have to keep happening, and each one has a failure mode worth knowing about.

We re-check what it may touch

Without itAccess quietly builds up that nobody signed off on, and you find out during an audit.

We re-tune it when things move

Without itYour supplier ships a new model or your process changes, accuracy slips, and nobody notices until reviewers quietly start checking everything again.

We feed your reviewers' corrections back in

Without itThe checking costs the same in year two as it did in year one, so the return flattens instead of compounding.

We produce the number

Without itThere is nothing to put next to the invoice at budget time, and the line gets cut.

This is why there is a monthly fee, and it is not maintenance. Maintenance implies you are paying to hold something still. You are paying for month eighteen to be better than month three, which does not happen on its own.

The thinking behind itWhat AI may touch
Tell us about the work

Book a discovery call.Leave with a plan you can act on.

Start with your people or with the work. One job at a time, on probation, measured in hours and money. Everything we build stays yours.

Loading form…