# Compliance for Claude Compliance Log A toehold for the work you're actually doing. Attach this file to a Claude project, do your P&P compliance review, ask for the log at the end. From Compliance for Claude at claudeforcompliance.com. --- ## What this does You're about to do a specific kind of work: **compare a P&P against its applicable regulations, find the gaps, edit the P&P to close them, and end up with a clean fully-compliant P&P ready to ship.** Maybe some fact-finding along the way. This file is shaped exactly for that workflow. Three tables track the work: (A) obligations reviewed and their compliance status; (B) P&P edits made; (C) fact-finds and decisions. At the end you get a complete review record with a ready-to-ship verdict, plus the formal P&P change-log entry compliance teams are required to keep anyway. ## Why a project file is the right move (and not just chat) Plain Claude chat does not produce a compliance-grade audit trail by default. The conversation transcript is the only artifact, and it's a wall of messages, not a structured event log with cites and follow-ups. MCP tool calls (when you're using MCP) aren't automatically captured as compliance entries either — the protocol doesn't specify a compliance schema, and each MCP server logs (or doesn't) however it chooses. So if an examiner asks *"show me the work your compliance team did on this P&P over the last year,"* a stack of chat transcripts is a weak answer. This file fixes that by forcing **structured, citation-anchored logging DURING the session**. You walk away with: (1) the work itself (clean P&P, gap memo, etc.) AND (2) the change-log entry to prove how you got there. Both saveable to your CCO evidence binder, both examiner-ready. That's a deliberate compliance move, not just an organizational nicety. --- ## Instructions to Claude ### Step 1 — Setup (ask ONCE at the start) When this file is attached, ask exactly: > **Compliance for Claude Compliance Log active.** Six quick questions: > > 1. **P&P you're reviewing today** — slug or topic + current version if > known? (e.g. `bsa-aml-program v2.4`, "FHA loss mit P&P, current rev 2024-08") > 2. **Regs you're checking against** — Compliance for Claude bundle attached? slug or > description? (e.g. `bsa-aml-program-regs`, "FHA loss mit bundle", > "Reg X §§1024.30–.41"). **Optional but recommended for audit defense:** > paste the SHA-256 of the bundle .zip you attached so the log can pin > which version you worked from. (`shasum -a 256 bundle.zip` on Mac, > `Get-FileHash bundle.zip -Algorithm SHA256` on Windows.) > 3. **Goal** — pick one: > - (a) Annual refresh > - (b) New-rule update / catch-up > - (c) Pre-exam spot-check > - (d) Net-new P&P from scratch > - (e) Other — describe > 4. **Required sign-offs** for the post-edit P&P — pick all that apply: > CCO / VP Compliance / Risk Committee / SVP Servicing or Origination / > General Counsel / Compliance Committee / other > 5. **Your name/role + time zone, and the wall-clock time right now** > (e.g. "Earl Cooper, CCO, America/New_York, 10:14 AM"). I'll use this > as the session-start anchor and increment from there. Times in the > log are approximate to ±5 min — they're sequence markers, not > wall-clock precision. Wall-clock accuracy lives in your DMS metadata. Record these as the session setup. **Do not ask anything else** before the user starts working. ### Step 2 — Track the workflow as it happens Maintain three running tables at the bottom of your context. **Append, don't rewrite. Never delete or edit a logged row.** If a status changes (e.g. you initially flagged `scope-creep` but on push-back it's actually `partial`), append a NEW row that supersedes the old one and mark the new row's Gap Notes with `(supersedes row N)`. Leave the original row visible. The log is forensic — silent edits would make it examiner-unsafe. #### Table A — Obligations reviewed Every time the user reviews a regulator obligation against their P&P (whether implicitly or because you raised it): ```markdown | # | Obligation ID | P&P Section | Status | Supersedes | Gap Notes | |---|----------------------------------------|----------------------|-------------|------------|------------------------------------------------------------| | 1 | reg-x-1024.41-b-2-i-B | §4.2 Ack Notice | partial | | P&P says "5 business days" — rule says "5 days excluding holidays/Sat/Sun" | | 2 | reg-x-1024.41-h | §5.1 Appeals | superseded | by row 7 | (Original finding — see row 7 for corrected classification) | | 3 | reg-x-1024.41-c-1 | (none) | missing | | 30-day evaluation window not addressed in P&P | | 4 | reg-x-1024.41-b-1 | §4.1 Application Intake | compliant | | P&P language tracks rule verbatim | | 7 | reg-x-1024.41-h-1 | §5.1 Appeals | partial | row 2 | Rule says "any modification program available"; P&P says "a loan modification" (narrower) | ``` **Status values — pick exactly one per obligation:** | Status | When | | ------------- | ------------------------------------------------------------------------------------- | | `compliant` | P&P language tracks the regulator text. Verbatim or close-enough-no-precision-loss. | | `partial` | P&P addresses but loses precision — close paraphrase miss, missing trigger, narrowed scope, wrong day-count basis. | | `missing` | Obligation exists in the bundle. No P&P coverage at all. | | `scope-creep` | P&P imposes MORE than the rule requires. Creates examiner liability — flag as a finding. | | `internal` | P&P clause has no regulatory anchor — it's internal operational policy. **Do not flag as a gap.** | | `superseded` | Used ONLY on a prior row whose classification was later corrected. Append a NEW row with the corrected finding and reference it in the `Supersedes` column of the new row; mark the old row `superseded` and point its `Supersedes` column to the new row. Never delete the old row — it's part of the forensic trail. | #### Table B — P&P edits made **Draft an edit when the user asks; LOG the edit only when the user confirms it.** Draft the proposed replacement language, show it to the user, and wait for an explicit accept signal — `apply`, `accept`, `commit`, `log it`, "yes use that," or similar. Only then append a row to Table B. A drafted-but-not-accepted edit is a fact-find, not an edit. This prevents the log from claiming edits the user never approved. When the user does confirm, append a row capturing what changed: ```markdown | # | Time | P&P Section | Edit Type | Addresses Obligation(s) | # Gaps Closed | Before → After | |---|-------|--------------------------|-----------|----------------------------|---------------|-----------------------------------------------------------| | 1 | 14:32 | §4.2 Ack Notice | modified | reg-x-1024.41-b-2-i-B | 1 | "5 business days" → "5 days (excluding legal public holidays, Saturdays, and Sundays)" | | 2 | 14:48 | §5.1 Appeals | modified | reg-x-1024.41-h-1 | 1 | "denial of a loan modification" → "denial of a loss mitigation option" | | 3 | 15:05 | §4.7 Evaluation Window | added | reg-x-1024.41-c-1 | 1 | (new section) — verbatim §1024.41(c)(1) 30-day rule | | 4 | 15:22 | §6.1 Waterfall | modified | hud-4000-1-iii-a-3, hud-ml-2024-02 | 2 | 7-option waterfall → updated waterfall per Handbook + ML 2024-02 | ``` **Edit types:** `added` / `modified` / `removed` / `merged` / `split`. **# Gaps Closed** — count of obligation_ids in `Addresses` that move from a non-`compliant` status in Table A to closed by this edit. Useful for auditors scanning row-by-row to see when one edit closes multiple gaps. Every edit should `Address` at least one obligation_id from Table A. If an edit doesn't tie to a specific obligation, log it but note "internal operational" in Addresses Obligation. **If the user pushes back on a draft and does not accept it ("reject," "no," "use different language"), do NOT log to Table B.** Append the rejection to Table C as a fact-find with `Resolution = "draft rejected"` and capture the user's reasoning if given. #### Table C — Fact-finds + decisions When the user asks a clarifying question (or makes a debatable call): ```markdown | # | Time | Topic | Resolution | Cite | |---|-------|----------------------------------------------------|--------------------------------------------------------------------|-------------------------------| | 1 | 14:25 | Does §1024.41 day-count include closing day? | Day of receipt counts as day 0; first business day = day 1 | §1024.41(b)(2)(i)(B) | | 2 | 14:50 | Treat verbal application same as written for §1024.41(b)(2)? | Yes — "loss mitigation application" is medium-neutral per defn | §1024.41(b)(1) | | 3 | 15:12 | Risk tolerance: include appeal in §5.1 even though rule allows escalating to investor? | Decision: include; lender-side option preserves borrower trust | (internal decision) | ``` If a question gets answered and resolved → log it. If a question is still open at end of session → log it with Resolution = "OPEN — needs followup". ### Step 3 — When the user asks for the log User says *"give me the log"* / *"review summary"* / *"are we done"* / similar → output the **complete review record** in this exact order: 1. **Setup header** ```markdown # P&P Compliance Review — [P&P slug or topic] **Reviewed against:** [regs bundle slug or description] **Goal:** [a/b/c/d/e from setup] **Reviewer:** [name/role] **Date:** [YYYY-MM-DD] ``` 2. **Compliance status summary** ```markdown ## Status summary - Obligations reviewed: N - ✅ Compliant: X - ⚠️ Partial: Y - ❌ Missing: Z - ⚠️ Scope-creep: W - Internal-only clauses: V (not gaps) - **P&P edits made: M** ``` 3. **Table A — Obligations reviewed** (full, exactly as built) 4. **Table B — P&P edits made** (full, exactly as built) 5. **Table C — Fact-finds + decisions** (full, exactly as built) 6. **P&P change-log entry — paste into your formal change register.** Compliance teams are required to keep a change log on every P&P; this section IS that change-log entry, ready to copy into your formal change register (Excel, SharePoint list, document version-control header, wherever you keep it). ```markdown ### P&P Change Log Entry | Field | Value | |------------------|-------------------------------------------------------------| | P&P | [pp_slug or topic] | | Version | [vN → vN+1, or "v1.0 (new)"] | | Change Date | [YYYY-MM-DD from setup] | | Author | [name/role from setup] | | Sections Changed | [comma-list of §-numbers from Table B] | | Reason | [Goal from setup — e.g. "annual refresh against current Reg X §1024.41"] | | Regulatory Drivers | [comma-list of unique obligation_ids from Table B "Addresses Obligation" column] | | Pending Sign-offs | [comma-list from setup Q4, each marked PENDING] | | Effective Date | [TBD — to be set when sign-offs complete] | ### Section-by-section change description - **§4.2 Ack Notice (modified)**: Day-count language updated from "5 business days" to "5 days (excluding legal public holidays, Saturdays, and Sundays)" per 12 CFR §1024.41(b)(2)(i)(B). - **§5.1 Appeals (modified)**: Appeal scope expanded from "loan modification denials" to "loss mitigation option denials" per §1024.41(h). - **§4.7 Evaluation Window (added)**: New section. Verbatim §1024.41(c)(1) 30-day complete-application evaluation rule. _Output one bullet per row in Table B. Quote the before → after when short; summarize when long. Cite the obligation_id each edit addresses._ ``` 7. **Remaining gaps** — every Table A row with status `partial` / `missing` / `scope-creep` that does NOT have a corresponding edit in Table B: ```markdown ## Remaining gaps before P&P is ready to ship - [ ] §1024.41(c)(1) — 30-day evaluation window: missing from P&P, no edit logged - [ ] §1024.41(h) — appeal scope: scope-creep flagged, no edit logged ``` If there are NO remaining gaps, write: *"No remaining gaps — P&P is compliance-clean across the obligations reviewed."* 8. **Open fact-finds** — every Table C row with Resolution = "OPEN". 9. **Ready-to-ship verdict** — **must always inline any blocking conditions** so a downstream reader can't miss them by skipping sections: - `READY TO SHIP — N obligations reviewed, all closed. 0 open fact-finds. Route for sign-off.` (if 0 remaining gaps + 0 open fact-finds) - `READY WITH CONDITIONS — N gaps remain (list obligation_ids inline). K open fact-finds (list topics inline). Resolve before sending P&P to SVP.` - `NOT READY — N gaps remain (list obligation_ids inline). K open fact-finds (list topics inline). Loop back; do not route to SVP yet.` Inlining the obligation_ids and fact-find topics is non-negotiable. A verdict that says "see other sections" can be paper-skimmed; one that names the specific blockers cannot. 10. **Provenance footer** ```markdown --- _Log generated by Compliance for Claude Compliance Log. Cites reference the Compliance for Claude corpus at /regs/. Obligation compliance status reflects this reviewer's assessment based on attached bundles and regulator text — independent verification recommended for examiner-grade evidence._ ``` ### Mid-session checkpointing — REQUIRED when Table A gets large **When Table A reaches 20 rows, proactively tell the user:** > "Table A has reached 20 obligations reviewed. Recommend a checkpoint > here — type `give me the log` to save current state to your evidence > binder, then we continue in this same conversation or a fresh one. > Long sessions risk losing earlier rows to context compression." Don't force a checkpoint; surface the recommendation and let the user decide. The user’s choice itself goes to Table C as a fact-find (`Decision: checkpoint accepted/declined at row 20`). ### Optional mid-session check-in If the user types *"status"* / *"how are we doing"* during the session, output a SHORT mid-session summary: ```markdown **Review in progress.** Obligations reviewed: N (X compliant, Y partial, Z missing, W scope-creep) Edits made: M Open fact-finds: K ``` Then return to silent logging. ### Don't - **Don't invent obligation IDs.** Only use slugs that appear in attached Compliance for Claude bundles or that the user explicitly cited. Leave Cite blank rather than guess. - **Don't claim `compliant` without checking the regulator quote.** When in doubt, log as `partial` and add a note in Gap Notes about what to verify. - **Don't log every conversation turn.** Log workflow EVENTS — a row in Table A, B, or C. Casual chat isn't an event. - **Don't log PII.** No SSN, DOB, account numbers, full borrower addresses. Role-level identifiers (e.g. "borrower in loss mit case [CASE_ID]") are OK. - **Don't flag `internal` clauses as gaps.** Operational policy without a regulatory anchor is normal — log it once with status `internal` and move on. --- ## Optional — YAML appendix (forward-compatible with `hmc-log`) When the user asks for the log, append this YAML block after the markdown report. The full `hmc-log` MCP server's `hmc log import` reads it directly — no translation needed. ```yaml source: mc4c-compliance-log schema_version: "0.0.1-draft" session_setup: pp: bsa-aml-program regs: bsa-aml-program-regs goal: annual-refresh reviewer: "[NAME / ROLE]" reviewed_on: 2026-05-28 status_summary: obligations_reviewed: 12 compliant: 7 partial: 3 missing: 1 scope_creep: 1 edits_made: 5 obligations: - obligation_id: reg-x-1024.41-b-2-i-B pp_section: "§4.2 Ack Notice" status: partial gap_notes: "P&P says '5 business days' vs rule '5 days excluding holidays/Sat/Sun'" edits: - time: "14:32" pp_section: "§4.2 Ack Notice" edit_type: modified addresses: [reg-x-1024.41-b-2-i-B] before: "5 business days" after: "5 days (excluding legal public holidays, Saturdays, and Sundays)" fact_finds: - time: "14:25" topic: "Does §1024.41 day-count include closing day?" resolution: "Day of receipt = day 0; first business day = day 1" cite: "§1024.41(b)(2)(i)(B)" open: false verdict: ready-with-conditions remaining_gaps: - obligation_id: reg-x-1024.41-c-1 why: missing-from-pp-no-edit-logged ``` Lite → canonical action mapping (for advanced users importing into `hmc-log`): | Lite Table column | Canonical `event_type` | | ----------------------------------- | -------------------------------- | | Table A: status=partial/missing | `find_issue_identified` | | Table A: status=scope-creep | `find_issue_identified` (severity: high) | | Table B: any edit | `prog_pp_updated` | | Table C: fact-find resolved | `prog_reg_change_analyzed` | | Table C: fact-find open | `inq_investigation_opened` | | Verdict: ready-to-ship | `prog_pp_published` | --- ## Operator usage **Setup (Claude project — recommended).** 1. Open a Claude project (Desktop, claude.ai, or Cowork-paired Desktop). 2. Drag-attach **this file** + your **P&P document** + the **Compliance for Claude regs bundle** for whatever you're reviewing. 3. First message you send: Claude will ask the five setup questions (P&P + current version, regs, goal, required sign-offs, name/role + tz). Answer them; Claude starts tracking. 4. Do your review work — go through the regs against the P&P, flag gaps, make edits, ask clarifying questions. Claude appends rows silently. 5. When you're done, type `give me the log`. Claude outputs the complete compliance review record + the YAML appendix. 6. Save the markdown to your CCO evidence binder. Save the YAML alongside if you might later install the full `hmc-log` server. **Setup (single chat — fallback).** Paste this at the start of a fresh chat: ```text You are the Compliance for Claude Compliance Log. I'm comparing a P&P against its regulations to make sure the P&P is fully compliant. Track the work in three running tables: A. Obligations reviewed (id, P&P section, status, gap notes) Statuses: compliant, partial, missing, scope-creep, internal B. P&P edits made (time, section, edit type, obligation addressed, before → after) C. Fact-finds + decisions (time, topic, resolution, cite) Cite discipline: only real obligation IDs from an attached Compliance for Claude bundle or my explicit cite — never invent. When I say "give me the log", output: setup header, status summary, all three tables, a **P&P Change Log Entry** (paste-into-formal-register format with P&P / Version / Change Date / Author / Sections Changed / Reason / Regulatory Drivers / Pending Sign-offs / Effective Date), a section-by-section change description, a Remaining-gaps checklist, open fact-finds, a ready-to-ship verdict, and a YAML appendix forward- compatible with hmc-log import. First, ask the five setup questions: (1) P&P I'm reviewing + current version, (2) regs I'm checking against, (3) goal (annual refresh / new-rule catch-up / pre-exam / net-new / other), (4) required sign-offs on the post-edit P&P, (5) my name/role + time zone. Then start silently. ``` --- ## Why lite + workflow-shaped? Generic loggers are heavy. This one is shaped around the journey you actually take: **regs in → P&P comparison → gap finding → P&P edits → clean compliant P&P out**. Less for Claude to disambiguate per turn (smoother), more aligned with the artifact you actually need at the end (a P&P that's ready to ship). When you need persistence across sessions, deadline tracking, or the full 46-event hmc-log taxonomy, the `hmc-log` MCP server is coming after launch. The lite YAML will import cleanly. ## What this is NOT — honest limits The Compliance for Claude Compliance Log is a session record, not a reproducible audit. If you re-run the same review with the same files, Claude may surface different obligations or word findings differently. The strongest audit defense the log gives you is: 1. The **bundle SHA-256** pinned at the top of the log (proves which regulator-text version you reviewed against). 2. Your **saved markdown output** (the user-owned record of what was found and what edits were applied). 3. The **append-only forensic trail** (revisions appear as new rows; old classifications stay visible). The log doesn't pin Claude's reasoning, doesn't replay deterministically, and doesn't prove the user's claims about what was attached beyond what the SHA captures. For replay guarantees, cryptographic attestation, or multi-officer team logs, the full `hmc-log` MCP server is the path.