Keep an Acceptance Record for Every Voice Workflow Version

Voice workflow version acceptance is the practice of connecting a configuration change to the evidence that makes it safe to use. Without that connection, a team can know that “the assistant worked last week” while having no reliable account of which prompt, tools or knowledge were active at the time.

The record does not need to be elaborate. A small business may use a shared document. An engineering team may attach it to a release. What matters is that someone can identify the current behaviour, understand why it changed and find a known previous configuration.

Describe the change in business terms

Lead with the caller situation that motivated the revision. For example: “Callers sometimes correct an equipment code after the first readback; the assistant now reconfirms the corrected code before saving it.” This is a hypothetical change description, but it is specific enough to evaluate.

Avoid entries such as “improved prompt” or “better AI.” They cannot tell a reviewer what success looks like. Include the behaviour that should remain unchanged, especially when a revision touches a shared instruction used across several tasks.

Burki's voice-agent building guide explains the wider configuration approach. An acceptance record adds the operational history around whatever supported editing method your team uses; it does not require a particular interface feature.

Capture the configuration boundary

Record the workflow or prompt revision, selected voice mode, model where relevant, knowledge revision and enabled integrations. Include permission changes explicitly. A new instruction and a new write permission are different changes even when they arrive together.

Also note the route used for testing. A browser conversation, a simulated tool result and a telephone call with a real provider do not establish the same capabilities. If transfer or another advanced action is outside the accepted scope, put that limit beside the release decision.

The record should not contain credentials. Refer to managed configuration names or owners, not copied secrets. Keeping evidence useful does not require making account access portable.

Use a short acceptance table

A practical review could contain these rows:

LiveKit documents turn-level tests in its testing reference. Such tests can support the record, but the record must explain their boundaries. A tool assertion cannot by itself prove that the caller heard the final confirmation.

Review exceptions before release

Not every unresolved item has the same significance. A slightly verbose answer may be acceptable during a bounded pilot. A falsely confirmed action or an untested required route is different. State the exception, its practical effect and the person who accepted it.

This makes the decision reviewable without pretending that software becomes risk-free. It also prevents an exception from disappearing when a new operator takes over. Revisit exceptions when the related feature changes or when the pilot expands.

Make rollback a real option

A previous prompt is not a complete rollback if the new revision also changed tool permissions or document selection. Identify the entire set of changes that must move together. Confirm who can restore it and how the team will tell that restoration worked.

During a rollout, compare actual conversations with the behaviour described in the record. A new failure should refer back to the revision that introduced it, while preserving uncertainty when the cause is not yet demonstrated.

Use Burki's production-safe learning approach to make reviewed improvement a habit. Start the next change with one sentence describing its purpose and finish with evidence of the result. That small discipline turns “we think this is the latest version” into an operationally useful answer.