Prototype

What a Prototype is

A prototype is a working build of the highest-priority AI or automation opportunity, tested with the people who will use it on suitable data or realistic samples, to judge accuracy, usability and benefit. In this business it is step four of the audit’s five steps, and its result decides whether the next step happens.

The word is easy to hear as a rough draft of the final product. That is not what it means here. A prototype on this site is a test. It is built to find out something, and the audit page is precise about what: whether the tool behaves well enough on this organisation’s own work to be trusted with it.

This page covers where the step sits, what it tests, who judges it, what it produces and how it differs from a pilot or a full build. It states no price and promises no result.

Where it sits in the Audit

The audit runs five steps: map the processes, document how they run, identify the opportunities, test a prototype, and build and scale. The prototype is the fourth.

It comes after the opportunities are ranked. The opportunity identification page says the output of that step is a plan and not a finished workflow, and that the next step builds the highest-ranked opportunity as a narrow working prototype. It also says a high ranking is not a promise: the prototype is what justifies a build, not the ranking alone.

It comes before anything is built for production. The AI audit page and the audit methodology both say a prototype that fails answers the question just as usefully as one that succeeds, and does so before anything has been rolled out or rebuilt around it. That is the reason for the order.

Narrow on purpose

The audit page says the prototype is narrow and specific, deliberately. It exists to answer one question, and a wider build would answer a blurrier one.

The well-scoped workflow article gives the underlying reason from the production side. It says the return concentrates where a workflow is narrow and well scoped, and that broad, loosely defined rollouts are where the return goes missing. A narrow build is easier to judge, easier to measure and cheaper to abandon if the answer is no.

The workflow design page adds what is settled first. The input, the output and the point where a person reviews the result are all decided before a prototype exists, because scope is the decision that determines the result and is fixed at that stage and not discovered during the build.

What it is tested on

The prototype is put in front of the people who would use it, running on real work or a realistic sample of it. The audit page says the organisation supplies representative work, including the awkward cases.

The awkward cases matter. The comparison of off-the-shelf tools against a custom workflow makes the same point about any trial: a short pilot on real work, including the awkward cases and not the tidy ones, shows how a tool behaves against this organisation’s own exceptions in a way a comparison table cannot. If the pilot is a prototype of a custom build, the review says the same test applies: does it hold up against the organisation’s own exceptions, not just its tidy, standard case.

Data comes into it too. The data readiness page suggests four plain questions about one workflow before anything is built:

1. Where does each input actually sit, and in which system or inbox?
2. Who or what can open it, and could the tool under consideration?
3. Is there one agreed version, or several, and who says which is current?
4. Does the knowledge that makes the process work exist anywhere except one person’s memory?

If the answers are clear, the data is probably ready for a first narrow prototype. If not, the page says the work to do is on the data first.

Who judges it

The people who do the work being tested. The audit page says the organisation lets the people who do that work judge the result, and that their verdict decides whether step five happens.

This is a deliberate choice. A tool can look right to the person who built it and wrong to the person who has to use it on a Tuesday afternoon. Putting the verdict with the users is how the step avoids being a demonstration.

It also tests the review step in practice. The human in the loop page says a named person has to check an AI result, and that the review has to name who checks, at what stage and against what standard. A prototype is the first time a business finds out whether that review is workable on its own work.

What it produces

The audit page says what comes out is a working prototype and a documented result. The result records four things: what it did, where it broke, what a person still has to check, and whether it is worth building properly.

The third item is the one most easily missed. A prototype that works well often still needs a person to check part of its output. Writing down which part is how the later build knows where to put the oversight.

The AI audit page lists the documented result among the five things an audit produces, which the organisation keeps: process documentation, a register of knowledge gaps and key-person dependencies, a prioritised roadmap, a compliance checklist for the EU AI Act and GDPR, and a tested prototype of the first opportunity with its result written down. The audit page notes that the documentation and the register hold their value even if nothing further is commissioned.

A failed Prototype is still an Answer

