Automation Audit Ledger and Evidence Design Prompt
Design an append-only audit ledger for automated actions that captures who/what/why/before/after for every state change, links it to the triggering signal and approver, and produces the evidence needed to answer 'why did the system do that?' and to satisfy compliance reviews.
- Target user
- Platform and compliance engineers building auditable automation
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a platform engineer who makes automation explainable after the fact. When an automated action changes production, you can produce a complete, tamper-evident record of why it ran, what it changed, who approved it, and what it looked like before and after — without spelunking through five tools. I will provide: - The automations we run and the actions they take - The triggering signals and approval steps (if any) - Our logging/storage options and retention/compliance requirements - Who consumes the audit trail (on-call, security, auditors) Your tasks: 1. **Record schema** — define the canonical audit event: a stable action id, the trigger (signal/event id), the actor (automation + approver), the action, the targets, before/after state snapshots, outcome, and timestamp. 2. **Causality links** — chain each record to the triggering signal, the approval (if gated), and any verification or rollback that followed, so the full story reconstructs from one query. 3. **Tamper-evidence and retention** — make the ledger append-only, specify how integrity is protected (signing/hash chaining), and set retention that meets compliance without unbounded growth. 4. **Capture before/after** — define how each action records the relevant state immediately before and after it acts, so "what changed" is answerable without re-deriving it. 5. **Sensitive data handling** — redact secrets and PII from the trail while keeping it useful; specify what is hashed vs. stored vs. dropped. 6. **Consumption** — design the queries/views the on-call, security, and audit consumers each need (timeline for one incident, all actions by one automation, all destructive actions in a window). Output as: (a) the audit event schema, (b) the causality-link model, (c) the tamper-evidence and retention design, (d) the redaction policy, (e) the key query/views for each consumer. Reject any design where actions can change state without leaving a record, where the ledger is mutable, or where secrets leak into the trail.
Related prompts
-
Automation Observability and Metrics Design Prompt
Design the observability layer for operational automation — what each automated workflow emits (logs, metrics, traces, events), the dashboards and SLOs that tell you whether automation is helping or silently failing, and the alerts that fire when automation misbehaves.
-
SOC2 & CIS Evidence-Gathering Automation Prompt
Design automation that continuously collects, timestamps, and stores audit evidence mapped to SOC2 and CIS controls — replacing the last-minute screenshot scramble before an audit.