Projects

Problem

Investments on a regulated crowdfunding platform stall on funding, payment, accreditation, and identity-verification blockers. Clearing them meant piecing together each investor's state across several services and the CRM, then writing a compliant follow-up by hand.

Approach

• ▸Deterministic intake, AI drafting. Rules classify each stalled case by blocker type; an LLM then triages and drafts. Cases are processed independently, so one failure never fails the run, and the model sees only the data that case needs.
• ▸Verify, don't trust. An AI review step checks every draft before it goes out. Anything it can't confirm is held for a human — never silently dropped.
• ▸Safe, idempotent sending. Every automated send passes a safety gate first, and a crash can never send the same message twice. Rolled out in stages, starting with a dry-run phase.
• ▸Operable without redeploys. Runtime-tunable settings, scoped on-demand refreshes, and long rebuilds as background jobs with status polling instead of requests that time out.

Result

• ▸Lets a single admin clear 70+ cases per day, with clearer decision-making.
• ▸The AI review step replaced a brittle hand-maintained rule set after being measured against it on frozen real cases before cutover.

Problem

Sales and ops staff wanted to ask investor questions in plain English and sometimes have the assistant carry out authorized account operations. Free-text approval in a chat can't safely authorize a money or account action on its own.

What it can do

Dozens of read and action capabilities, loaded on demand by a router instead of one giant prompt — for example, where an investment stands, how a payment changed over time, or a holdings summary. Sensitive account changes run only through the approval flow below; lower-risk actions run directly.

Approach

• ▸Approve a stored proposal, not the model's words. A propose step reads live state, stores the exact proposed effect on the server, and posts a plain-language preview. Execution runs from the stored proposal, so the model can't alter what a human approved.
• ▸The server verifies authorization. The server — not the model — confirms a trusted approver authorized this specific proposal and re-validates against live state at execution. Every approval path converges on the same check.
• ▸Exactly-once, safe execution. An approved action runs only once; anything unclear goes to a human.
• ▸Model interprets, server confirms facts. Answers come from server-side lookups that return facts with provenance — or an honest “unknown”. Hard gates remain on sensitive actions. Scoped per deployment, with operator controls.

Result

• ▸Validated with a deterministic offline eval harness against frozen baselines before cutover: approval recognition and wrong-refusal rates both improved materially, and sensitive actions took fewer turns to complete.
• ▸Authored the implementation-ready design doc.

Problem

Updates needed a staff review step, scheduling, delivery to the right audience — public followers vs. existing investors for private updates — and automatic notices when an offering changed materially.

Approach

• ▸Explicit lifecycle with role-based permissions. Draft, staff review, scheduled, published. Issuers act only on their own offerings; only staff approve, reschedule, or reject — and rejecting an approved update cancels its pending delivery.
• ▸Cross-service hand-off with retries and defined reschedule/cancel semantics, so the two services never disagree about what is scheduled.
• ▸Set-based fan-out into a database work queue. One query builds the per-recipient queue; parallel workers claim work without collisions and emit one notification event per recipient over Kafka.
• ▸Event-driven closure and migration. A completion event marks the update published; a listener turns material-change events into templated notices (the template is ops-editable config, not code); a strangler path migrated legacy updates.

Result

• ▸In production across both services since March 2023, replacing a multi-day manual process with a minutes-long workflow.

Problem

Transferring privately held securities takes several parties signing legally binding documents in a safe order, and the same shares must never be allocated twice.

Approach

• ▸A state machine owned by the domain. One allowed-transition table guards every move. Recipients sign before the transferor, so nobody commits shares to a transfer a recipient later declines.
• ▸The database is the arbiter. Row-level locking and a share reservation make double-allocation impossible even when job runs overlap; investor-facing access is scoped to the requesting account.
• ▸Background jobs, not synchronous chains. Document generation, signature polling, and outcome reporting run as resilient scheduled jobs with per-item failure isolation. Permanent failures go to a manual queue rather than auto-cancelling, which would email the investor.
• ▸Replay-safe hand-off, notify after commit. The ledger hand-off is atomic and idempotent and is created unapproved, so the transfer agent's human approval stays downstream. Lifecycle events publish only after commit, so a rolled-back write never notifies anyone; ambiguous e-signature responses go to reconciliation, not automatic retries.

