A model can be impressive while the workflow around it remains undefined.
Consider an internal knowledge workflow that proposes a response and updates a business system after approval. This is a design example, not a verified client engagement or a claim of measured performance.
1. Assign ownership of state
The knowledge source owns content and access rules. The system of record owns authoritative business state. The model proposes an action; generated text is not evidence that an action happened.
Map the caller, allowed sources, model provider, tools, reviewer, destination system and audit locations. If an external model is involved, identify which fields may leave the customer environment.
2. Carry permissions through retrieval
Signing in is not sufficient. Indexing, retrieval filters, caches and citations must preserve source permissions. Revoking access must also stop stale caches from revealing protected content.
Test a user without permission against a known fact in a restricted document. The expected outcome is denial or no result, not an answer that happens to be correct.
Retrieved documents are untrusted input. They cannot authorize tool use. Enforce tool allowlists, argument validation and caller permissions in application code rather than relying on the model to resist prompt injection.
3. Bind approval to a specific action
An approval should identify the proposal, target, parameters, version and expiry. A changed recipient, amount or target state requires another review. A generic approved flag does not prove that the executed action matches the approved one.
Missing evidence, unclear permissions, conflicting parameters or an out-of-scope proposal should trigger refusal or escalation. Human review creates an accountable decision point; it does not replace validation.
4. Separate rollback, retries and compensation
A timeout means the caller did not receive a result. It does not prove that a write failed. Reconcile using an operation identifier before retrying. Side-effecting APIs need idempotency or a documented reconciliation mechanism.
Rolling back software does not recall a sent email or undo an accepted order. Cancellation, reversal and manual correction are separate business operations with their own permissions and procedures.
5. Make evaluation a release condition
Include ordinary outcomes, unsupported answers, denied access, tool failures, duplicate requests and escalation in a versioned test set. Record the model, prompt, tool and data versions so that evaluation runs are comparable.
Inspect completion, refusal and escalation separately, alongside P95 latency, per-run cost and alert delivery. Agree thresholds against the actual risk and budget rather than relying on an undefined claim of high accuracy.
6. Make handoff inspectable
A handoff package should contain the repository and deployment guide, API contracts, access matrix, evaluation report, logging schema, alert owners, runbook and recovery-drill evidence. Agree artifact ownership, ongoing maintenance and the support window in the scope of work.
The question is whether the workflow knows what to do next, and who decides when it fails.
Inspect the reference architectures · View the acceptance template