Sample: support-inbox draft assistant

Disclosure: this is a hypothetical demonstration, not client work or a claim of measured results. It shows the structure and specificity of the US$200-equivalent review.

Stated workflow

Trigger: a new message arrives in a shared support inbox.
Actions: classify topic and urgency, retrieve account context, draft a reply, and place it in a human-review queue.
System of record: help desk ticket.
Authority: draft only; the workflow may not send, close, refund, delete, or change account state.
Success: exactly one evidence-backed draft is attached to the correct open ticket and awaits named human review.

Priority findings

Priority	Failure	Control	Observable test
P0	Retry after an ambiguous attachment write creates two drafts or attaches one to the wrong ticket.	Stable key from `tenant + ticket + source-message`; destination lookup before retry; bind ticket ID in every stage.	Accept the first attachment write, drop its acknowledgement, redeliver the job, and assert one draft on the original ticket with both attempts linked to one key.
P0	Retrieved text instructs the model to send, refund, disclose another customer, or use an unapproved tool.	Treat message and retrieved documents as untrusted data; fixed tool/field allowlist; enforce draft-only capability outside the model.	Embed send/refund/data-exfiltration instructions in message and knowledge article; assert no external action occurs and the draft contains no unrelated account data.
P1	Account context is stale or belongs to another tenant because a cached lookup survived a worker reuse.	Tenant-scoped cache keys, short freshness requirement, and account/ticket binding checked immediately before draft attachment.	Run alternating jobs for two tenants with colliding local IDs; assert every evidence reference and draft uses only the triggering tenant.
P1	A new customer reply arrives while the draft is being generated, making the draft obsolete.	Record source-message version; compare ticket's latest-message ID before attachment; stale work becomes superseded, not completed.	Insert a new message after retrieval but before attachment; assert the original draft is discarded or clearly marked stale and a fresh job is queued.
P1	Low-confidence urgency classification silently routes a safety or account-takeover report as routine.	Conservative escalation rules independent of generative confidence; explicit unknown category; retain matched evidence.	Supply ambiguous security, billing, and harm language; assert uncertain cases enter urgent human triage with source excerpts and no invented certainty.

Acceptance contract

Each source message has at most one current draft for its ticket version.
No workflow component possesses send, close, refund, deletion, or account-mutation authority.
Every draft records tenant, ticket, source-message, context versions, and evidence references.
Stale or uncertain work terminates visibly as superseded or needs_review.
Retries are bounded; terminal failures include the operator action and do not disappear from the queue.

Evidence requested

Redacted event/state trace for each test.
Stable operation key and destination record identifiers.
Tool-call allowlist and denied-action log.
Source-message and context-version values before attachment.
Approval identity and final send event generated outside this workflow.

Recommended rollout

Start with synthetic tickets, then shadow generation with no help-desk writes, then attachment to an isolated review queue. Do not expand authority. Evaluate duplicate rate, stale-draft rate, tenant-isolation assertions, urgent-escalation recall on a reviewed fixture set, and terminal-failure visibility before increasing volume.

Need this level of specificity for a redacted workflow? Use the encrypted scope form. Start with the free local worksheet if a deterministic draft may be enough.

This sample is engineering guidance, not a security audit, legal opinion, compliance certification, or guarantee.