Data Quality Assurance Manager who built
an internal data QA platform.

Vantage's regression suite — a single-file query registry powering 742 unique carrier/audience combinations, run daily and on-demand.

BenefitWatch is the operational core of Ideon's data-quality monitoring. A 5-batch Athena validation engine runs from a single-file registry of 103 SQL queries across ticket-ingestion, QA-ingestion, rate-ingestion, and daily rule-engine batches, with cost-tagged queries and dashboards offering pagination, sorting, filtering, and per-row dismissal. A separate Analytics layer reads S3 run history to surface active, new, resolved, and recurring quality flags across all carriers.

• Custom SQL-suite CI check validates the registry: get_queries() returns a non-empty dict[str, str] for every batch×audience, no stale years or unresolved tokens, benefit and rate batches reference the correct tables, and every query parses as valid Trino SQL via sqlglot.
• Per-row dismissal with audit logs so dismissed flags don't reappear — operators get a clean queue without losing history.
• Trend dashboards make recurring defect categories visible across processing seasons, replacing one-off spot-checks with a continuous signal.

Watches every change to the data and queues it for QA approval before it propagates — with priority-tiered flag categorization so reviewers aren't drowning in noise.

WREN tracks every data change across the entire dataset and gates it on QA sign-off. The novel piece is the priority-tiered flag categorization: high-priority flags get triaged first; lower-priority ones are batched. Two workflows run side-by-side. The daily zero-tolerance scan focuses on 14 high-priority fields we've deemed critical based on direct customer feedback — nothing on those fields ships without explicit approval. The ticket-level change-set view surfaces every change made during a given ticket's lifecycle so the reviewer can sign off on the whole bundle at once.

• Two cadences, one engine. Daily zero-tolerance scan for the 14 priority fields + a ticket-level diff view for everything else — same flag taxonomy, different triggers.
• Priority tiers, not a single severity. High-priority flags get expedited routing; lower-priority ones batch up for end-of-day review. Customer feedback drove the priority list.
• Same flag categorization extended to ARIA. Once WREN proved out, the same priority-tier model went into ARIA so its SBC reviewer queue stays focused on what matters.

Automated data profiling over semi-structured SBC PDFs — deterministic, regex-based, no LLM in the hot path.

ARIA discovers SBC (Summary of Benefits and Coverage) PDFs on S3, uses pdfplumber to extract coverage period, plan name, and benefit cost-share fields, then runs regex-based checks covering name alignment, coverage dates, deductibles, and benefit values. Three categories of structured checks per plan, processed at 50+ plans per batch with audit-logged dismissals — every flag, override, and reviewer decision is traceable. Now runs the same priority-tiered flag categorization that WREN pioneered so the reviewer queue stays focused on what matters.

• Deliberately not an LLM. Regex on a parsed-text pipeline is faster, cheaper, and fully deterministic — and the audit trail is meaningful precisely because the rules are explicit.
• Layered architecture: discovery, extraction, and validation are independently testable concerns — the same test-automation patterns the rest of Vantage uses.
• Audit-logged dismissals mean every flag is traceable back to the reviewer who handled it; dismissed flags don't re-fire on the next run.
• Priority-tiered flags from WREN. ARIA borrowed WREN's flag taxonomy so high-priority issues get triaged first and the queue doesn't drown reviewers in low-signal noise.

An agentic loop with real fallback logic — and a real outcome metric. Per-ticket processing dropped from ~15 minutes of manual work to under 30 seconds.

When a Jira ticket is tagged agent, the Adapter Agent picks it up, pulls the matching script from the carrier library, runs it in an isolated subprocess, samples 3 plans at age 60 as a sanity check, attaches the output back to the ticket, POSTs results to the database, and routes the ticket to QA for fuller review. If the script fails mid-run, the agent attempts up to 3 repairs on AWS Bedrock Claude before escalating to a human.

