Quality Assurance Data 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.

Ingests QHP rates, service areas, and benefits and runs a standardized battery of checks before the data reaches downstream systems.

QHP Validation takes a carrier's qualified health plan rates, service areas, and benefits and runs them through one standardized set of checks — invalid rate curves, wrong year/quarter, wrong audience, wrong issuer, missing data, and similar contract violations. It replaces ad-hoc, source-by-source QHP review with a single repeatable gate, so the same problems get caught the same way every time.

• Standardized checks in one pass: invalid curves, wrong year/quarter, wrong audience, wrong issuer, and missing-data detection.
• One consistent gate for every source — QHP review stops depending on who happens to be looking at it.
• Runs on the same Vantage data and auth as the other validators, so its flags land in the same review workflow.

Tracks publishing rate against acquisition targets for the active year/quarter, so Ops always knows how close the season is to plan.

Quote Metrics measures publishing rate against the acquisition targets set for the current year/quarter combination. It gives the operations team a live read on progress toward the season's goals instead of waiting for an end-of-season tally.

• Publishing rate vs. acquisition target for the active year/quarter, at a glance.
• Turns the season goal into a single number Ops can watch day to day.

Validation metrics and flag analysis across the plan-validation output, brought into one quality view.

Data Ops Quality aggregates the validation metrics and flag analysis produced by the plan-validation tools — BenefitWatch, WREN, ARIA, and QHP Validation — into a single view: what's flagging, how often, and where defects cluster. Quality trends become visible across the whole pipeline rather than tool by tool.

• One quality view across every validator instead of separate dashboards.
• Flag analysis surfaces where defects concentrate and whether they're trending up or down.

Per-processor season reports and year-over-year benchmarks built from Jira data — with feedback pulled straight from QA comments.

Season Reports uses the Jira REST v3 API to build per-processor reports for the active build season, drawing feedback from QA comments and generating data analysis over the underlying ticket data. It also benchmarks each season against prior years, so recurring defect categories and capacity shifts stay visible instead of being re-discovered every cycle.

• Live Jira data via REST v3 with JQL — no scheduled exports, no stale dashboards.
• Per-processor report cards with feedback drawn from the QA comments on each ticket.
• Year-over-year benchmarks treat prior seasons as the baseline, so what didn't change is itself a signal.

Manual overrides for the SQL metric queries behind the dashboards — for when data is storing oddly or a bug is hiding it.

Manual Metric Override lets an operator step in and override the SQL metric queries that feed the dashboards when the underlying data is storing weirdly or isn't surfacing because of a system bug. Reported metrics stay accurate during the gap while the root cause is tracked down and fixed.

• A controlled escape hatch for when the data — not the query — is the problem.
• Keeps reported numbers trustworthy while a storage or ingestion bug is being fixed.

A quick-access hub for the documents and references the operations team reaches for every day.

Documents is a curated hub of quick-access links to the references, runbooks, and resources the operations team uses most. It puts the scattered, frequently-needed docs in one predictable place inside Vantage.

• One predictable home for the docs Ops actually uses, instead of hunting across drives.

A customizable, in-app replacement for the Google Sheet the team used to track carrier component statuses.

Acquisition Sheet is an improved, customizable version of the Google Sheet the team relied on to track carrier component statuses. It keeps the familiar tracking workflow but moves it into Vantage, with the structure, controls, and customization a shared spreadsheet could never offer.

• Same carrier-component tracking the team already knows, now native to Vantage.
• Customizable structure replaces a brittle, hard-to-govern shared spreadsheet.

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.

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.

Being phased out in favor of the new, wizard-driven THEA. 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.

A guided wizard: upload any rate source and THEA explores it, generates the right template with Haiku 4.5, and learns from every run.

THEA is a guided wizard for turning any carrier rate source into a clean, typed template. You upload a rate file (and a crosswalk if one applies) and THEA uses Claude Haiku 4.5 to explore the source, find the information it needs, and generate a defined template — age-banded or family-tiered — based on what the source actually contains. When it finishes, THEA asks you to confirm the template is complete, learns from any corrections, and stores the correctly generated carrier script for reuse. Think of it as Claude Cowork shaped for rate processing, so outsourced team members can put Claude to work on real files without ever being on the team account.

• Guided wizard: upload any rate source (plus a crosswalk if applicable) and THEA works out how to process it.
• Haiku 4.5 generates the right template shape — age-banded or family-tiered — from what it finds in the source.
• Confirms completeness, learns from mistakes, and stores correct carrier scripts so the next file of that type is instant.
• Lets outsourced teammates use Claude on real work without needing a seat on the team account.

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.

A chat assistant that answers data-availability and coverage-gap questions for customer success, backed by Claude Haiku.

CSM Assistant lets customer success managers ask plain-language questions about data availability, coverage gaps, and ingestion status and get answers in seconds, without pinging data ops. It's live and usable today but isn't under active development right now.

• Self-serve answers on coverage and ingestion status for CSMs.
• Built on Claude Haiku, and available as an interactive demo in the Explore section below.