AI Automation / Workflow Systems
Design logging, monitoring, and audit systems for compliance and debugging across multiple workflows — creates accountability and traceability.
Why This Prompt Exists
When a workflow fails — or worse, processes something incorrectly — you need to know what happened. Without audit trails, you have no answers.
You get:
- no trace of what data entered a workflow (can’t reproduce failures)
- no record of what decisions were made (can’t audit compliance)
- no visibility into who triggered what (can’t assign responsibility)
- debugging blind (no logs, no evidence)
- compliance failures (regulators ask, you can’t answer)
But audit trails capture everything:
- inputs: what data entered the workflow
- decisions: what conditional branches were taken
- outputs: what data was produced
- timing: when each step happened
- actors: who or what triggered the workflow
Without audit trails, you have no accountability.
This prompt designs comprehensive audit systems for workflows.
The Prompt
Assume the role of a compliance architect who designs audit trails for workflow systems. Your task is to specify what to log, where to log it, and how long to keep it. Generate: 1. AUDIT REQUIREMENTS | Requirement | Source | Retention | Access | |-------------|--------|-----------|--------| | SOX compliance | Finance | 7 years | Restricted | | GDPR (user data) | Legal | 30 days | Restricted | | Operational debugging | Engineering | 90 days | Open | 2. LOGGED DATA PER EXECUTION **Workflow Execution Record** - workflow_id: [unique identifier] - workflow_name: [name] - execution_id: [UUID] - trigger: [webhook / schedule / manual / API] - triggered_by: [user_id or system] - start_time: [timestamp] - end_time: [timestamp] - duration_ms: [integer] - status: [success / failed / partial] **Step Records** (per step in workflow) - step_id: [order in workflow] - step_name: [action name] - input_data: [hash or truncation for PII] - output_data: [hash or truncation for PII] - error_message: [if failed] - duration_ms: [integer] **Decision Records** (for conditional branches) - branch_condition: [the condition evaluated] - branch_taken: [which path] - branch_reason: [why] 3. LOG STORAGE ARCHITECTURE - Primary store: [CloudWatch / BigQuery / Snowflake / S3] - Indexes: [execution_id, workflow_id, status, timestamp] - Retention policy: [archive after X days, delete after Y] 4. QUERY PATTERNS (for debugging) - "Show all failed executions of WF-003 in last hour" - "Show inputs for execution_id XYZ" - "Show decision path for execution_id XYZ" 5. PII HANDLING - Fields containing PII: [list] - Handling: [mask / hash / omit / store separately with access controls] - Justification: [GDPR / CCPA / internal policy] 6. AUDIT REPORTING - Who can request audit reports: [compliance, legal, security] - Report format: [CSV / JSON / PDF] - SLA for report generation: [X hours/days] 7. ALERTING ON AUDIT EVENTS - What triggers audit alerts: [e.g., "failed workflow accessing PII"] - Who is notified: [security team / compliance officer] INPUTS: Compliance requirements: [PASTE REGULATORY REQUIREMENTS (GDPR, SOX, HIPAA, etc.)] PII fields in your workflows: [E.G., "email, phone, name, address"] Debugging needs: [E.G., "Need to reprocess failed executions with original inputs"] Log storage preferences: [E.G., "Use Snowflake for long-term, CloudWatch for operational"] RULES: - Log everything needed to reproduce a failure (inputs, decisions, outputs) - Hash or mask PII in logs (compliance requirement) - Set retention periods based on regulatory requirements (not convenience) - Index query patterns (unindexed logs are useless for debugging) - Test audit recovery (can you reconstruct a failed execution from logs?) - Review audit access quarterly (prevent log creep)
How To Use It
- Log everything needed to reproduce a failure — inputs, decisions, outputs.
- Hash or mask PII in logs — compliance isn’t optional.
- Set retention periods based on regulatory requirements, not convenience.
- Index your query patterns — unindexed logs are useless for debugging.
- Test audit recovery — can you reconstruct a failed execution from logs?
- Review audit access quarterly — prevent log creep (too many people with access).
Example Input
Compliance requirements:
“GDPR (European customers), SOX (financial reporting)”
PII fields in your workflows:
“customer_email, customer_name, phone_number, billing_address”
Debugging needs:
“Engineers need to see full inputs for failed executions to reproduce bugs”
Log storage preferences:
“CloudWatch for 30 days, S3 Glacier for 7 years”
Why It Works
Most workflow systems log errors but not inputs — making failures impossible to reproduce. That’s debugging blindfolded.
This framework improves outcomes by forcing:
- audit requirement specification (what regulations apply?)
- logged data definition (what to capture per execution?)
- storage architecture design (where do logs live?)
- PII handling (compliance with data privacy)
- audit reporting (who can request logs?)
Failure modes this prevents:
- Reproduction failure — can’t see what inputs caused a bug
- Compliance violation — regulators ask for logs, you have none
- Debugging delays — hours wasted reconstructing what happened
- Accountability gaps — no record of who triggered what
This improves on: Error-only logging (useless for reproduction). Full audit trails enable post-mortem analysis.
Related to: WS-01 (Documenter) for workflow inventory; WS-06 (Dashboard) for health monitoring.
Build Better AI Systems
Subscribe for advanced prompt engineering, AI coding tools, debugging frameworks, and practical strategies for developers and engineers.