• ~15 minutes of manual work → under 30 seconds. The processing-time delta is the headline metric, and the agent escalates only what it genuinely couldn't recover.
• Subprocess sandboxing contains LLM-generated repairs: the model can suggest anything, but it can only break its own subprocess — the host stays clean.
• Age-60 sample as a built-in canary. Output isn't trusted until three plans at a fixed age look right, then results POST to the database and the ticket routes to QA.

Two functions under one engine — documentation Q&A on our internal grammar, and an LLM-assisted PDF-to-ingest translator that hits ~15% of carriers today.

SAGE pairs two related capabilities. (1) Answers questions about our internal ingestion flows and data-grammar rules over internal documentation. (2) Parses carrier PDFs with pdfplumber, maps fields into our internal schema (the same target ARIA uses), then uses AWS Bedrock Claude with grammar rules, regex patterns, and embedded LLM instructions to translate extracted data into ingest-ready records. The translation path is under active development and covers roughly 15% of the carrier universe; we're training an AWS SageMaker model on our own data to extend coverage.

• Two related capabilities under one engine — the docs Q&A surfaces the grammar; the PDF translator applies it.
• Shared internal schema with ARIA means SAGE-translated records land in the same shape downstream consumers already trust.
• SageMaker model in training on real ingestion data to push coverage beyond what Bedrock prompt-engineering reaches.

Chat interface that turns ad-hoc carrier rate files into typed, validated CSV — by generating its own extraction code.

THEA is an LLM-as-code-generator pipeline wrapped in a chat interface. The user uploads a carrier's Excel or PDF rate file; THEA generates a Python extraction script, runs it inside an isolated subprocess sandbox, and returns a typed CSV with HIOS ID validation applied. The user-facing surface is conversation; the underlying machinery is code generation, sandboxed execution, and contract validation.

• Subprocess sandbox isolation: LLM-generated extraction code runs in its own process — failures are contained, the host stays clean.
• HIOS ID validation enforces the data contract on output — the LLM can be creative, but the schema is not negotiable.
• Typed CSV makes downstream consumption deterministic — the artifact is testable, diffable, and re-runnable.

A real-time Salesforce case queue with inline editing, auto-fill, and direct write-back — the daily driver for QDS Support.

CLIO is a real-time Salesforce case queue built for the QDS Support team. It pulls cases via the Salesforce REST API using SOQL, provides inline field editing directly inside the dashboard, auto-fills case fields from the description text, and writes changes back to Salesforce via the same REST API. No tab-switching, no copy-paste.

• Reduced the click-cost of casework: inline editing means support reps update Salesforce without ever leaving the queue.
• Auto-fill demonstrates light rules-based extraction — pattern-matching on description text to surface the right defaults.
• Clean REST client pattern: SOQL for reads, REST writeback for updates, all behind Vantage auth.

Deliberately not an LLM. A domain-specific ACA keyword taxonomy that classifies CS tickets faster, cheaper, and more predictably.

Not every problem needs an LLM. Salesforce Ticket Quality classifies customer-support tickets by error reason and solution summary using a domain-specific ACA keyword taxonomy — fully rules-based, fully deterministic, zero inference cost. The dashboard surfaces error and resolution patterns across the support pipeline, giving leadership visibility into recurring CS friction.

• Rules-based by design: structured ACA terminology classifies reliably without LLM cost, latency, or non-determinism.
• Demonstrates judgment about when not to reach for AI — an underrated discipline in 2026.
• Backed by the same Vantage auth/access model as the LLM-augmented tools.

Weekly snapshots, per-processor report cards, and year-over-year benchmarks — built from live and historical Jira data.

Two companion tools built on the Jira REST v3 API. Processing Season Report generates weekly snapshots and per-processor report cards for the active processing season. Processor YoY compares the same metrics across years to surface trends, regressions, and capacity shifts. Together they give the operations team objective visibility into throughput and quality.

• Live Jira data via REST v3 with JQL — no scheduled exports, no stale dashboards.
• YoY benchmarking treats prior seasons as the baseline — defect categories that didn't change are themselves a signal.
• Powered by the same query-registry pattern as BenefitWatch — one place to change a metric, everywhere downstream stays consistent.