A narrow but serious audit-findings workflow, and one of the first places I learned how much better AI products get when SME judgment, testing, and a willingness to pivot are part of the build.
Demo environment note
April 2026 proof-of-concept snapshot. Still functional, and the lessons from it now show up in my active Horizon Scanning build.
The data is fictional and seeded. Meridian Bank & Trust is not a real bank, and no customer, bank, regulatory, employer, or production data is represented.
AI Response Generation
This project taught me to ask a better question: not where can AI be impressive, but where can it make a real compliance workflow easier to draft, review, and explain.
I started with a citation helper because it looked like an obvious AI feature. Testing it made the better answer clear: experienced auditors do not need much help picking an FFIEC section. The higher-friction work was drafting formal management responses, so I changed direction.
The fun part was not just getting Claude to write prose. It was shaping a review loop that felt right for compliance work: Claude drafts from the finding facts, the response lands in an editable surface, and the user accepts, edits, or rejects it.
The drafter is available only when a finding is issued and waiting for management response. It is locked before issuance and after the response window, because a useful compliance tool has to respect the process around it.
Audit Trail
The design separates what the model suggested from what the user accepted. That distinction is the product point: an examiner, auditor, or reviewer should be able to recover who did what, when, and through which path.
Insert a PENDING ai_logs row before the Claude call, including model, system prompt, user prompt, and request payload.
Call Claude with forced structured output: draft plus rationale, not free-form text that the app has to guess how to parse.
Complete the log with response payload, suggested value, rationale, token counts, and latency.
Show the AI draft to the user in an editable review surface. Dismiss is logged. Accept requires an explicit action.
On Accept, write the user-final text, mark the ai_logs row ACCEPTED, and record the field edit in the same transaction with a shared correlation id.
From Prototype To Current Focus
I do not want to stay attached to an early idea just because it was the starting point. This proof of concept still works, but its real value is what it taught me about product judgment, AI controls, and the kind of build I want to keep pursuing.
This was one of my first serious AI apprenticeship projects: take a workflow I know well, build a narrow working slice, find the awkward parts, and keep improving the product decision.
The current focus applies the same lessons to regulatory-change review: source-quoted summaries, AI-proposed ratings, user confirmations or overrides, prompt versions, and audit logs.
Tech Stack
Part of the enjoyment is learning how the pieces fit together. The stack is how the compliance ideas become visible: identity, state, review gates, structured AI output, durable storage, testing, and deploy discipline.
Screenshots
These screenshots are from the hosted demo environment. The layout below gives each image more width so the workflow evidence is easier to inspect.
The main work queue shows seeded audit findings with status, risk, due date, audit source, and owner. It proves the demo is a functioning workflow surface, not a static mockup.
The detail page ties the narrative, response status, remediation notes, change history, and risk matrix into one reviewable record.
The edit surface keeps the finding structured. Severity and likelihood drive the risk rating, which the server recomputes rather than trusting the browser.
The intake path starts a finding as a governed record tied to an audit, with the fields a reviewer expects before the item moves into the lifecycle.
Reopened findings test the edge cases: recurrence, prior response context, status history, and renewed remediation accountability.
Filtering issued findings turns the inventory into an action queue: the records waiting for a management response.
Blank submission fails visibly and safely. Validation states matter because bad records should be stopped before they enter the trail.
I like taking a real workflow, building a small usable version, finding where it feels off, and changing direction when the better answer appears. The BSA/AML demo was that first serious test. Horizon Scanning is where I am applying the lessons now.
