01
Source
Systems allowed, fields allowed, exclusions, credential model, vendor/model exposure.
Responsible AI resource
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
Evidence packet
Sample packetReviewer decision
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
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.
01
Systems allowed, fields allowed, exclusions, credential model, vendor/model exposure.
02
Draft-only, approval-required, prohibited, escalation triggers.
03
Role, source excerpts, policy rule, risk reason, execution preview, available decisions.
04
Manual lane, automatic lane if any, expensive mistake, stop condition, audit sample.
05
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
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. |
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.
Mini example
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.
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 packetIf 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
See how workflow boundary, data boundary, policy, queue, receipts, evals, observability, and rollback fit together.
Open artifactDefine source systems, fields, excluded data, credentials, vendor/model exposure, retention, and open review questions.
Open artifactDesign the reviewer surface around proposed action, source evidence, policy rule, risk reason, decisions, and receipt.
Open artifactDefine the run-level record before the workflow acts or asks for approval.
Open artifactWrite allowed reads, draft-only actions, approval-required actions, prohibited actions, escalation triggers, receipts, and rollback owner.
Open artifactSeparate proposed action from execution before the system changes records or reaches customers.
Open artifactMake each run reconstructable enough to answer what the agent saw, decided, touched, and how to undo it.
Open artifactUse queue thresholds as business tradeoffs, not abstract model scores.
Open artifactFAQ
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.
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.
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.
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.
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.