Skip to content This library is free, offered as dana. If it helps your work, donate here →

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Case decision rationale logger

Structures the reasoning behind an account or case decision into a consistent, audit-ready log entry — capturing the decision, the facts relied on, the policy or regulation applied, the alternatives considered, and the…

download .md

Purpose

Convert a case decision and its supporting reasoning into a single, standardized, audit-ready log entry that shows what was decided, on what facts, under which policy, and by whom — so any reviewer can reconstruct the decision months later without re-interviewing the analyst. Solves the recurring exam and audit problem of decisions that were correct but poorly documented.

When to Use

Invoke this skill when the user asks to:

  • Log the rationale for an account approval, denial, or conditional approval
  • Document why a case was escalated, frozen, restricted, or closed
  • Record the reasoning behind a KYC/AML disposition or SAR decision
  • Standardize an existing decision note into an audit-ready format
  • Create a defensible paper trail for a discretionary or exception-based decision
  • Reconstruct a decision record from scattered notes before an internal audit or exam

Inputs Required

Before starting, collect:

  • Case identifier: Account number, case ID, or reference (masked if required by policy)
  • Case type: e.g., new account, periodic review, transaction alert, exception request, offboarding
  • Decision made: The specific outcome (approved, denied, escalated, restricted, closed, no action, etc.)
  • Facts relied on: The evidence, data points, or observations that drove the decision
  • Policy/regulation applied: The internal policy section, regulatory obligation, or risk rating that governs this decision
  • Alternatives considered: Other outcomes weighed and why they were rejected
  • Decision-maker & approver: Who decided and who signed off, with role/authority level

If the approver or policy citation is missing, produce the entry with a clearly marked "PENDING — REQUIRED BEFORE CLOSE" flag rather than inventing a value.

Instructions

Step 1: Normalize the Decision Statement

Rewrite the outcome into a single unambiguous sentence in the form: "[Role] [decided/recommended] to [action] [case reference] effective [date] because [primary driver]."

  • State the decision, not the process that led to it
  • Use the firm's exact outcome vocabulary (Approved / Denied / Escalated / Restricted / Closed — No Action / EDD Required)
  • Never soften a denial or restriction with hedging language

Step 2: Log the Facts Relied On

List each material fact as a discrete, verifiable line item. For each fact:

  • State the fact objectively (no interpretation)
  • Note the source (system of record, document, screening tool, customer statement)
  • Note the date observed and whether it was verified or unverified
  • Separate facts from inferences — inferences belong in Step 4, not here

Step 3: Cite the Governing Policy or Regulation

Map the decision to its authority:

  • Name the specific internal policy section, procedure number, or risk-rating threshold
  • Name any external obligation (e.g., BSA/AML, KYC/CDD, OFAC, Reg-specific requirement) by its actual reference
  • State the required standard the decision must meet, then confirm whether the facts meet it
  • If discretion was exercised, cite the policy that grants that discretion and the authority level required

Step 4: Document the Reasoning Chain

Show the logical path from facts to decision in 3–6 numbered steps:

  1. What the facts, taken together, indicate
  2. How that maps to the governing standard
  3. What risk was present and how it was assessed
  4. Why the standard is met or not met - Every inference must trace back to a fact logged in Step 2

Step 5: Record Alternatives Considered and Rejected

For each realistic alternative outcome:

  • State the alternative
  • State the specific reason it was rejected (facts + policy, not preference) This is the section examiners scrutinize most — it proves the decision was reasoned, not reflexive.

Step 6: Capture Conditions, Follow-ups, and Sign-off

  • Conditions: Any requirements attached to the decision (e.g., 6-month review, documentation to obtain)
  • Follow-up trigger & date: What event or date reopens the case
  • Decision-maker: Name/ID, role, authority level
  • Approver: Name/ID, role, and confirmation that authority level was sufficient for this decision type
  • Flag any missing required field as "PENDING — REQUIRED BEFORE CLOSE"

Output Format

  • Structure: Single structured log entry with labeled sections and a header block of identifying metadata
  • Length: 350–600 words per entry
  • Format: Structured document — header table for metadata, numbered lists for facts and reasoning, short prose only where reasoning requires it
  • Sections: Header Metadata → Decision Statement → Facts Relied On → Governing Policy/Regulation → Reasoning Chain → Alternatives Considered → Conditions & Follow-up → Sign-off
  • Tone: Neutral, precise, examiner-facing — factual and unemotional, written to be read by someone who was not present

Quality Checklist

Before delivering output, verify:

  • [ ] The decision statement is a single unambiguous sentence using the firm's exact outcome vocabulary
  • [ ] Every fact in Step 2 has a source and a date and is marked verified or unverified
  • [ ] The governing policy/regulation is cited by specific reference — not "per policy" or "per regulations"
  • [ ] Every inference in the reasoning chain traces to a logged fact
  • [ ] At least one rejected alternative is documented with a fact-and-policy reason
  • [ ] Any missing approver, policy citation, or required field is explicitly flagged "PENDING — REQUIRED BEFORE CLOSE" rather than left blank or fabricated

Notes

  • Never fabricate a policy citation, approver name, or fact to complete an entry — an incomplete-but-honest log is defensible; an invented one is a finding
  • Mask account and customer identifiers according to the firm's data-handling policy; when unsure, mask by default
  • The "Alternatives Considered" section is what distinguishes a defensible discretionary decision from an arbitrary one — never skip it, even for routine approvals
  • For high-risk or exception decisions, confirm the approver's authority level explicitly; a correct decision signed by an under-authorized approver is still an exception

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills