Risk Score Justification Prompt for Audit Trails

This prompt is designed for governance and compliance engineering teams who must produce a permanent, auditable record every time an automated system makes a risk-scored decision. The core job-to-be-done is not to compute a risk score, but to generate a structured justification document that explains why a specific score was assigned, which threshold policy was applied, and what evidence supported the final outcome. The ideal user is a developer or MLOps engineer integrating this prompt into a post-decision logging pipeline, where the system already has a computed score, a policy version, and a set of evidence artifacts. The output is a timestamped justification document suitable for storage in an audit trail, ready for review by internal compliance teams or external regulators.

You should use this prompt when your system must satisfy regulatory auditors, internal model risk management (MRM) policies, or compliance reviews that require explainability and traceability for every automated risk action. This is a post-hoc justification step, not a real-time decisioning step. It assumes the risk score has already been computed by a separate model or rules engine. The prompt's value is in structuring the evidence, score components, and policy logic into a human-readable, non-repudiable record. For example, after a transaction is flagged with a composite fraud score of 850, this prompt would generate a document citing the specific features that drove the score (e.g., 'transaction velocity 3x user baseline'), the policy version that defined the 800-point escalation threshold, and the source of the evidence (e.g., 'user_profile_service:v2.1').

Do not use this prompt to compute the risk score itself, to make a real-time approval decision, or to replace a human reviewer's judgment. If you need to decide whether to escalate an action based on a threshold, use the 'Escalation Decision Prompt Based on Risk Thresholds' instead. If you need to explain a score to a human reviewer so they can take action, use the 'Risk Score Interpretation Prompt for Reviewers'. This prompt is exclusively for creating the static, evidence-backed justification record after the decision logic has executed. The next step after generating this justification is to store it immutably, link it to the decision event, and ensure it is indexed for audit queries.

This prompt template produces a timestamped, structured justification document for a single risk decision. It is designed for governance and compliance teams who need a permanent, auditable record that connects a risk score to its underlying evidence, the policy version that was in effect, and the final decision rationale. The output is intended to be stored in an audit trail system, not used as a real-time operational alert. Before using this template, ensure you have the complete risk score payload, the threshold policy that was applied, and all source evidence that contributed to the score.

textCopy
You are an audit documentation specialist. Your task is to produce a structured risk score justification document suitable for a permanent regulatory audit trail. The document must be self-contained, timestamped, and cite all evidence sources.

## INPUT DATA

### Risk Score Payload
[RISK_SCORE_PAYLOAD]

### Threshold Policy
[THRESHOLD_POLICY_VERSION]
[THRESHOLD_POLICY_DEFINITION]

### Evidence Sources
[EVIDENCE_SOURCES]

### Decision Context
[DECISION_CONTEXT]

## OUTPUT SCHEMA

Generate a JSON document conforming to this exact schema:

{
  "audit_record_id": "string, unique identifier for this justification",
  "generated_at": "ISO 8601 timestamp",
  "policy_version": "string, the version of the threshold policy applied",
  "risk_score": {
    "composite_score": "number",
    "score_range": { "min": "number", "max": "number" },
    "confidence_interval": { "lower": "number", "upper": "number", "confidence_level": "number" },
    "component_scores": [
      {
        "component_name": "string",
        "score": "number",
        "weight": "number",
        "evidence_reference_ids": ["string"]
      }
    ]
  },
  "threshold_evaluation": {
    "threshold_value": "number",
    "threshold_exceeded": "boolean",
    "comparison_detail": "string, explain how the score compares to the threshold"
  },
  "decision": {
    "action": "APPROVED | ESCALATED | BLOCKED | MANUAL_REVIEW",
    "rationale": "string, clear explanation of why this decision was reached",
    "overrides_applied": [
      {
        "override_type": "string",
        "authorized_by": "string",
        "reason": "string",
        "timestamp": "ISO 8601"
      }
    ]
  },
  "evidence_inventory": [
    {
      "evidence_id": "string",
      "source_system": "string",
      "data_type": "string",
      "relevance": "string, why this evidence was considered",
      "retrieved_at": "ISO 8601"
    }
  ],
  "completeness_checks": {
    "all_components_documented": "boolean",
    "all_evidence_cited": "boolean",
    "policy_version_recorded": "boolean",
    "decision_rationale_present": "boolean",
    "missing_information_flags": ["string"]
  }
}

## CONSTRAINTS

- Every component score must reference at least one evidence source by ID.
- The decision rationale must explicitly connect the composite score, the threshold, and any overrides to the final action.
- If any completeness check fails, include a specific flag in `missing_information_flags` describing what is absent.
- Do not invent evidence. If an expected source is missing, flag it rather than fabricating data.
- The `generated_at` timestamp must be the current time.
- Use only the provided [EVIDENCE_SOURCES] and [RISK_SCORE_PAYLOAD]. Do not introduce external knowledge.

## OUTPUT FORMAT

Return only the JSON object. No markdown fences, no surrounding text.

To adapt this template for your environment, replace the square-bracket placeholders with actual data from your risk pipeline. The [RISK_SCORE_PAYLOAD] should contain the full structured output from your risk scoring model, including all component scores and metadata. The [THRESHOLD_POLICY_VERSION] and [THRESHOLD_POLICY_DEFINITION] must capture exactly which policy was in effect at decision time—this is critical for audit defensibility. The [EVIDENCE_SOURCES] should be a structured list of every data point, log entry, or signal that fed into the score. If your system applies overrides, populate the overrides_applied array with the authorization details; otherwise, leave it empty. After generation, validate the output against the schema and confirm that every completeness check passes before committing the record to your audit store.

This prompt is designed to be the final step in an automated risk decision pipeline, not a standalone chat interaction. It should be invoked only after a risk score has been computed by your primary scoring model or rules engine. The application must supply the computed score, its feature-level components, the threshold policy version in effect, and all evidence sources as structured inputs. The prompt's job is to synthesize these inputs into a human-readable, timestamped justification document suitable for permanent audit trails. Do not use this prompt to compute the risk score itself; it is a documentation and explanation generator, not a scoring engine.

Wire the prompt into a post-decision processing queue. After a transaction or event is scored and a decision (approve, deny, escalate) is made, serialize the decision context into the prompt's placeholders: [RISK_SCORE], [SCORE_COMPONENTS], [THRESHOLD_POLICY], [EVIDENCE_SOURCES], and [DECISION]. The application should enforce a strict schema for these inputs before the prompt is called. For example, [SCORE_COMPONENTS] should be a list of objects with feature_name, value, and contribution fields. Validate this schema in application code before model invocation. On the output side, parse the generated justification document and validate its structure: it must contain a timestamp, a decision summary, a score breakdown, a policy reference, and an evidence inventory. If the output fails structural validation, retry once with a more explicit [OUTPUT_SCHEMA] constraint. If it fails again, log the failure and flag the record for manual review. For high-stakes regulatory environments, always route the final generated justification to a human reviewer for approval before it is committed to the immutable audit log.

Model choice matters for consistency. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, and set a low temperature (0.0–0.2) to maximize deterministic, repeatable justifications. Store the full prompt, the model response, and the validation result in your observability platform. This trace is critical for debugging justification drift and for demonstrating to auditors that the explanation was generated faithfully from the input data. Avoid using this prompt in streaming mode; the entire document must be generated and validated before it is persisted. The next step after implementation is to build an eval set of known risk scenarios with expected justification properties and run regression tests whenever the prompt or the underlying scoring model changes.