The demo is not the work.
A prototype can show that an idea is useful. Production acceptance asks a broader question: can the complete workflow be operated, checked and recovered by the people responsible for it?
A model returns an answer. A voice assistant completes a conversation. An integration moves one example record. Each can demonstrate something valuable. None, by itself, establishes that the surrounding operation is ready.
An operating workflow has inputs that vary, systems that refuse requests and people who need to know what happened. Acceptance needs to examine those relationships as well as the successful result.
The framework below is a practical starting point for AI and integration work. It is general guidance, not a report of a customer deployment.
Define the complete operating path
Start before the model or integration runs. Where does the input come from? Which system owns the record? What information is required? What should happen when that information is missing?
Then follow the result. Does it update a record, create a task, start an action or wait for review? Name the destination and the person responsible for dealing with an exception. A successful intermediate step is useful only if its meaning in the wider workflow is clear.
For example, consider a workflow that reads an incoming request and proposes a next action. The scope might include input validation, a model response, a policy check and either a permitted action or human review. That example describes an operating structure; it does not establish which model or platform should be used.
Input enters validation. Valid input proceeds to the model; invalid input goes to review. The model proposes an action. A policy check permits the action or sends it to review. An action failure also goes to review. Review ends with correction or a stop; it does not automatically grant execution permission.
Decide where AI may act
Producing a suggestion and carrying out an action have different consequences. Define which tools a workflow can use, what information it can access and which decisions stay with a person.
A useful boundary can be concrete: the workflow may prepare a draft, but a person sends it. Or it may update a specified field only when agreed conditions are met. What matters is that the boundary can be explained and tested.
Evaluation should reflect the intended use. Include ordinary inputs and examples where information is incomplete, ambiguous or outside scope. Decide what an acceptable result looks like before treating a successful demonstration as evidence of readiness. OpenAI’s evaluation guidance offers a useful reference for designing task-specific evaluations.
Test failure paths deliberately
A request can time out after another system has already accepted it. A repeated event can produce duplicate work. A record can change between being read and being updated. An incorrect model response can still look plausible.
Select failure scenarios according to the actual design and the consequences of failure. For each scenario, agree what the system records, whether it retries, when it stops and who is told.
A retry is especially important to understand. If repeating a step could create a second charge, record or notification, the recovery design needs to account for that possibility. Do not assume that repeating a failed-looking request is always safe. The Amazon Builders’ Library explains the underlying problem and the use of idempotent APIs to make retries safe.
Give an operator control
The accepting person should be able to follow the workflow without relying on the person who built it. They need to recognise incomplete work, understand what a failure means and know the next permitted action.
Handover can be concise. Explain the purpose, the normal operating path, the important limitations and the steps for stopping or recovering the workflow. Identify which parts depend on another provider or require additional access.
Visibility does not require an elaborate dashboard. It requires enough accurate information for the person responsible to make the next decision.
A practical acceptance checklist
Before delivery, agree answers to these questions:
- What is the complete expected result?
- Which inputs and variations are included?
- What should happen when required information is missing?
- Which actions are permitted automatically, and which need review?
- How are failed or incomplete steps made visible?
- Can a repeated event or retry create duplicate work?
- How does a person stop or recover the workflow?
- What limitations remain, and who accepts them?
- Who is authorised to accept the implementation?
This is a starting checklist, not a universal certification. A specific system may need more detailed tests, particularly where a wrong action has significant consequences.
When an implementation has already stalled
Start by separating what is known from what is assumed. Identify a reproducible failure, preserve the parts that work and define the smallest useful recovery scope.
The next step may be a repair, a missing connection, a narrower requirement or a decision that the proposed approach is not viable. Agree that decision before treating an unfinished system as a reason to begin a larger rebuild.
Production rescue describes this bounded approach. For the work around a model, see AI implementation.
Make acceptance part of the work
A working implementation has more than a successful demonstration behind it. It has a defined operating path, evidence against agreed criteria and a person who can take responsibility for its use.
That is the standard Calvoryn uses to frame implementation work.
Make acceptance part of the work.
Describe the current system, the problem and the constraints. A short note is enough to start.
Discuss a project