The audit page and the means-here line say the same thing: a prototype that fails answers the question just as usefully as one that succeeds. It tells a business, early and cheaply, that the tool does not behave well enough on its own work, or that the data was not ready, or that the process needs redesigning first.

That is the opposite of a sunk cost. The production article states the logic in plain terms. It says finding a gap during a scoping exercise costs a conversation, while finding the same gap well into a build costs a redesign. A prototype moves the discovery to the cheap end.

It also protects against a different failure. The article on telling a real workflow from a chatbot lists five demo tests that can be run in a vendor demonstration, a pilot review or an internal build check: what starts it, where the result lands, where a decision happens, what happens when it goes wrong and what is recorded. A prototype is where those tests can be run on a business’s own system and not a vendor’s.

What happens after

If the verdict is that the prototype is worth building properly, step five begins. The audit page says what the prototype proved is built for production, with oversight, logging, escalation and the point at which a person takes over designed into the build and not added once something has gone wrong. Scaling happens one proven workflow at a time, each returning to step one for the next process.

Two things are required on the client side. The organisation names an internal owner for each workflow that goes live, and it sends the people who will run it through training so that the operation belongs to the organisation and not to whoever built it. The AI ownership page covers the owner.

The production article adds what predicts whether a pilot reaches production. It names a named executive sponsor, a defined success metric tied to a real business outcome and at least one internal champion, and says projects without them consistently drift. A prototype with a named owner and a written success measure is in the group that moves on.

Prototype, pilot and build

Three words get used loosely, and the site separates them.

A prototype is the narrow working test inside the audit, judged by users on real work, with a documented result.

A pilot is the word the off-the-shelf comparison uses for a short trial on real work, of either a subscription tool or a prototype of a custom build. The old pilot address on this site now redirects here.

A build is step five: the production workflow, with oversight, logging, an owner and trained staff. The AI workflow page defines what is being built. The audit is a plan and a test. The build is separate work with its own scope.

A worked example

This is an illustration, not a real client. A small business has ranked six opportunities. The top one is drafting first replies to routine supplier enquiries, which arrive in a shared inbox, repeat daily and follow clear rules.

The business answers the four data questions and finds one gap: the pricing rules live in one person’s memory. It writes them down first. Then it builds a narrow prototype for that one process only. The people who answer supplier emails try it on a realistic sample of last month’s enquiries, including three awkward ones that break the usual pattern.

The result is written down. It drafted the routine replies well. It broke on enquiries that mixed two topics. A person still has to check any reply that quotes a price. The people who do the work say it is worth building properly, so long as that check stays in place. That verdict, and not the original ranking, is what decides step five.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating a prototype as a rough first version of the final product, when it is a test with one question. The second is testing on tidy examples, when the awkward cases are what show whether a tool can be trusted. The third is letting the builder decide whether it worked, when the people who do the work decide. The fourth is treating a failed prototype as wasted effort, when it answered the question before anything was rolled out.

How we use it

It is step four of the five steps in how we audit, Build and Test a Prototype, after the opportunities are ranked and before anything is built for production. A tested prototype of the first opportunity, with its result written down, is one of the five things an audit produces. The audit is a diagnostic and not a legal opinion.

See how we audit for all five steps, and what an AI audit actually checks for why candidate work is tested against the people who will use it. If you want to know whether a process of yours is ready for a first narrow prototype, a discovery call is where it starts.

Sources

• How we audit and AI audit: step four and step five, the narrow test, who judges it and what it produces.
• Opportunity identification and workflow design: what comes before, why a ranking is not a promise and what is settled first.
• Data readiness: the four questions that show whether the data is ready for a first prototype.
• Off-the-shelf AI tools vs a custom AI workflow and off-the-shelf AI tool: a trial on real work including the awkward cases.
• What predicts whether an AI project reaches production, well-scoped AI workflow and how to tell a real AI workflow from a chatbot with extra steps: the traits of projects that ship, why narrow works and the demo tests.