Write Tool Justification Requirement Prompt

This prompt is for compliance engineers, platform architects, and security teams who need every write tool selection to be accompanied by a structured, reviewable justification. It forces the model to articulate the user request, the intended change, and why a read-only alternative is insufficient before a write tool is selected. Use this when audit trails, regulatory compliance, or internal governance require evidence that destructive operations were necessary and intentional. The output is a justification record that can be logged, reviewed, and used to demonstrate that write operations were not selected carelessly or by default.

The ideal deployment context is a backend agent or copilot where write operations carry material risk: database mutations, configuration changes, user-visible actions, or state transitions that are difficult to undo. In these environments, the prompt sits between intent classification and tool execution. When the model proposes a write tool, this prompt intercepts the selection and requires the model to produce a structured justification block before the tool call is released. The justification must cite the specific user request, describe the intended change, and explain why a read-only tool cannot satisfy the request. A generic justification such as 'user asked for it' or 'write is required' should fail validation. The justification record becomes part of the audit log alongside the tool call and its result.

Do not use this prompt for latency-sensitive user-facing copilots where a justification step would degrade the experience. In chat-based products where users expect immediate action, inserting a justification round-trip adds friction that users will resent. Instead, use a lighter-weight confirmation prompt such as the Write Operation Confirmation Prompt Template or a pre-execution guardrail like the Write Operation Pre-Flight Check Prompt. Reserve this justification prompt for backend systems, internal tools, and regulated workflows where auditability is a hard requirement and the extra latency is an acceptable cost of doing business safely.

This prompt template acts as a pre-tool-call guard for compliance-sensitive environments. It instructs the model to generate a structured justification block before selecting any tool that mutates state, writes data, or produces user-visible side effects. The justification must cite the specific user request, describe the intended change, and explain why a read-only alternative is insufficient. This record becomes part of your audit trail, giving compliance teams a traceable decision log for every write operation the model initiates.

textCopy
SYSTEM INSTRUCTION:
Before selecting any tool classified as a write, destructive, or state-mutating operation, you MUST produce a structured justification block. Do not call the tool until the justification is complete.

JUSTIFICATION FORMAT:
```json
{
  "justification": {
    "user_request_summary": "[RESTATE THE USER'S REQUEST IN ONE SENTENCE]",
    "intended_change": "[DESCRIBE WHAT WILL BE CREATED, MODIFIED, OR DELETED]",
    "affected_resources": ["[RESOURCE_ID_OR_TYPE]", "..."],
    "read_only_alternative_considered": "[NAME THE READ-ONLY TOOL OR APPROACH THAT WAS EVALUATED]",
    "why_read_only_insufficient": "[EXPLAIN WHY A READ-ONLY OPERATION CANNOT SATISFY THE REQUEST]",
    "irreversibility_assessment": "reversible | partially-reversible | irreversible",
    "confidence": 0.0_to_1.0
  }
}

RULES:

1. If no write tool is required, do not produce a justification block.
2. If the user request is ambiguous between read and write intent, default to the read-only tool and explain the limitation.
3. If confidence is below [CONFIDENCE_THRESHOLD], do not call the write tool. Instead, ask the user for clarification.
4. If the operation is irreversible, flag it explicitly and consider requesting human approval before proceeding.
5. Never use generic justifications such as "user requested it" or "write required." Each field must contain specific, auditable detail.

AVAILABLE TOOLS: [TOOLS]

USER REQUEST: [INPUT]

To adapt this template, replace [TOOLS] with your actual tool definitions, ensuring each tool has a clear operation_type field set to read, write, or destructive. Set [CONFIDENCE_THRESHOLD] to a value appropriate for your risk tolerance—0.85 is a common starting point for financial or healthcare systems. Replace [INPUT] with the user's request at runtime. If your system already classifies tools by side-effect profile, wire that classification into the operation_type field so the model can reference it directly. For high-risk domains, add a [RISK_LEVEL] placeholder that gates whether human approval is required before execution.

This prompt is not a conversational suggestion—it is a compliance gate. Wire it into your tool-call pipeline so that every write operation is preceded by a structured justification record. The model must produce the justification as a separate, parseable output before the write tool call is executed. In practice, this means your application should intercept any proposed tool call classified as write or destructive, invoke this prompt with the user request and proposed tool call as context, and block execution until a valid justification is received and logged. The justification record becomes part of your immutable audit trail, alongside the user request, the tool call arguments, the timestamp, and the session identifier.

Pipeline integration: Structure your tool-execution middleware as a three-step sequence. First, classify the proposed tool call using a read-vs-write intent classifier. If the call is read-only, proceed without justification. If the call is a write, invoke this prompt with [USER_REQUEST], [PROPOSED_TOOL_CALL] (name and arguments), and [AVAILABLE_READ_ALTERNATIVES] (a list of read-only tools that could partially satisfy the request). Parse the model's output against a strict JSON schema that requires justification_id, user_intent_summary, intended_change, read_alternative_considered, why_read_insufficient, and confidence_score. Reject any justification where why_read_insufficient is fewer than 20 words or contains generic phrases like 'user requested it' or 'write is required.' Log the justification, attach it to the tool call metadata, and only then execute the write. If the model refuses to justify or produces an invalid record, escalate to a human reviewer queue with the full context preserved.

Validation and evals: Build automated checks that run on every justification before execution. Reject justifications that cite no specific read alternative by name, that use circular reasoning ('write is needed because write is needed'), or that fail to quote the relevant portion of the user request. In your eval harness, maintain a dataset of borderline cases—requests that could plausibly be satisfied by a read operation but where a user might expect a write. Measure the false-justification rate: how often the model produces a passing justification for a write that a human reviewer would deem unnecessary. Set a threshold (e.g., <5% false-justification rate) and gate prompt changes on it. For high-risk domains such as financial transactions, PII modification, or infrastructure changes, require dual approval: the model's justification must be reviewed by a second human or a separate LLM judge before execution proceeds.

Model choice and latency: This prompt adds a synchronous step before every write operation, so latency matters. Use a fast, instruction-tuned model (e.g., GPT-4o-mini, Claude Haiku) for the justification generation, reserving larger models for the human-escalation review path. Cache the read-alternative tool list per session to avoid rebuilding it on each call. If your application issues writes in rapid succession, consider batching justification requests where the same user intent spans multiple tool calls, but never batch across different user requests or sessions—each audit record must be traceable to a single user action. Monitor justification generation latency in your observability dashboard and set an SLA (e.g., p95 < 800ms) with automatic fallback to human review if the model times out.

What to avoid: Do not treat this prompt as a checkbox that can be satisfied with boilerplate. The primary failure mode is justification drift, where the model learns to produce superficially valid justifications that pass schema validation but contain no real reasoning. Combat this by rotating eval examples, periodically reviewing a sample of production justifications, and updating the prompt's [CONSTRAINTS] to block newly observed bypass patterns. Never allow a write to proceed without a logged justification record—even in 'emergency' or 'admin override' paths, require a manual justification entry that follows the same schema. The audit trail is only as strong as its weakest entry.