VERIFIABLE WORKFLOW SPEC (VWS) — STARTER TEMPLATE

Goal
- Workflow name:
- Business owner (role, not person):
- Systems touched (e.g., Salesforce, Zendesk, GitHub, Gmail):
- What “done” means in one sentence (must be observable):

Scope & Boundaries
- In-scope actions (verbs + objects):
- Out-of-scope actions (explicitly forbidden):
- Data sources allowed (by connector):
- Data destinations allowed (email domains, ticketing projects, repos, etc.):

Permissions Model
- Identity provider integration target (Okta / Microsoft Entra ID / other):
- Roles (e.g., Viewer, Operator, Approver, Admin):
- For each role: allowed tools + allowed data + allowed environments:

Run Receipt (your product’s “ledger entry”)
Define the immutable record for every run:
- run_id (unique)
- tenant_id / workspace_id
- requester identity (user/service)
- start/end timestamps
- input payload (sanitized)
- retrieved documents list (IDs/links)
- tool calls (ordered): tool name, typed inputs, typed outputs, errors
- model(s) used per step (provider + model name)
- policy checks applied + outcomes
- approvals: who/when/what was approved
- final actions committed (what changed, where)
- rollback reference (how to undo, if supported)
- export format (JSON/CSV) and retention period

Approval Gates
List the actions that require approval:
- Money movement, refunds, invoices:
- Customer communications (email/send):
- Permission changes / access grants:
- Production changes (deploy, config, secrets):
For each gate:
- Approver role:
- What is shown to approver (diff, draft email, field changes):
- Timeout/escalation behavior:

Rollback & Safety
- What can be rolled back automatically (and how):
- What requires manual rollback instructions:
- Kill switch location (tenant/env) and who can trigger:
- Rate limits and anomaly alerts (qualitative):

Evaluation & Monitoring (no fake metrics)
- Define a small labeled set of “good runs” and “bad runs” examples (links/IDs):
- What failures must be visible in alerts (policy violation, tool error, low confidence, missing data):
- Where logs are accessible (UI + export path):

Launch Checklist
1) Receipts implemented and exportable
2) Approval gates enforced for high-risk actions
3) Tenant isolation verified
4) Least-privilege tool permissions verified
5) Kill switch tested
6) On-call/incident path documented