Result

• ▸In production since September 2026; 34 test files cover the workflow, including explicit account-scoping denials.

Problem

The custodian is a third-party system with its own account lifecycle, maintenance windows, e-signature steps, and asynchronous status changes. The platform had to keep investor-facing state correct without tying user requests to the custodian's availability.

Approach

• ▸Never block a user on the custodian. Custodian work runs in background jobs with per-request transactions and retry; requests stay pending through the custodian's maintenance windows.
• ▸Store-then-process webhooks. Callbacks land in an inbox first, then are dispatched to handlers, so bursts and duplicates never corrupt state.
• ▸Two keys to activate. An account activates only when both the custodian and internal checks agree; duplicate callbacks are idempotent and conflicting work is serialized.
• ▸Replay-safe events. Registration events to Kafka can be re-run safely, so the repair path actually works.

Result

• ▸In production since March 2025.

Problem

Onboarding a company to raise capital takes dozens of facts that live in legal and financial documents. Re-typing them is slow and error-prone, and extracted data should only land while onboarding can still accept it.

Approach

• ▸Asynchronous by design. An upload emits an extraction request over Kafka; results come back on a separate topic. A colleague built the Kafka plumbing; I built what happens to each result.
• ▸A typed contract per document type. Results are validated before they touch the domain; a violation marks the upload as an error with a reason instead of writing bad data.
• ▸Stage-guarded writes. Extracted data is applied only when the onboarding stage permits; rejected results are ignored or recorded, never applied.
• ▸Prerequisite-aware second pass. A lock-guarded scheduled job requests a company-level extraction once the needed documents exist. A Q&A endpoint lets users ask questions about the documents they uploaded.

Result

• ▸In production since July 2024; document types expanded through 2024.

Problem

Every company that onboards uploads a stack of legal and corporate documents. Reviewers had to read each one and re-key the facts by hand.

Approach

• ▸A request queue in front of the AI. The Kafka consumer only records the request, and a worker picks it up. Slow LLM calls never back up the consumer, and every request has an auditable state — at the cost of one extra hop.
• ▸Classify, then extract. An LLM identifies the document type when it's unknown; a versioned, type-specific prompt library drives extraction, hardened against instructions embedded in the documents themselves.
• ▸Multi-provider routing with fallback. Inputs route to the best-fit provider by input type, with fallback and an optional cross-provider merge for field coverage — trading cost and latency for accuracy.
• ▸Protected results, closed loop. Sensitive fields are encrypted and values normalized before storage; results and handled errors return to onboarding over Kafka.

Result

• ▸Cut document processing time from 30 minutes to 2–3 minutes and lifted accuracy from 30% to 70%.
• ▸In production since July 2024; three other engineers later extended the design.

Problem

It started as a passion project for a few engineers and grew as more asked for reviews. An AI reviewer with shell access over untrusted PR content, whose approval can carry weight, needs hard limits: no re-reviewing unchanged code, no reviewing mid-push or while CI is running, no runaway on a busy PR, and nothing posted that policy forbids — whatever the prompt or the diff says.

Approach

• ▸Tiered detection and re-look. Configurable polling for reviews requested from the bot, from a team, and a proactive sweep of configured repos; a push, a human reply, or CI turning green brings a reviewed PR back.
• ▸Idempotent queue keyed by head commit, with daily caps — a re-poll never re-reviews unchanged code and every reply earns exactly one follow-up.
• ▸Cost gates before the model runs. A debounce waits for the author to stop pushing and a CI gate waits for checks (both fail open). A newer commit cancels a running review and keeps partial findings.
• ▸Guardrails in code, not the prompt. Every post goes through a per-run shim that allows exactly one review shape and re-checks dry-run mode, approval policy, and PR state at post time; the model's environment has no database access.
• ▸Two verdicts, human-held approvals. Approve or request changes — never a neutral comment. Approvals are opt-in per author; held approvals wait for an operator in a web dashboard that also edits runtime settings (pause, dry-run, model, concurrency).

Result

• ▸Became the team's sole AI code reviewer, replacing CodeRabbit — cheaper, with reviews engineers preferred.
• ▸The self-hostable core (Docker Compose) is MIT-licensed with offline tests for approval rules, concurrency, caps, and the post-time gate. Production deployment config is not in the repo.