Business Rule Validation Audit Prompt for Tool Arguments

This prompt is designed for compliance engineers and platform teams who must enforce configurable business rules before a tool call is executed. Its core job is to act as a pre-execution guardrail, validating tool call arguments—such as spend limits, date ranges, or user eligibility—against a provided policy document. The primary output is a structured, pass/fail audit record with explicit rule references, creating a reviewable artifact that proves a validation check occurred. Use this when executing a tool call without validation would violate a domain-specific business constraint, and you need a durable, queryable record for internal policy compliance checks or external auditor review.

Deploy this prompt in workflows where the cost of an invalid tool execution is high, such as financial transactions, healthcare operations, or mutating infrastructure changes. It is not a replacement for static, code-level input validation (type checks, regex, required fields) but rather a complement for semantic, policy-based rules that are too complex or dynamic to encode in traditional logic. For example, a static check can ensure a 'spend_limit' field is a float, but this prompt can verify that the limit does not exceed a user's tiered approval threshold as defined in a natural language policy document. The prompt requires a clear [POLICY_DOCUMENT] and the proposed [TOOL_ARGUMENTS] as input. It is critical to log the full output—including the rule_references and audit_timestamp—to an append-only store for non-repudiation.

Avoid using this prompt for real-time, latency-sensitive applications where a sub-100ms decision is required; a model-based check introduces latency and cost that may be unacceptable for high-throughput, low-risk operations. Do not use it as the sole defense against prompt injection or malicious argument construction—assume that a compromised upstream prompt could attempt to social-engineer the validation step. Always pair this with a human-in-the-loop approval gate for high-severity rule violations, where the prompt's output should trigger a review queue rather than an automatic block. Before putting this into production, build a test harness with policy-argument pairs that cover edge cases like conflicting rules, missing fields, and ambiguous policy language to measure the prompt's precision and recall on violation detection.

This prompt template is designed to be placed as a pre-execution validation step in your tool-calling pipeline. It receives the proposed tool name, its arguments, and a set of configurable business rules, then produces a structured audit record indicating whether the arguments comply with each rule. The output includes rule references, pass/fail status, and violation details, making it suitable for compliance review and internal policy enforcement before any side-effect operation proceeds.

textCopy
You are a business rule validation auditor. Your task is to validate the arguments of a proposed tool call against a set of configurable business rules and generate a structured pass/fail audit record.

## INPUT
- Tool Name: [TOOL_NAME]
- Tool Arguments: [TOOL_ARGUMENTS]
- Business Rules: [BUSINESS_RULES]
- Execution Context: [EXECUTION_CONTEXT]

## BUSINESS RULES FORMAT
Each rule is provided as a JSON object with the following fields:
- rule_id: unique identifier for the rule
- rule_description: human-readable description of what the rule enforces
- field_path: dot-notation path to the argument field being validated (e.g., "amount" or "user.tier")
- operator: comparison operator (one of: less_than, less_than_or_equal, greater_than, greater_than_or_equal, equals, not_equals, in_list, not_in_list, matches_regex, exists, not_exists, between_dates, before_date, after_date)
- value: the threshold or comparison value (type depends on operator)
- severity: one of "blocker" or "warning"
- policy_reference: link or identifier for the internal policy document

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "audit_id": "string, unique identifier for this audit record",
  "timestamp": "ISO 8601 timestamp of validation",
  "tool_name": "string, the tool being validated",
  "overall_result": "pass" | "fail" | "warning",
  "rules_checked": [
    {
      "rule_id": "string",
      "rule_description": "string",
      "field_path": "string",
      "actual_value": "the value found in the arguments at field_path, or null if missing",
      "expected_constraint": "string describing the constraint",
      "result": "pass" | "fail" | "warning" | "skipped",
      "severity": "blocker" | "warning",
      "policy_reference": "string",
      "violation_detail": "null if pass, otherwise a clear description of the violation"
    }
  ],
  "blocker_count": 0,
  "warning_count": 0,
  "human_review_required": false,
  "summary": "string, one-sentence summary of the audit outcome"
}

## CONSTRAINTS
- Validate every rule in [BUSINESS_RULES] against the corresponding field in [TOOL_ARGUMENTS].
- If a field_path does not exist in the arguments, mark the rule as "fail" with violation_detail explaining the missing field.
- If any rule with severity "blocker" fails, set overall_result to "fail" and human_review_required to true.
- If only "warning" severity rules fail, set overall_result to "warning" and human_review_required to false.
- If all rules pass, set overall_result to "pass" and human_review_required to false.
- Do not invent rules. Only validate the rules provided in [BUSINESS_RULES].
- Do not modify the tool arguments. This is a read-only validation step.
- Include the exact policy_reference from each rule in the output.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with your application's concrete values. [TOOL_NAME] and [TOOL_ARGUMENTS] should come from the model's proposed tool call before execution. [BUSINESS_RULES] should be loaded from your policy configuration store—keep these as structured JSON so they can be versioned and audited independently of the prompt. [EXECUTION_CONTEXT] can include user role, session scope, or request origin to enable context-aware rules. [EXAMPLES] should contain at least two few-shot demonstrations: one showing a clean pass and one showing a blocker failure with the correct output shape. [RISK_LEVEL] should be set to "high" if the tool performs mutating operations, triggering the human_review_required flag on any blocker failure.

Before deploying this prompt, wire the output through a JSON schema validator to catch malformed audit records. If the model returns invalid JSON, retry once with the validation error included in the prompt context. For high-risk domains such as financial transactions or healthcare operations, always route audit records with human_review_required: true to a review queue and log the full audit payload immutably. Do not execute the tool until the audit record confirms overall_result is "pass" or a human reviewer has approved the override.

This prompt is designed to sit as a synchronous pre-execution guardrail between the tool selection layer and the tool execution layer. In a typical implementation, the AI system selects a tool and constructs its arguments, but before the tool is invoked, the arguments are passed to this validation prompt along with the active business rules. The prompt returns a structured pass/fail audit record. If the record indicates a failure, the system must block execution and either request corrected arguments from the model, escalate to a human reviewer, or log the violation and halt. This is not a post-hoc audit prompt—it is a blocking control point.

Wire the prompt into your application as a middleware function or a pre-execution hook. The function should accept the proposed tool name, the full arguments object, the user or session context (role, permissions, department), and the applicable rule set. The rule set should be injected as [RULES] in the prompt template, formatted as a structured list of conditions with rule IDs, descriptions, and failure severity levels. The function should call the LLM with low temperature (0.0–0.1) to maximize deterministic validation, and it must parse the output against a strict JSON schema that includes validation_result (pass/fail), rule_checks (array of per-rule results with rule ID, passed boolean, and evidence), and blocking_violations (array of failed rules that require execution to stop). If the model returns malformed JSON, retry once with a repair prompt; if it fails again, treat it as a system error and block execution by default—never execute a tool call when the guardrail is unavailable.

For high-risk domains such as financial transactions or healthcare operations, add a human-in-the-loop approval step for any blocking_violations with severity CRITICAL. The audit record should be persisted to an immutable log before any human review, capturing the full prompt input, the model's response, the reviewer's decision, and any argument overrides. Use a correlation ID to link the validation event to the downstream tool execution log and any subsequent error or incident records. Avoid implementing this as a purely advisory log—if the prompt is used only for post-execution review, it cannot prevent the violation it was designed to catch. The implementation must enforce that a fail result or a guardrail error prevents tool execution, and that this enforcement is tested in your integration suite with both valid and intentionally violating arguments.