01
Source
Systems allowed, fields allowed, exclusions, credential model, vendor/model exposure.
Responsible AI resource
Build the evidence packet before the AI workflow gets permission
The demo can already draft, route, summarize, and update. The permission decision needs different evidence: what the workflow can see, what it must ignore, what it may do, who approves, what the reviewer sees, what gets logged, and who owns rollback.
This is an implementation-planning artifact, not legal advice, compliance certification, or a guarantee that an AI workflow is safe to launch.
Workflow request
- Trigger
- new support ticket
- Source systems
- help desk, account tier, approved KB
- Permission requested
- draft-only with reviewed send
Evidence packet
Sample packet- Source boundary
- Exclusions
- Allowed actions
- Approval lane
- Vendor/model exposure
- Receipt fields
- Threshold / stop rule
- Rollback owner
Reviewer decision
- Approve pilot
- Revise boundary
- Shadow longer
- Stop
The demo is not the handoff
The workflow is ready enough to make the room impatient. A support ticket comes in. The system reads the message, checks the account tier, pulls an approved help article, drafts a reply, and prepares a CRM note.
Then the reviewer asks for the handoff. What sources can it read? Which fields are excluded? Can it send the reply or only draft it? Which vendor sees the ticket text? What threshold moves work out of review? What will the receipt prove after the action? Who owns rollback if the note is wrong?
A Slack thread, three screenshots, and a confident explanation are not an evidence packet. The packet is the object that lets the team say yes, no, or not yet without trusting memory. Start with the security review worksheet, connect it to the approval queue, and make the run reconstructable with the agent receipt template.
Copyable artifact
What to put in the packet
Keep the first packet short enough for a decision-maker to read. If a field cannot be answered, do not hide it. Missing evidence is often the reason to keep the workflow in draft mode or run a shadow week before permission expands.
02
Action
Draft-only, approval-required, prohibited, escalation triggers.
03
Reviewer
Role, source excerpts, policy rule, risk reason, execution preview, available decisions.
04
Threshold
Manual lane, automatic lane if any, expensive mistake, stop condition, audit sample.
05
Receipt
Trigger, source IDs, policy check, reviewer decision, final action, rollback owner.
AI workflow evidence packet
1. Workflow request
Workflow name:
Business owner:
Builder / technical owner:
Workflow trigger:
Current manual baseline:
Permission requested: draft-only / reviewed action / limited autonomous action / broader autonomy
Decision needed: approve / revise / shadow longer / stop
2. Source boundary
Allowed source systems:
Allowed records, fields, documents, excerpts, or retrieval snippets:
Excluded systems, records, fields, or data types:
Data classification:
Credential / permission model:
Vendor, model, API, vector store, or automation-tool exposure:
Retention, deletion, and logging assumptions:
Open security, privacy, legal, or compliance questions:
3. Action boundary
Draft-only actions:
Actions allowed without review, if any:
Actions requiring approval:
Actions prohibited in this version:
Stop or escalation triggers:
Known conditions where the workflow should do nothing:
4. Reviewer evidence
Reviewer role:
Backup reviewer:
Evidence shown before approval:
Source excerpts shown:
Before / after preview required? yes / no:
Policy rule shown to reviewer:
Risk reason, threshold, or routing signal shown:
Reviewer decisions available: approve / edit / reject / escalate / keep manual
5. Threshold and stop rules
Score or threshold used, if any:
Which mistake is more expensive: risky item approved too soon / safe item held too long:
Automatic lane allowed for:
Manual-review lane required for:
Stop immediately when:
Sample or audit plan after any threshold change:
6. Receipt and rollback
Receipt fields:
Where the receipt lives:
Systems touched after approval:
Final state recorded:
Rollback or correction path:
Rollback owner:
Incident or escalation owner:
How long receipts are retained:
7. Evidence status
Ready to pilot because:
Not ready because:
Needs stakeholder review from:
Next test or shadow-run sample:
Permission increase criteria:
Next review date:Source map
Use the source artifacts to fill the packet
The evidence packet is not a new bureaucracy layer. It is the place where the existing artifacts meet. Each source page answers one part of the reviewer’s question.
| Packet section | Source artifact | What it contributes |
|---|---|---|
| Workflow request | AI workflow controls | Named workflow, permission requested, current baseline, owner. |
| Source boundary | Security review worksheet | Systems, fields, excluded data, credential model, vendor/model exposure, retention assumptions. |
| Action boundary | Approval policy template | Allowed reads, draft-only actions, approval-required actions, prohibited actions, escalation triggers. |
| Reviewer evidence | Approval queue guide | Proposed action, source evidence, policy rule, risk reason, reviewer decisions, execution preview. |
| Threshold and stop rules | Threshold tuning guide | Which mistakes reach customers, which safe work stays stuck, and when the action should remain manual. |
| Receipt and rollback | Agent receipt template | Trigger, sources, model output, policy check, reviewer, final action, version, rollback path. |
| Evidence status | Security review before access | Decision language: approve, revise, shadow longer, stop, or keep draft-only. |
The packet should change the decision
A packet that only describes the demo is decoration. A useful packet changes the permission conversation.
If the source boundary is narrow, the action is draft-only, the reviewer sees source evidence, and the receipt has a rollback path, a pilot may be reasonable. If the workflow asks for broad CRM access, hides vendor/model exposure, sends customer messages without approval, and cannot reconstruct a run, the answer should be no or not yet.
The packet does not make the workflow safe. It makes the risk visible enough for the right person to own the next decision.
A demo is not enough evidence
Stop before expanding permission when any of these are missing:
- No named business owner for the workflow.
- The source list says CRM or inbox but not the exact records and fields.
- Excluded data is blank.
- The workflow can send, update, publish, refund, delete, or change access without a reviewer.
- Vendor/model exposure is described as internal even though data leaves the system.
- The reviewer sees a polished draft but not the sources, policy rule, or execution preview.
- A threshold can move work out of review without an audit sample.
- Receipts do not include source IDs, reviewer decision, final action, and rollback path.
- Nobody owns correction if the workflow acts on the wrong evidence.
Mini example
A filled packet is easier to review than a promise
For a support-triage workflow, the first packet might stay deliberately narrow: triage and draft replies for new support tickets; draft-only with reviewed send; allowed sources limited to the current ticket, plan tier, approved KB excerpt, and most recent same-account support note; no payment card data, credentials, unrelated customer records, legal notes, or broad CRM exports.
The support lead reviews the first 50 tickets and every refund, security, legal, or cancellation mention. Receipts include ticket ID, run ID, sources shown, policy check, reviewer edits, final action, timestamp, and rollback link. Decision: pilot as draft-only; revisit internal auto-tagging after the first sample.
Copy the packet for one workflow
Use the packet before granting source access, write permission, customer-facing action, public publishing, money movement, access changes, regulated work, or reduced review.
Copy the evidence packetMap one workflow boundary with BaristaLabs
If the workflow is real but the packet is incomplete, BaristaLabs can help define the source boundary, approval gate, receipt fields, stop rules, and first pilot evidence for one workflow.
Map one workflow evidence packetRelated artifacts
Related BaristaLabs artifacts
AI workflow controls
See how workflow boundary, data boundary, policy, queue, receipts, evals, observability, and rollback fit together.
Open artifactSecurity review worksheet
Define source systems, fields, excluded data, credentials, vendor/model exposure, retention, and open review questions.
Open artifactApproval queue guide
Design the reviewer surface around proposed action, source evidence, policy rule, risk reason, decisions, and receipt.
Open artifactAgent receipt template
Define the run-level record before the workflow acts or asks for approval.
Open artifactApproval policy template
Write allowed reads, draft-only actions, approval-required actions, prohibited actions, escalation triggers, receipts, and rollback owner.
Open artifactBuild an approval queue before the agent
Separate proposed action from execution before the system changes records or reaches customers.
Open artifactAgent receipts log customer work
Make each run reconstructable enough to answer what the agent saw, decided, touched, and how to undo it.
Open artifactPrecision and recall in approval queues
Use queue thresholds as business tradeoffs, not abstract model scores.
Open artifactFAQ
Evidence packet questions
Is an AI workflow evidence packet a compliance document?
No. It is an implementation-planning artifact for one workflow. Regulated, sensitive, legal, privacy, security, financial, healthcare, HR, or compliance-heavy workflows still need the client's accountable stakeholders.
When should we make the packet?
Make it before the workflow receives source access beyond a test set, production credentials, write permission, customer-facing action, public publishing ability, money movement, access changes, regulated work, or reduced review.
How is this different from an approval policy?
The approval policy defines allowed, approval-required, and prohibited actions. The evidence packet combines that policy with the data boundary, reviewer evidence, vendor/model exposure, threshold rules, receipt fields, and rollback ownership.
Can the packet approve a workflow by itself?
No. The packet makes the decision reviewable. The business owner, technical owner, and relevant security, legal, privacy, compliance, or operations stakeholders still decide whether to approve, revise, shadow longer, or stop.
What if we cannot fill out a section?
Treat the blank as evidence. The next step may be to keep the workflow draft-only, narrow the source boundary, add reviewer evidence, run a shadow week, or stop before granting more permission.