Proceed
The workflow has a narrow boundary, reviewers see enough evidence, receipts are designed, rollback has an owner, and the first production sample stays under review.
Responsible AI resource
The demo works. Now someone asks what the system can see, who approves, what gets logged, and how rollback works.
Use this packet to review one workflow before giving it source access, production credentials, write permission, public publishing ability, or customer-facing action.
This is an implementation planning artifact, not legal advice, compliance certification, or a promise that an AI workflow is safe to launch.
Launch review
Early demos are forgiving. A draft appears. A routing suggestion looks right. A test record updates. Everyone can see the potential.
The launch review is different. Stakeholders want the boundary, not the demo: exact source data, draft-only actions, approval triggers, shadow-run misses, reviewer evidence, receipt location, and rollback ownership.
Those answers should be visible in one packet before the workflow gets more permission.
Permission line
Fill out the packet before an AI workflow receives any of these permissions. It is also useful after a shadow week if reviewers found misses that need a launch decision.
One document, five source artifacts
Use the approval policy to define allowed, approval-required, and prohibited actions. Use the security worksheet to set the data boundary and vendor/model exposure. Use the approval queue guidance to decide what reviewers need to see. Use a shadow week to learn where the workflow fails on real inputs. Use the receipt template to make each run reconstructable. For the reason those records matter after customer-facing work, read how agent receipts log customer work.
The launch packet does not replace those artifacts. It makes the launch decision possible without asking a buyer, operator, or reviewer to assemble the sequence from five pages during the meeting.
Copyable packet
Copy this into a doc and fill it out for one workflow. Keep the answers short enough for a reviewer to read in one meeting. If a section cannot be answered, that is evidence for revise, shadow longer, or stop.
Select the text below, then copy it into your launch-review doc.
AI workflow launch review packet 1. Workflow summary Workflow name: Business owner: Builder / technical owner: Trigger: What the workflow is supposed to improve: Current manual baseline: Launch review date: Decision owner: 2. Source and data boundary Allowed source systems: Allowed records / fields / documents / excerpts: Excluded systems, records, fields, or data types: Data classification: Vendor, model, API, vector store, or automation-tool exposure: Credential / permission model: Retention and deletion expectations: Open security, legal, privacy, or compliance questions: 3. Action boundary Draft-only actions: Actions allowed without review, if any: Actions requiring approval: Actions prohibited in this version: Stop / escalation triggers: Known conditions where the workflow should do nothing: 4. Reviewer screen and evidence Reviewer role: Backup reviewer: Evidence shown before approval: Before / after preview required? yes / no: Policy rule shown to reviewer: Risk reason or routing signal shown to reviewer: Reviewer decisions available: approve / edit / reject / escalate: Queue threshold or routing rule: 5. Shadow-week evidence Shadow run dates: Sample size: Human baseline used for comparison: Misses found: False approvals / risky items caught: Safe items stuck in review: Changes made after the shadow run: Remaining uncertainty: 6. Receipt fields Run ID: Trigger and timestamp: Source IDs and source excerpts shown: Data boundary note: Proposed action: Policy check: Reviewer decision and edits: Final action: Destination system: Model / workflow version: Rollback or correction link: Receipt retention owner: 7. Rollback and escalation Rollback owner: Correction path: Destination-system restore path: Customer / stakeholder notification path: Security, legal, privacy, or compliance escalation owner: Incident severity threshold: 8. Launch decision Decision: proceed / proceed with restrictions / revise / shadow longer / stop Restrictions if proceeding: What must change before the next permission increase: First production review sample: Date for next review: Who signed off:
Filled example
This example touches customers, records, approval queues, and receipts without requiring a specialized domain. It launches only with restrictions and continued human review.
Select the text below, then copy it into your launch-review doc.
AI workflow launch review packet
1. Workflow summary
Workflow name: Triage and draft replies for new support tickets.
Business owner: Support operations lead.
Builder / technical owner: Internal automation owner and BaristaLabs implementation lead.
Trigger: New support ticket created in the help desk.
What the workflow is supposed to improve: Reduce first-pass triage time and prepare reviewer-ready replies.
Current manual baseline: Support lead reviews every new ticket, picks category, finds the relevant KB article, drafts reply, and updates CRM note.
Launch review date: 2026-06-08.
Decision owner: Support operations lead.
2. Source and data boundary
Allowed source systems: Help desk, approved support knowledge base, CRM account summary, email platform after approval.
Allowed records / fields / documents / excerpts: Current ticket subject/body, customer ID, plan tier, open-ticket count, last support note for the same account, approved KB excerpt.
Excluded systems, records, fields, or data types: Payment card details, unrelated customer records, credentials, private sales notes, HR/legal notes, broad CRM exports.
Data classification: Customer data and internal support notes; possible sensitive account context.
Vendor, model, API, vector store, or automation-tool exposure: Model receives ticket text, limited account context, and approved KB excerpts. No broad CRM export.
Credential / permission model: Read-only help desk and CRM access for draft preparation. Send/update permission stays behind reviewer action.
Retention and deletion expectations: Receipt stored with the ticket/CRM activity. Do not create a separate store of unrelated customer context.
Open security, legal, privacy, or compliance questions: Confirm whether tickets may contain regulated data. Confirm model/vendor settings and retention exceptions.
3. Action boundary
Draft-only actions: Draft reply, suggest support category, list missing information, prepare CRM note for review.
Actions allowed without review, if any: Create internal review packet only.
Actions requiring approval: Send customer reply, save CRM note, close ticket, escalate to billing/security/account owner.
Actions prohibited in this version: Promise refund, quote legal terms, approve cancellation exception, request credentials, discuss another customer's data, mark issue resolved without review.
Stop / escalation triggers: Refund language, security/access issue, angry customer, legal threat, account cancellation, conflicting CRM notes, missing source evidence, regulated-data mention.
Known conditions where the workflow should do nothing: No matching KB article, source record missing, request asks for credentials, or customer asks for another customer's information.
4. Reviewer screen and evidence
Reviewer role: Support lead or trained support reviewer.
Backup reviewer: Operations manager.
Evidence shown before approval: Original ticket, relevant KB excerpt, customer context shown, draft reply, CRM note preview, risk reason, approval rule.
Before / after preview required? yes.
Policy rule shown to reviewer: External messages and CRM notes require review. Refund/security/legal/access requests escalate.
Risk reason or routing signal shown to reviewer: Category, escalation reason, missing-source flag, and blocked-action check.
Reviewer decisions available: approve / edit / reject / escalate.
Queue threshold or routing rule: All items reviewed for first 50 tickets. After review, low-risk category suggestions may be considered for auto-tagging only.
5. Shadow-week evidence
Shadow run dates: 2026-06-01 through 2026-06-05.
Sample size: 50 tickets.
Human baseline used for comparison: Existing support lead triage and replies.
Misses found: Two refund requests needed escalation; one angry-customer ticket used a tone that was too casual; three drafts lacked the relevant KB link.
False approvals / risky items caught: Security/access ticket correctly escalated before any reply.
Safe items stuck in review: Password-reset information requests repeatedly stayed in review even when the approved KB article matched.
Changes made after the shadow run: Added refund/access/legal escalation triggers, required KB source link in reviewer screen, tightened tone rule for angry customers.
Remaining uncertainty: Whether password-reset information requests can be auto-categorized without review.
6. Receipt fields
Run ID: support-triage-{ticket-id}-{timestamp}.
Trigger and timestamp: Help desk ticket creation timestamp.
Source IDs and source excerpts shown: Ticket ID, KB article ID, same-account support note ID if used.
Data boundary note: Allowed support context only; no payment, credential, unrelated account, or legal/HR material.
Proposed action: Draft reply, support category, CRM note preview, escalation recommendation.
Policy check: Approval required for external message and CRM note. Escalate refund/security/legal/access language.
Reviewer decision and edits: Reviewer ID, decision, edits, rejection or escalation reason.
Final action: Email sent by reviewer, CRM note saved, ticket category updated, or no action.
Destination system: Help desk, CRM, email platform.
Model / workflow version: Workflow version and model/provider setting used for the run.
Rollback or correction link: Ticket correction note, CRM amendment, reopened-ticket link, customer correction email if needed.
Receipt retention owner: Support operations lead.
7. Rollback and escalation
Rollback owner: Support operations lead.
Correction path: Send correction, amend CRM note, reopen ticket, attach correction note to receipt.
Destination-system restore path: Restore CRM note/status from before/after value in receipt.
Customer / stakeholder notification path: Support lead sends customer correction; account owner notified for enterprise accounts.
Security, legal, privacy, or compliance escalation owner: Security/privacy owner for access or regulated-data issues; legal owner for legal threats or terms.
Incident severity threshold: Any credential request, wrong-customer data exposure, refund promise, or legal/security advice leaves normal queue and becomes incident review.
8. Launch decision
Decision: proceed with restrictions.
Restrictions if proceeding: Human review required for every customer message and CRM note. No auto-close. No refund/access/legal/security replies. Category suggestions only after reviewer approval.
What must change before the next permission increase: Review another 50 tickets, measure escalation misses, and confirm whether password-reset category can be auto-tagged safely.
First production review sample: First 50 production tickets and every escalated ticket.
Date for next review: Two weeks after launch.
Who signed off: Support operations lead, builder/technical owner, privacy/security owner.Launch decision
The packet should end with a decision, not a vibe.
The workflow has a narrow boundary, reviewers see enough evidence, receipts are designed, rollback has an owner, and the first production sample stays under review.
The workflow can launch only with tighter permissions, a smaller sample, or more review than the end-state design.
The team needs a clearer boundary, better evidence, different queue threshold, safer credentials, or stronger receipt fields before another launch review.
Real inputs are still teaching the team where the workflow fails, so production permission should wait.
The workflow crosses a line the team is not ready to manage: data exposure, regulated risk, irreversible action, unclear reviewer accountability, or no credible rollback.
BaristaLabs help
Bring one workflow, the source systems it needs, the actions it wants to take, and the permission line you are unsure about. BaristaLabs can help turn the packet into reviewer screens, approval rules, receipts, and rollback paths.
FAQ
No. This is an implementation planning artifact. It does not replace legal, privacy, compliance, security, or operational review for regulated or sensitive workflows.
Use it before the workflow gets production credentials, write access, customer-facing permission, public publishing ability, money movement, regulated-record access, or irreversible operations. It is also useful after a shadow week when the team has real misses to discuss.
Yes for higher-risk workflows. The launch packet is the meeting document. The approval policy and security worksheet provide the underlying details for action boundaries, data access, vendor/model exposure, retention, and escalation.
A blank section is a launch signal. Missing reviewer evidence, rollback owner, receipt fields, or source boundary usually means revise the workflow or shadow longer before increasing permission.
No. Low-risk internal drafts may need a lighter version. Use the full packet when the workflow can affect customers, records, money, credentials, public content, regulated work, access, deletion, or relationship-sensitive decisions.