Autonomous Action Audit Trail Generation Prompt

This prompt is for compliance engineers and platform teams who need to produce a verifiable, structured audit trail for every autonomous action an AI agent executes. Use it when your system operates under a staged release or graduated autonomy policy and you must prove to internal auditors or external regulators exactly what action was taken, at what autonomy level, with what evidence, and with what outcome. The primary job-to-be-done is post-action, record-keeping: transforming the raw context of an agent's decision and its execution into a single, immutable, and queryable record that satisfies a defined retention policy.

The ideal user is a platform engineer embedding this prompt into an agent's post-execution hook, not a human operator manually compiling a report. The required context includes the agent's full action payload, the autonomy stage and policy ID that authorized the action, the evidence the agent used to make its decision, the tool call and its result, and any human approval or override signals. This prompt is not for real-time decision-making or for generating human-facing summaries. It is a structured data generation tool designed to enforce traceability and completeness before an audit entry is written to an immutable log. Do not use this prompt for actions that were blocked or never executed; it is strictly for recording completed autonomous actions.

Avoid using this prompt when you need a conversational explanation of an agent's reasoning, a real-time blocking decision, or a user-friendly activity feed. For those cases, use a separate summarization or guardrail prompt. After generating the audit record with this prompt, you must validate its schema, confirm that all required fields are populated, and check that the recorded action is consistent with the governing autonomy policy before writing it to your append-only store. The next step is to integrate this prompt into your agent's post-action pipeline and pair it with a schema validator.

The following prompt template is designed to be wired directly into an AI harness. It instructs the model to produce a single, valid JSON audit record for a given autonomous action. The template uses square-bracket placeholders for all dynamic inputs, ensuring that the prompt can be adapted to different systems, action types, and regulatory contexts without modifying its core structure. The primary goal is to create a traceable, evidence-backed record that links an action to its autonomy stage, outcome, and the context in which it was executed.

textCopy
Generate a single, valid JSON object that serves as an audit trail record for an autonomous action. Do not include any text outside the JSON object.

## Action Context
- **Action ID:** [ACTION_ID]
- **Action Description:** [ACTION_DESCRIPTION]
- **Autonomy Stage:** [AUTONOMY_STAGE]
- **Triggering Event:** [TRIGGER_EVENT]
- **Actor/Agent ID:** [ACTOR_ID]
- **Timestamp:** [TIMESTAMP]

## Required Output Schema
{
  "audit_record": {
    "action_id": "string",
    "timestamp": "string (ISO 8601)",
    "actor": {
      "agent_id": "string",
      "autonomy_stage": "string"
    },
    "action": {
      "type": "string",
      "description": "string",
      "target_resource": "string",
      "parameters": {}
    },
    "evidence": [
      {
        "source": "string",
        "type": "string (e.g., 'log', 'metric', 'user_input')",
        "reference": "string (e.g., a link or ID)",
        "summary": "string"
      }
    ],
    "outcome": {
      "status": "string (e.g., 'success', 'failure', 'pending_approval')",
      "result_summary": "string",
      "error_code": "string or null"
    },
    "traceability": {
      "correlation_id": "string",
      "parent_action_id": "string or null",
      "stage_transition_id": "string or null"
    },
    "compliance_flags": ["string"]
  }
}

## Constraints
- [CONSTRAINTS]
- All fields in the schema must be present.
- If information for a field is not available, use `null` for scalar values or an empty array `[]` for lists.
- The `evidence` array must contain at least one entry linking the action to an observable fact.
- The `compliance_flags` array should list any regulatory or policy tags that apply to this action (e.g., 'GDPR', 'SOX', 'PII_ACCESS').

To adapt this template, replace each bracketed placeholder with data from your application's execution context. For the [CONSTRAINTS] placeholder, insert a bulleted list of domain-specific rules, such as 'Do not log raw PII in the description field' or 'The target_resource must be a valid ARN.' Before deploying, validate that the generated JSON strictly conforms to the defined schema using a JSON Schema validator in your application layer. For high-risk actions, always route the generated audit record to a human review queue for confirmation before it is committed to your system of record.

This prompt is designed to be called synchronously after every autonomous action completes, but before the next action in a sequence begins. It should be wired as a mandatory side-effect in your agent execution loop, not an optional logging step. The prompt expects a structured input payload containing the action details, autonomy stage, evidence, and outcome. You must assemble this payload from your agent's runtime state—do not rely on the model to infer missing fields. The output is a structured audit entry that must be validated for completeness before being committed to your audit store.

Integration pattern: Wrap the prompt call in a function that constructs the input from your agent's execution context. For example, in a Python agent loop: audit_entry = generate_audit_trail(action=completed_action, stage=current_stage, evidence=action.evidence, outcome=action.result). The function should handle the model call, parse the JSON response, run a completeness validator, and on failure, retry once with the validation errors injected into the prompt's [CONSTRAINTS] field. If the retry also fails, log the raw output, flag the audit record as incomplete, and escalate to a human review queue. Never silently drop a failed audit entry—missing audit trails are a compliance finding in themselves.

Validation rules to implement: Before storing the output, confirm that all required fields are present and non-null: action_id, timestamp, autonomy_level, action_description, evidence_references, outcome_status, and traceability_link. Check that evidence_references contains at least one concrete pointer (a log line, a decision ID, a tool call ID), not just a narrative summary. Validate that autonomy_level matches one of the enumerated stages defined in your staged autonomy policy. If the action was a high-risk category (e.g., data deletion, configuration change, financial commit), confirm that the audit entry includes an approval_id or override_justification field. These validators should be implemented as deterministic code, not as a second model call, to keep the audit trail's integrity verifiable.

Storage and traceability: Write each validated audit entry to an append-only store with a unique, sortable identifier. Include the prompt version and model identifier in the audit metadata so that future reviewers can reconstruct the generation context. If your system uses multiple autonomy stages, index the audit store by autonomy_level and action_category to support stage-gate evaluations and compliance sampling. For regulated environments, ensure the audit store is immutable and that any correction to an audit entry is itself recorded as a new entry referencing the original, never overwriting it.

Human review integration: When the prompt fails validation after retries, or when the action's risk score exceeds a configured threshold, route the incomplete audit entry to a human review queue. The queue item should include the raw model output, the validation errors, the original action context, and a link to any existing partial audit record. The human reviewer's completion action should generate a corrected audit entry with a reviewed_by field and a reference to the original failed generation. This keeps your audit trail complete even when the prompt underperforms, and it creates a feedback loop for improving the prompt or its input assembly over time.