Verification Decision Log Prompt Template

This prompt is designed for audit and compliance teams who need a traceable, machine-readable record of every verification triage decision. Use it when your verification pipeline routes claims to auto-verification or human review and you must prove to internal or external auditors that routing decisions were made consistently, with documented rationale, and without reconstruction gaps. The prompt takes raw triage inputs and produces a structured log entry that includes decision rationale, routing outcome, reviewer assignment, and immutability markers. It is not a replacement for your triage logic; it is the documentation layer that makes that logic auditable.

The ideal user is an engineering lead or platform operator integrating this prompt into an existing verification pipeline. Required context includes the original claim, the evidence set considered, the triage decision (auto-verify or human review), the confidence score, and any routing rules that fired. The prompt is most effective when called immediately after a triage decision is made, ensuring the log is generated before any downstream state changes. Do not use this prompt to make the triage decision itself—it documents decisions, it does not make them. Do not use it for real-time decision-making where latency is measured in milliseconds; the log generation step adds a non-trivial model call that should be asynchronous or post-decision.

Before deploying, define the log schema your auditors require and validate that every generated log entry is complete, contains a unique and verifiable identifier, and includes a hash or checksum of the decision context to support immutability checks. The harness must reject logs with missing required fields and retry with backoff. For high-risk domains such as healthcare or finance, ensure that human review decisions are never logged without the reviewer's identity and a timestamp. The next step is to wire this prompt into your triage pipeline's post-decision hook and configure your log storage for append-only access.

This prompt template is the core instruction set for your verification decision logger. It forces the model to produce a single, structured JSON object that serves as an audit trail for a triage decision. The template is designed to be copied directly into your application's prompt layer, with square-bracket placeholders that your system must replace with live data at runtime. The output is not a conversation; it is a machine-readable log entry that must pass strict schema validation before being written to your immutable log store.

textCopy
Generate a structured JSON log entry for a verification triage decision. You are a precise logging function. Do not include any text outside the JSON object.

## Input Data
- Claim to Verify: [CLAIM_TEXT]
- Claim Context: [CLAIM_CONTEXT]
- Available Evidence Summary: [EVIDENCE_SUMMARY]
- Auto-Verification Result (if any): [AUTO_VERIFY_RESULT]
- Current Queue Priority: [QUEUE_PRIORITY]
- Applicable SLA Tier: [SLA_TIER]
- Risk Profile: [RISK_PROFILE]

## Output Schema
Produce a single JSON object conforming to this exact structure:
{
  "log_id": "[LOG_ID]",
  "timestamp_utc": "[CURRENT_TIMESTAMP]",
  "triage_input": {
    "claim_text": "[CLAIM_TEXT]",
    "claim_context": "[CLAIM_CONTEXT]",
    "evidence_summary": "[EVIDENCE_SUMMARY]",
    "auto_verify_result": "[AUTO_VERIFY_RESULT]",
    "queue_priority": "[QUEUE_PRIORITY]",
    "sla_tier": "[SLA_TIER]",
    "risk_profile": "[RISK_PROFILE]"
  },
  "decision": {
    "routing_outcome": "[ROUTING_OUTCOME]",
    "rationale": "[DECISION_RATIONALE]",
    "confidence_score": [CONFIDENCE_SCORE],
    "reviewer_assignment": "[REVIEWER_ASSIGNMENT]",
    "escalation_reason": "[ESCALATION_REASON]",
    "required_reviewer_skills": ["[SKILL_1]", "[SKILL_2]"]
  },
  "immutability_markers": {
    "log_hash": "[LOG_HASH]",
    "previous_log_hash": "[PREVIOUS_LOG_HASH]",
    "sequence_number": [SEQUENCE_NUMBER]
  }
}

## Constraints
- The `routing_outcome` field must be one of: "auto_verify", "human_review", "escalate".
- The `rationale` must explicitly reference the evidence summary and risk profile.
- If `routing_outcome` is "escalate", the `escalation_reason` field must be non-null and specific.
- The `confidence_score` must be a float between 0.0 and 1.0.
- All string values must be properly escaped for JSON.
- The `log_hash` must be a placeholder for the system-generated hash of this log entry.

To adapt this template, your application must replace every square-bracket placeholder with a real, sanitized value before sending the prompt to the model. The [LOG_ID], [CURRENT_TIMESTAMP], [LOG_HASH], [PREVIOUS_LOG_HASH], and [SEQUENCE_NUMBER] are system-generated fields that establish an immutable chain of custody. The model's job is to fill in the decision object based on the provided inputs. After receiving the model's response, your harness must validate the JSON against the schema, verify that the routing_outcome is consistent with the rationale and risk_profile, and then compute and inject the final log_hash before committing the record to your append-only log. Never rely on the model to generate the hash itself.

The Verification Decision Log prompt is not a standalone artifact; it is a component in an audit-grade pipeline. The harness must enforce immutability, completeness, and traceability from the moment a log entry is generated. Treat the prompt output as a candidate record that requires structural validation before it can be committed to the append-only log store. A wrapper function should call the model, receive the structured JSON response, and immediately validate it against a strict schema that checks for the presence of all required fields (log_id, timestamp, triage_inputs, decision_rationale, routing_outcome, reviewer_assignment), correct data types, and non-empty values for critical fields like decision_rationale. If validation fails, the harness should retry the prompt call with the validation error message appended to the [CONSTRAINTS] block, up to a maximum of two retries before flagging the entry for human review and manual log creation.

The storage layer must be an append-only system, such as a ledger database or an immutable S3 bucket with object lock enabled. The harness should generate a content hash (e.g., SHA-256) of the validated log entry and store it alongside the record. This hash acts as an immutability marker, allowing downstream audit queries to detect any post-hoc modification. The log_id should be a deterministic UUID generated from the triage inputs and a namespace UUID to prevent duplicate entries for the same verification event. The harness must check for an existing log with the same log_id before writing to enforce idempotency. For high-risk domains, the pipeline should include a synchronous or asynchronous human approval step where a reviewer confirms the log's decision_rationale and routing_outcome before the entry is finalized in the audit trail.

To ensure the logs support downstream audit queries without reconstruction gaps, the harness must log all prompt versions, model parameters, and validation failures in a separate, correlated telemetry stream. Do not rely on the model's output to be the sole record of the decision; the harness itself must capture the full context of the generation. When wiring this into a larger verification pipeline, pass the generated log_id to subsequent steps (like the Human Review Context Packaging prompt) to maintain a complete chain of custody. Avoid the failure mode of treating the log as a simple text dump; its value is realized only when the harness guarantees it is a complete, unalterable, and queryable record that can withstand auditor scrutiny.