Webhook Audit Log Documentation Prompt

This prompt is for compliance engineers, platform security leads, and integration architects who need to produce documentation for webhook audit trails. The job-to-be-done is converting raw event delivery records, retention policies, and query interface specs into a clear, auditable document that explains what events are logged, how long logs are retained, how authorized parties can query them, and what export formats are available. The reader of the output is typically an auditor, a security reviewer, or a customer's compliance team who needs to verify that the platform maintains a complete, tamper-evident record of all webhook activity.

Use this prompt when you have concrete system details—such as the exact fields captured in delivery attempt records, the retention period in days, the query API or UI endpoints, and the supported export formats (CSV, JSON, NDJSON, Parquet). The prompt is designed to enforce completeness: it will flag missing information about consumer acknowledgment trails, failed delivery records, and the chain of custody for log integrity. Do not use this prompt to generate a generic security whitepaper or to document real-time webhook delivery semantics; those belong in separate playbooks for delivery guarantees and signature verification. This prompt assumes the audit log is a distinct, queryable system of record, not a live event firehose.

Before running this prompt, gather your raw inputs: the event envelope schema, the list of auditable event types, the retention policy document, the query interface description (API or UI), and any compliance framework requirements (SOC 2, PCI DSS, HIPAA) that the audit log must satisfy. The prompt will ask you to specify these as [INPUT] and [CONTEXT] placeholders. If any of these inputs are missing, the generated documentation will contain explicit placeholders and warnings rather than hallucinated details. After generation, always have a compliance reviewer verify the output against the actual system behavior, especially the completeness of delivery attempt records and the accuracy of retention claims.

This template generates structured audit log documentation from your webhook event catalog, delivery infrastructure details, and compliance framework requirements. It is designed for compliance engineers and platform teams who need to document the complete audit trail—from event emission through delivery attempts to consumer acknowledgment—in a format that satisfies SOC 2, HIPAA, or PCI DSS evidence requirements. Before using this prompt, you must have your event type catalog, delivery guarantee specifications, retry policy, and any regulatory retention requirements ready. Do not use this prompt if you lack concrete delivery infrastructure details or if your webhook system does not yet have defined event types and delivery semantics.

textCopy
You are a compliance documentation engineer specializing in webhook audit trails. Your task is to produce a complete audit log documentation section from the provided inputs.

## INPUTS
[EVENT_CATALOG]
[DELIVERY_GUARANTEE_SPEC]
[RETRY_POLICY_SPEC]
[CONSUMER_ACKNOWLEDGMENT_PROTOCOL]
[COMPLIANCE_FRAMEWORKS]
[RETENTION_REQUIREMENTS]
[EXPORT_FORMATS]
[QUERY_INTERFACE_SPEC]

## OUTPUT_SCHEMA
Produce a markdown document with these sections:
1. **Audit Event Catalog**: For each event type in [EVENT_CATALOG], document the auditable fields, timestamp precision, and source system identifier.
2. **Delivery Attempt Records**: Document the structure of each delivery attempt record, including timestamp, HTTP status code, response body capture policy, and correlation ID linking attempts to the original event.
3. **Consumer Acknowledgment Trail**: Document how consumer HTTP responses are captured, stored, and linked to delivery attempts. Specify the retention period for acknowledgment records.
4. **Log Retention Policy**: Specify retention periods for each log category, aligned with [RETENTION_REQUIREMENTS] and [COMPLIANCE_FRAMEWORKS]. Include data lifecycle stages: hot storage, warm storage, cold archive, and deletion.
5. **Query Interface Documentation**: Document available query parameters, filtering capabilities, time-range selection, and rate limits for the audit log query interface described in [QUERY_INTERFACE_SPEC].
6. **Export Formats**: Document each export format from [EXPORT_FORMATS], including schema, field mappings, compression options, and integrity verification methods.
7. **Completeness Guarantees**: Document what the audit log guarantees to capture, what gaps may exist, and how gaps are detected and reported.
8. **Compliance Mapping**: Map each requirement from [COMPLIANCE_FRAMEWORKS] to the specific audit log features that satisfy it.

## CONSTRAINTS
- Every auditable field must include its data type, source, and whether it is guaranteed or best-effort.
- For each delivery attempt, document whether the payload body is captured in the audit log or must be retrieved from a separate system.
- Flag any gaps between [DELIVERY_GUARANTEE_SPEC] and what the audit log actually records.
- Use precise timestamp formats (RFC 3339) and specify timezone handling.
- If [RETRY_POLICY_SPEC] includes dead-letter queue behavior, document how DLQ events appear in the audit log.
- For [COMPLIANCE_FRAMEWORKS], cite specific control references where applicable.

## VALIDATION CHECKLIST
After generating the document, self-check for:
- [ ] Every event type from [EVENT_CATALOG] appears in the audit event catalog
- [ ] Delivery attempt fields cover all states: success, failure, retry, timeout, and DLQ
- [ ] Consumer acknowledgment records include both success and rejection scenarios
- [ ] Retention periods are specified for each log category
- [ ] Query interface covers all filterable fields mentioned in the document
- [ ] Export formats include integrity verification method
- [ ] Compliance mapping is complete and traceable
- [ ] No ambiguous language about completeness guarantees

## OUTPUT FORMAT
Return the complete audit log documentation as a single markdown document. Use tables for field catalogs. Use code blocks for query examples and export schemas. Begin each section with a level-2 heading.

After copying this template, replace each square-bracket placeholder with your actual specifications. The [EVENT_CATALOG] should include every event type your system emits, with field-level detail. The [COMPLIANCE_FRAMEWORKS] placeholder accepts a list of frameworks and their specific control requirements—for example, 'SOC 2 CC6.1, CC6.6, CC7.2' or 'HIPAA 164.312(b)'. If your system does not support a particular feature mentioned in the template, replace the relevant section with an explicit statement of non-support rather than omitting it. For high-risk deployments, run the generated document through a human compliance review before publication, and validate that the documented audit trail matches actual log output by sampling production records.

This prompt is designed to be called programmatically as part of a documentation generation or compliance review pipeline, not as a one-off chat interaction. The primary integration point is a function that receives structured webhook event definitions, delivery logs, and retention policies as input, then invokes the LLM with this prompt template to produce a draft audit log document. The output should be treated as a draft for human review, never as a published compliance artifact without approval. Wire the prompt into a workflow that validates the output against a predefined schema before surfacing it to a compliance engineer or technical writer.

The implementation should follow a validate-generate-validate pattern. First, validate that all required inputs are present: event catalog entries with unique IDs, delivery attempt records with timestamps and status codes, consumer acknowledgment trails, and the retention policy specification. If any required input is missing, abort and return a structured error to the caller rather than generating incomplete documentation. After the model responds, parse the output and validate that every referenced event type exists in the input catalog, that all retention periods are expressed in concrete units (days, months, years), and that the document includes the required sections: auditable event inventory, log retention policy, query interface description, export format specification, and completeness statement. Use a deterministic post-processing step to check for placeholder text or unresolved tokens before the document enters the review queue.

For production deployment, log every generation attempt with the prompt version hash, input event count, model used, generation latency, and validation pass/fail status. If the output fails validation, implement a single retry with a more explicit error message appended to the prompt context, then escalate to a human reviewer if the second attempt also fails. Choose a model with strong structured output capabilities and a context window large enough to hold your full event catalog plus the prompt template. Avoid using this prompt with models that have known hallucination tendencies on compliance topics. The final approved document should be stored with a generation timestamp, reviewer identity, and the exact prompt version used, creating a clear audit trail for the documentation process itself.