Tool Call Audit Record Generation Prompt Template

This prompt is for compliance engineers and AI governance teams who need every tool call in a production AI system to generate a structured, reviewable audit record. Use it when opaque tool selection creates audit gaps that block deployment in regulated environments. The prompt produces a JSON record containing the tool name, full arguments, a timestamp, a selection rationale, and the execution context. It is designed to be called as a post-processing step after a tool is selected but before it is executed, or as a logging wrapper in your observability pipeline.

The ideal user has a tool selection event—either from a model's function call or from an application-level router—and needs to convert that event into a compliance-grade artifact. You must provide the selected tool name, the full arguments payload, the user's original intent or query, and any active policy constraints. The prompt will not make the tool call itself; it only documents the decision. This separation is critical for audit integrity: the record is generated before execution, so it cannot be retroactively altered by a side effect.

Do not use this prompt for real-time decision-making on the critical path if latency is a primary concern. The generation step adds overhead, and in high-throughput systems, you should run it asynchronously or in a logging sidecar. Do not use it as a substitute for execution-level logging—your application must still capture the actual tool response, status codes, and timings. This prompt covers the decision record, not the execution trace. If you need to capture both, pair it with a Post-Execution Tool Call Review Prompt. Finally, do not use this prompt when the tool selection is deterministic application logic with no model involvement; a simple structured log is sufficient and cheaper.

The following prompt template is designed to be pasted directly into your system prompt, a dedicated audit step, or a post-tool-call processing pipeline. Its purpose is to produce a single, structured audit record that captures why a tool was selected, what arguments were passed, and what context surrounded the call. This record is essential for SOC 2 compliance, internal policy alignment, and debugging opaque tool selection in production. The template uses square-bracket placeholders that your application must populate with live data before sending the request to the model. Do not send the prompt with unresolved placeholders; doing so will produce an invalid audit record.

textCopy
Generate a structured audit record for the following tool call. Adhere strictly to the output schema and constraints.

[INPUT]
User Intent: [USER_INTENT]
Conversation Context (last 5 turns): [CONVERSATION_CONTEXT]
Available Tools with Descriptions: [AVAILABLE_TOOLS]
Active Policies: [ACTIVE_POLICIES]
Session Metadata: [SESSION_METADATA]

[TOOL_CALL_TO_AUDIT]
Selected Tool: [SELECTED_TOOL_NAME]
Arguments: [TOOL_ARGUMENTS]
Timestamp: [EXECUTION_TIMESTAMP]

[OUTPUT_SCHEMA]
{
  "audit_record": {
    "audit_id": "string, unique identifier for this audit entry",
    "timestamp": "string, ISO 8601 format, must match [EXECUTION_TIMESTAMP]",
    "tool_call": {
      "tool_name": "string, must match [SELECTED_TOOL_NAME]",
      "arguments": "object, must match [TOOL_ARGUMENTS]",
      "argument_sources": {
        "[argument_name]": "string, one of: 'user_input', 'conversation_context', 'system_default', 'model_inference'"
      }
    },
    "selection_rationale": {
      "primary_reason": "string, concise explanation of why this tool was selected",
      "evidence_from_input": "string, specific quote or reference from [USER_INTENT] or [CONVERSATION_CONTEXT]",
      "alternatives_considered": ["string, names of other tools that were not selected"],
      "policy_compliance": "string, explanation of how this selection aligns with [ACTIVE_POLICIES]"
    },
    "execution_context": {
      "session_id": "string, from [SESSION_METADATA]",
      "user_id": "string, from [SESSION_METADATA]",
      "pre_execution_state": "string, summary of relevant state before the call"
    },
    "completeness_checks": {
      "all_required_args_present": "boolean",
      "no_undefined_args": "boolean",
      "policy_violation_flag": "boolean",
      "missing_context_flag": "boolean"
    }
  }
}

[CONSTRAINTS]
1. The `audit_id` must be a UUID v4 string.
2. Every argument in `tool_call.arguments` must have a corresponding entry in `tool_call.argument_sources`.
3. `selection_rationale.evidence_from_input` must be a verbatim quote from the provided context; do not paraphrase.
4. If no alternatives were considered, `alternatives_considered` must be an empty array.
5. If `policy_violation_flag` is true, you must append a `policy_violation_detail` field to the `completeness_checks` object explaining the violation.
6. Do not invent any information not present in the provided context.
7. Output only the valid JSON object. No markdown, no commentary.

To adapt this template for your application, replace each [PLACEHOLDER] with live data from your orchestration layer. [USER_INTENT] should be a concise summary of the user's goal, not the raw transcript. [AVAILABLE_TOOLS] must be a serialized list of tool definitions, including descriptions and parameter schemas, as the model needs this to reason about alternatives. [ACTIVE_POLICIES] can include rules like 'never call a write tool without explicit user confirmation' or 'prefer read-only tools for data retrieval.' The [OUTPUT_SCHEMA] section is designed to be parsed by a downstream validator; ensure your application enforces the schema after the model responds. For high-risk domains, always route the generated audit record to a human review queue before archiving it as a compliance artifact.

The Tool Call Audit Record Generation Prompt is not a standalone artifact—it is a component inside a larger observability pipeline. In production, you will call this prompt immediately after a tool selection decision is made but before the tool is executed. This placement ensures the audit record captures the pre-execution intent, which is critical for compliance review and incident analysis. The prompt expects a structured input containing the user request, conversation context, selected tool name, proposed arguments, and the active policy or risk level. You must assemble this input from your application state, not from the model's memory, to avoid context drift between the selection step and the audit generation step.

Wire the prompt into a pre-execution hook in your tool-calling middleware. After the model returns a tool call, extract the tool_name and arguments, then invoke the audit prompt with those values plus the original user input and any session metadata. The prompt returns a JSON audit record. Before storing or forwarding this record, run a schema validator against the expected output shape—check that audit_id, timestamp, tool_name, arguments, selection_rationale, and compliance_flags are all present and correctly typed. If validation fails, retry the prompt once with a more explicit error message appended to the input. If it fails again, log the failure and escalate to a human review queue rather than silently proceeding with an incomplete audit record. This is especially important in SOC 2 and internal policy alignment contexts where missing audit fields are themselves a compliance gap.

For model choice, prefer a model with strong structured output support and low latency, since this prompt runs synchronously in the tool-call path. GPT-4o and Claude 3.5 Sonnet are good defaults. Enable structured outputs mode (JSON mode with a supplied schema) to reduce post-generation repair. Set temperature=0 to maximize determinism for audit records. Log every invocation—including input, output, validation result, and latency—to your observability platform. Attach the generated audit_id to the downstream tool execution span so you can correlate the audit record with the actual tool result. If the tool execution fails or produces unexpected output, the audit record becomes the baseline for your post-execution review prompt. Do not skip audit generation for read-only tools; data access patterns are often the most scrutinized in privacy audits, and an audit gap here will block production deployment in regulated environments.