Six diagrams, six questionsEnough shared vocabulary that the first call doesn't start with definitions
Six diagrams
From “what is it” to “how long”
Each carries
One answer + four reading notes
How to use them
Walk your own process and find the break
Yours to take
Screenshot them, use them internally
Pick one
Which of these is in your way right now
01 · “What is automation, actually?”
What one AI workflow looks like
The AI occupies one box out of six
What the AI is responsible for is extraction, judgement and drafting. Getting the data out beforehand and writing the result back afterwards is engineering — and in most “AI projects” that's where the actual work is, not in the middle box.
The human checkpoint isn't unfinished work
Consequential actions pausing here is designed behaviour. Which actions count as consequential is what the fourth diagram is about.
The audit trail matters as much as the write-back
Who approved it and on what basis can't be reconstructed later if it wasn't recorded at the time. Whether you can explain what happened depends entirely on this box existing.
Without the last three boxes it isn't deployed
The first three alone are “getting AI to write something for me”. Add confirmation, write-back and the audit trail and it's connected to the business.
Starting out means building one complete row of those six boxes, running it, and only then discussing the second.
02 · “Why didn't it work when we tried?”
The five places these projects break
Can't extract
Data spread across a dozen systems, or systems with no interface and no access. Nothing downstream matters until this works — and of the five, it's the most common.
Nobody decides
Who approves, how many stages, whose definition wins when two departments disagree. Those are management decisions and no outside party can make them for you. Where a disagreement is still open, we recommend not automating that step.
Can't write back
If a person still has to copy the AI's result into a system, nothing was automated. Projects that stall halfway usually stall here.
Silent failure · nobody maintains it
It stops and nobody notices, or the rules change three months in and nobody updates it. Neither is technical — both are questions of who is responsible, which is why they need an answer before the project starts.
That's exactly what a diagnostic does: walks your existing process and names which specific step each of the five breaks at.
03 · “What's the real difference between self-hosted and SaaS?”
Three ways data can flow
Look at the arrows, not the feature list
What the three can do may be roughly the same. The real difference is whether that middle arrow crosses the dotted line — a far more useful test than comparing features.
Public SaaS doesn't mean insecure
It means a copy of the data sits on someone else's machines, and the responsibility boundary moves with it. While volumes are small and the content isn't sensitive, that's good value, and we'll say so.
Hybrid is a conditional compromise
Requests go out rather than business data — but only if you can say precisely which fields count as business data and who polices that. If you can't, don't pick this tier.
Two questions choose the tier
How sensitive the data is, and whether the business stops if this process stops. Only when both answers are “very” is self-hosting worth the extra cost.
When it's time to move from an off-the-shelf tool to something self-hosted is set out on the home page.
04 · “What happens when the AI gets it wrong?”
Where human checkpoints belong
Everything outside those three passes
Classifying, structuring, drafting, tagging — worst case you run it again. Put a checkpoint on those too and people start approving without looking, at which point the checkpoint is already worthless.
Too many checkpoints is the same as none
This is the easiest mistake to make when building one of these. Better to have too few than a pile nobody reads.
An alert has to carry three things
What changed, on what basis, and approve or reject in one tap. Miss one and the person has to go back into the system to check for themselves — after a few times, they stop looking.
Checkpoints aren't the safety net for failure
“Someone approved it” and “someone knows it broke” are different things. The second is the fourth break in diagram two. You need both; either one missing means it isn't finished.
How a checkpoint reaches a specific person, and where the alert goes, is specified per project during delivery.
05 · “What stops it inventing things?”
How a knowledge base answers
Search first, answer second
The first thing that happens to a question is a search of your own material, and only matching passages are used to compose an answer. Skip this step and you're back to answering from impression.
The answer has to link back
An answer with its source attached can be checked. Without one, you have no way to tell whether it was found or invented — and that matters more than which model is underneath.
Escalating on no match is design
This is deliberate behaviour, not a capability gap. An assistant willing to answer anything is far more dangerous than one that says it can't find something.
Accuracy depends on your material
If the material is out of date, self-contradictory, or three departments define the same thing differently, perfect retrieval doesn't help. Which is why organising it can't be avoided, and why it's the most time-consuming part of these projects.
How the whole thing is built, how material gets in and how permissions are drawn is on the service page.
06 · “How long until we can use it?”
Four stages — and why this diagram carries no timeline
Every stage has a deliverable
The diagnostic ends with a list in three tiers; the proposal fixes scope, limits and acceptance criteria; during the build something running is visible every week; handover delivers source code, documentation and training.
Why there's no timeline on this diagram
Same four stages: one company clears the diagnostic in two weeks, another sits in stage two for two months. The pace barely depends on us — it depends on whether your data can be reached and whether someone resolves the disagreements. Publishing an average would mislead both sides.
You can take only the first two
The diagnostic and the proposal are deliverable on their own. The conclusions are yours, and you can implement them without us or hand them to someone else.
Handover is the end, not a tie-in
Source code and data are both on your own servers, and the documentation and training exist so someone else can carry it on. That was already decided in the third diagram.
You have something to take away at the end of the first stage, and that list is yours whether or not we continue.
Questions
Asked more than three times about these
01Can we use these diagrams ourselves?+
Yes. All six describe what this kind of thing generally looks like rather than any one company's implementation, so screenshotting them or putting them into an internal deck is fine — they carry the source, so just credit it. If you need a version redrawn against your own process — replacing the five breaks with the specific places you're stuck, say — that's diagnostic work, and it comes back with your process map.
02Our process doesn't look like this. Does that mean it doesn't apply?+
It almost certainly doesn't look like this — these are skeletons, not templates. Only four questions actually have to line up: who triggers it, where the data comes from, who confirms, and where the result is written. If you can answer those four, this maps onto your process; the ones you can't answer are precisely what a diagnostic is for.
Next