Sampreeth Avvari

How I saved our accountant 400 hours a year

Wed, 20 May 2026 00:00:00 GMT

Garrett is the controller at Hybridge. Every Monday morning he’d download CSVs from five different systems, open each one, rename columns, copy-paste rows, hand-tag deposit accounts, look up vendor names by check number. Then do it again for the next file. An entire workday a week was disappearing into reformatting work that produced no decisions, only inputs.

The cost isn’t just his time. Garrett is the person the operations team needs when something looks wrong in the numbers. While he was buried in paste-and-rename, everyone else was waiting. A small dental-implant clinic can’t afford to have its only senior accountant running a manual ETL pipeline every week.

I’m the sole AI engineer at Hybridge. When I sat down with Garrett and watched the Monday workflow, the problem wasn’t that nobody had tried to fix it. The problem was that the obvious fix, one unified import platform, would have broken every time a vendor changed a column header, which they do constantly. What Garrett actually needed was a dozen small scripts: one per upstream system, short enough to read in ten minutes, and editable without my help.

The five upstream systems

MagicTouch (DLCPM)  →  payments + production
Denticon            →  Buffalo location's PMS
Paychex             →  payroll, time-off exports
Bank (Buffalo)      →  AccountTransactionDetail CSV
Bank (Hybridge)     →  AccountTransactionDetail CSV

None of them speak each other’s format. None of them export the columns the downstream sheets need. The bank CSV has a two-line preamble and a two-line trailer. Paychex encodes company name into the filename and department codes need a lookup table. Denticon and MagicTouch label the same payment type three different ways.

What I built instead

A dozen small Python scripts. Each one is the verb for one upstream system. Each one is short enough to read in ten minutes.

AR_Aging.py                             receivables aging, multi-sheet Excel
Buffalo_Ramp_IIF_Reformat.py            IIF for QuickBooks
cashflow_import.py                      bank CSV → master cashflow Sheet
checks_import.py                        outstanding checks ledger
Denticon_Payment_Import_Buffalo.py      Denticon payments
Denticon_Production_Import_Buffalo.py   Denticon production
MT_Payments_Import.py                   MagicTouch payments
MT_Sales_Import.py                      MagicTouch sales
Paychex_Time_Off_Information_Cleanup.py payroll time-off
+ three reference Excel files

Garrett never runs a generic ETL command. He runs python MT_Payments_Import.py after he downloads the MagicTouch export, and a clean IIF appears in his Downloads folder. The mental model matches the calendar reality.

Configuration that respects how the user actually works

Each script has the same shape: imports, then a config block, then the functions. The config sits at the top so Garrett can edit it himself without asking me.

DEPOSIT_ACCOUNTS = {
    "credit card":     "Cardpointe Clearing",
    "check":           "ACH Check Clearing",
    "echeck":          "ACH Check Clearing",
    "ach":             "ACH Check Clearing",
    "direct deposit":  "ACH Check Clearing",
    "echecks/ach":     "ACH Check Clearing",
    "direct deposits": "ACH Check Clearing",
}

When MagicTouch invents a new deposit type label, Garrett opens the file and adds a line. No database migration. No deploy. No engineer.

The interactive y/s/d prompt, because automation shouldn’t be silent

I’d originally written the bank import as a one-pass loop that processes every matching file. Garrett pushed back. Half the time the glob picks up old downloads, partial files, test files from a vendor call. He wants to see each one and decide.

for f in files:
    print(f"\nFile detected:\n{f}")
    choice = input("Process this file? (y = yes, s = skip, d = delete): ").strip()
    if choice == 'y': approved.append(f)
    elif choice == 's': pass
    elif choice == 'd': os.remove(f)

This is the kind of detail you only know if you watch the work get done. The script could be silent. The accountant doesn’t want silent. Trust grows by showing each step.

Retry with backoff, because Sheets API throttles

Long imports hit APIError: Quota exceeded two or three times mid-run. The decorator that wraps every Sheets call:

def retry_with_backoff(retries=5, backoff_in_seconds=1):
    def decorator(func):
        def wrapper(*args, **kwargs):
            for x in range(retries + 1):
                try: return func(*args, **kwargs)
                except APIError as e:
                    if x == retries: raise
                    time.sleep(backoff_in_seconds * (2 ** x))
        return wrapper
    return decorator

Garrett never sees the throttle. He sees a one-line “retrying in 4s” message and the run continues.

By the numbers

~400 hrs/yr

of senior accounting time saved

6-8 h → 30 min

weekly reformat workload

small Python scripts, one per system

	Before	After
Weekly accounting reformat workload	~6-8 hours	~30-45 minutes
Of which is actual work	All of it	Downloading files + answering y/s/d
Reformat errors per quarter	Occasional silent paste-wrong-column	Near zero (deterministic output)
Lines of code per script	80-500	Short enough to read in 10 min

The pattern here matters more than the code. Most internal automation projects fail not because the engineering is bad but because the engineering builds a platform when the user wanted a tool. A tool is a thing you keep in a drawer. A platform is a thing you log into. Tools are easier to trust.

Garrett doesn’t run a server. He runs scripts. Six months in, he has already edited two config blocks himself when a vendor renamed a column. He didn’t need to file a ticket or wait for me. That’s the deliverable I was aiming for: not automation that requires an engineer to maintain it, but automation that belongs to the person using it.

How I replaced a $98K quote with a $50-a-month tool

Sat, 02 May 2026 00:00:00 GMT

About 10-15% of the 600 CBCT scans that flow through our design team each month are unusable: motion blur, metal streaks, a missing jaw region, a calibration ring of death. A designer doesn’t catch it for twenty minutes. The case gets escalated. The patient gets a rescan appointment two days later.

That loop had been running for ten years.

A vendor offered to break it: $98K up front + $26K a year. Binary good/bad classifier, no MLOps, they keep the IP. Hybridge would have been paying $26K a year indefinitely to flag scans it never owned the logic for.

So I built it instead, as sole AI engineer at Hybridge, on a laptop GPU and a CPU-only Cloud Run service.

The cost picture, before anything else

$124K

vendor year-one cost

< $600

year-one cloud spend, in-house

100%

IP retained: weights, code, MLOps stack

	Vendor proposal	What I built
Year 1	~$98K + $26K = $124K	< $600 cloud spend
Year 2 onward	$26K / yr	< $600 / yr
IP	Vendor keeps it	100% ours
Scope	Binary classifier	13-class taxonomy + 4-family routing + active learning + full MLOps
Hardware	TBD	None bought, RTX 4080 laptop existed

The model picked itself

When the project started I had 17 to 23 labeled studies. At that data size, picking a single architecture is a coin flip. So I built six in parallel behind the same interface:

A   ConvNeXt-Tiny + gated-attention MIL
B   ConvNeXt + 4-layer Transformer over slices
C   MONAI DenseNet-3D
D   nnU-Net adapter
E   3D VAE (anomaly)
F   ST-MAE (reconstruction anomaly)

Let the data tell me which one held up. Model F won round one. Then Model H, an architecture using a frozen DentalSegmentator nnU-Net encoder with a small multi-scale head, won the production slot once I had more labeled bads to evaluate against.

The whole stack in one diagram:

CBCT volume (1, 64, 224, 224)
    │
    ▼
Frozen DentalSegmentator encoder (30.79M params, no gradients)
    ├─ deep stage  → global pool      (320 dims)
    ├─ mid stage   → global pool      (256 dims)
    └─ early stage → BiGRU + attention (512 dims)
    │
    ▼
Concat (1088 dims) → small head (500K trainable params)
    │
    ├─ Binary head (good / bad)
    └─ Family head (clean / patient / xray / scanner)

13-class assignment is done by a deterministic router downstream, because eight of the thirteen classes have exactly one training sample. Don’t try to learn what you can compute.

The painful lesson

After several weeks of tuning, my test AUROC came in at 0.80. Beautiful number. I drafted the announcement.

Then I went back and checked the splits one more time. Seven of the ten test bads had also appeared in earlier training during an experiment I’d run. They’d leaked. After redoing the split cleanly, the honest test AUROC was 0.6309.

I shipped 0.6309.

<$50/mo

Cloud spend vs the $124K year-one vendor quote, same ten-year operating loss closed in-house

Shipping 0.80 would have promised something the model couldn’t deliver. The next person to run a proper holdout would have caught it. Better to be honest about where the model stands and lean on the active-learning queue for borderline cases.

A 99%-accurate model with no lineage and no honest holdout is operationally worse than a 75%-accurate model with both.

Cost-tuned threshold, not accuracy-tuned

A missed bad scan costs 24-48 hours of delay plus a rescan appointment. A false positive costs maybe 30 seconds of human review. So the threshold isn’t tuned to maximise accuracy. It’s tuned to minimise this cost:

cost = 15 × FN_count + 1 × FP_count

That gives an operating threshold of 0.176 on the binary score. Anything within ±0.10 of that lands in a human-review queue, which feeds the next retrain.

Production deployment in one paragraph

Cases flow in from MagicTouch DLCPM over SFTP (no API license needed). Eventarc fires on the GCS upload. Cloud Run pulls the encoder (OpenVINO IR, immutable per release) and the head checkpoint (hot-swappable via GCS, no rebuild needed for retrain). End-to-end latency including PDF report generation: about 5.5 seconds.

The numbers that matter

	Before	After
Vendor cost over year 1	$124K + 22 hrs/mo of internal time	$0 external, <$50/mo cloud
End-to-end latency	n/a	~5.5 s
60-90 bad scans/month reaching design	24-48 hours wasted each	Caught at intake
Wasted design-team hours / month	60-120	Near zero
Patient case turnaround on affected cases	+24-48 hrs	Same-day

I ran six model architectures, picked the frozen-encoder design because the data supported it, and shipped 0.6309 when 0.80 would have looked nicer on a slide. A model on its own is a science fair. A model with SFTP fan-out, Eventarc, CICT gates, a tag-based release pipeline, a hot-swap retrain loop, and a dashboard somebody actually opens: that’s the thing that closes a ten-year operating loss. The number that matters isn’t the peak AUROC from a leaky split. It’s the one you can stand behind when the next holdout runs.

Teaching an AI to read the whole patient and lean toward a treatment, before the doctor does

Sat, 20 Jun 2026 00:00:00 GMT

Most of my projects start from a broken workflow. This one started from a clinician’s head, and it is the only one I have built where the point is to have an AI read the patient before the doctor walks in.

Dr. Frank LaMar, who founded the practice, has a way of reading a complex restorative case. He looks at the bone, the wear, the decay pattern, the patient’s own words about pain and confidence, and he forms a judgment about whether the natural teeth are a dependable long-term bet or whether the honest conversation is about replacement. The Centralized Diagnostic Filter, CDF, is the attempt to put that first read into software: take every input a case generates, let the AI surface the findings and lean toward a treatment direction, and hand the doctor a finished assessment to confirm or correct, before the consultation even begins.

That last part is the whole philosophy. The CDF is not AI that replaces the dentist, and it is not AI that just reads x-rays. It is a standardized restorative prognosis operating system, and its governing rule is simple: AI assists, doctors validate. The AI does the first pass. Every finding it produces is provisional until a doctor signs it.

This was the hardest requirements job I have done. The other systems replaced a spreadsheet or a brittle script. This one had to extract a thirty-year mental model from the person who has it, and shape it into something a computer can carry without flattening the clinical nuance that makes it useful.

What “reading the patient” actually means

A complex case is not one image. It is a pile of them, plus everything the patient says. The CDF pulls fourteen input classes into one place and analyses each for something specific:

CBCT scan, and a panoramic view derived from that same scan, not a separate one: 3D bone, ridge architecture, available bone for implants.
Intraoral scans from the TRIOS scanner: missing teeth, wear, occlusion, supraeruption, crowding, collapse.
Clinical photo series (full-face smile, retracted frontal, occlusal, buccal, profile): aesthetics, recession, support loss, visible deterioration.
Bitewings and periapicals: decay, recurrent decay, restorations, root canals, structural breakdown.
Risk survey: pain, embarrassment, function, urgency, dry mouth, smoking, grinding, medical risk, and treatment goals.

The AI’s job is to look across all of that and surface what a doctor would otherwise reconstruct by hand: where the decay is, which teeth are gone, what is restored, how much bone support is left, and how the upper and lower jaws are each holding up.

The output the doctor is meant to confirm

The CDF walks into the consult having already done the reading. For every case it produces the same artifact: findings surfaced, risk scored, prognosis classified for each jaw, and a single treatment-direction leaning chosen from a fixed ladder.

Leaning	What it says
Conventional Viable	The natural teeth are a dependable long-term bet
Conventional Compromised	Restoration is possible, but the risk factors are real
Localized Implant Enhancement	A segment needs implants, the rest can stay
Full Arch Consider	Replacement is worth the honest conversation
Full Arch Likely	Replacement is the more predictable path
Full Arch Highly Appropriate	Replacement is clearly the better long-term bet

It never states a final diagnosis. It proposes a direction, shows the evidence behind it, and leaves the call to the doctor. That is the difference between a treatment leaning and a treatment decision, and the whole system is built to respect it.

the doctor always confirms

The report suggests a leaning and surfaces the evidence for it. It never delivers a final diagnosis. That boundary is clinical and legal, and it is wired into the architecture, not left to discipline.

Phase 1: own the front door first

You do not build the operating system on day one. You build the thing the rest of it plugs into, and you ship it.

Today the patient assessment lives in a third-party intake platform. The HIPAA posture is unverified, one person is the single point of edit, output gets screenshotted by hand into OneNote, each patient’s Drive folder is populated manually, and there are three duplicate questionnaires for the three markets (Rochester, Buffalo, Syracuse). It works, but it is fragile and it is not ours.

Phase 1 replaces all of that with a HYBRIDGE-owned intake on Google Cloud: one questionnaire with location-aware routing for all three markets, a premium patient-facing PDF delivered the moment the patient submits, automatic filing into the patient’s Drive folder with no human in the loop, and self-serve admin so the practice’s intake lead can edit questions, manage recipients per office, and add team members without filing a ticket. BAA-covered, audit-logged, role-based from the first commit.

It reads less like a dental form and more like an Apple product. That is deliberate. A premium intake experience is the first thing a patient touches, and it is also the data plane the AI reads from later, so it has to be owned and structured from day one.

The risk model, kept intact on purpose

The clinical core of the intake is a future-tooth-loss risk score, and one of the firmest decisions was to preserve the model the practice already trusts rather than invent a new one.

It is twelve weighted questions. Smoking, uncontrolled diabetes, dry mouth, and a history of periodontal disease carry the heaviest weights; missing a full arch of teeth, family denture history, grinding and clenching, and self-rated hygiene fill in the rest. The weights sum to a 0 to 200 score across four bands:

Band	Score	What it frames
Low risk	0-25	Restoration is a viable long-term option
Above average	30-70	Restoration is possible, but other factors matter
High risk	75-100	Replacement may be the more predictable path
Very high risk	110-200	Replacement is likely the better long-term bet

The score is not a diagnosis. It is a way to frame the restore-versus-replace conversation in a consistent, defensible way. Keeping the existing scale and bands means a patient who took the old questionnaire and the new one will not see a confusing numeric shift. Same clinical meaning, better instrument.

The full report, in nine sections

Phase 2 is the report Dr. Frank actually sketched: every patient produces the same artifact set, and every doctor reads the same document. Those fourteen inputs land in one visual report organized into nine sections.

Executive Summary answers four questions in plain language: what is happening, how severe, the long-term outlook, and the most reasonable treatment direction.
Risk Scoring carries the 0 to 200 score and a separate read on long-term predictability.
Anatomical Mapping locates the sinuses, mental foramina, ridge architecture, available bone, and implant zones.
Bone Support Visualization is the centerpiece (more on it below).
Structural Analysis outlines missing teeth, restorations, bridgework, implants, root canals, retained roots, and structural collapse.
Functional Analysis grades occlusal wear, guidance, posterior support, parafunction, and occlusal disease from none to severe.
Prognosis classifies the maxilla and mandible separately, because an upper jaw can be poor while the lower is fair, and that distinction changes the plan.
Patient Impact surfaces the emotional and functional drivers from the survey: this is the “why now” that a consultation lives or dies on.
Treatment Leaning picks a direction off the ladder above without ever stating a final diagnosis. The doctor always confirms.

The centerpiece: bone support, current versus ideal

The innovation at the heart of the CDF is not the AI. It is a way of showing bone.

Standardized Bone Support Visualization Mapping renders a patient’s current bone architecture against an ideal reference, so the support discrepancy and ridge atrophy are visible at a glance. A patient who would glaze over at a periodontal chart understands a picture of where their bone is versus where it should be. It also standardizes how doctors read periodontal health and frame long-term predictability. One concept, doing real work for both audiences.

There is a clinical insight underneath it that the system has to respect: not every heavily restored mouth is failing. The design distinguishes a generalized terminal dentition from a stable restorative adaptation, evaluating bone support, decay pattern, maintainability, biological risk, functional stability, and restorative burden rather than just counting fillings. That distinction came straight out of early testing, and getting it wrong would make the system confidently misleading.

The AI layer, and where it is allowed to act

Phase 3 is the part that makes the heading literal: the AI does the reading. Decay, missing teeth, restorations, and root-canal identification on 2D radiographs, plus the bone-level mapping that feeds the visualization. It assembles all of that into the draft assessment before anyone sits down with the patient.

But every AI output lands in a doctor validation queue and stays provisional until a doctor signs it. Those corrections are not discarded. They feed a continuous-learning loop on HYBRIDGE’s own validated cases, so every signed case strengthens the next prediction. The AI reads first, the doctor decides, and the doctor’s decisions are what teach the AI. The data compounds, and it stays ours.

That ownership is a principle, not an afterthought. Data, code, brand, and integrations live under HYBRIDGE accounts with no vendor lock-in, the schema is versioned and auditable from day one so Phase 4 plugs in without re-architecture, and Phase 4 itself is the integration layer: write-back into practice-management software so nobody re-keys data, outcome tracking that validates predictability against real results, multi-office rollout, and a pre-consult patient portal.

The roadmap, with honest status

Each phase ships independently and delivers visible value without waiting on the ones after it.

Phase	Scope	Status
1: Questionnaire system	HYBRIDGE-owned premium intake, PDF, auto-distribution, self-serve admin	In build
2: Diagnostic report (CDF v1)	One report from fourteen inputs, consult dashboard, risk + treatment lean	Designed, queued
3: AI-assisted findings	Radiograph assist, bone-support visualization, doctor validation queue	Designed
4: Scale and integrations	PMS write-back, outcome tracking, multi-office, patient portal	Planned

What is actually in place today, with no rounding up: the spec is written and the architecture approved, with a 19-task implementation plan and three planning sessions done with the practice’s intake lead. The private repository is live under the HYBRIDGE org. The Google Cloud foundation is set up with a dedicated billing account, isolated dev and prod projects, Terraform-managed infrastructure, and HIPAA-eligible services only. The brand system is applied, six cover concepts are designed for the patient PDF, and the risk model is preserved at its existing scale and bands. Underway right now: the questionnaire schema (thirty-plus questions with conditional logic, fully tested), the patient form interface, the PDF report generator, and the email-and-Drive delivery pipeline.

Why this one is the interesting problem

The engineering here is real, but it is not the hard part. The hard part is the elicitation: sitting with a clinician, pulling the structure out of how he actually reasons, and deciding what a system should standardize versus what it must leave to the doctor. Get that boundary wrong in either direction and you have either a glorified form or a liability. Phasing it is how you de-risk it: own the front door first, prove the intake, then build the report, then let the AI read but never decide. The goal was never to automate the diagnosis. It was to have the AI do the first read so the doctor walks in already holding a consistent, legible, evidence-backed assessment, and still holds the pen.

How I built an AI that grades every patient consult

Tue, 19 May 2026 00:00:00 GMT

Every week, implant consultations finished and nothing happened to them. The doctor moved on. The treatment coordinator moved on. Our CEO, Dr. Frank LaMar, had a seven-criterion framework for what a good consult looks like. It lived in a Word doc. Nobody else could apply it at the speed the practice runs.

So the coaching loop closed on maybe a handful of cases a week: the ones Frank had time to pull up himself. The rest were invisible.

I was the only engineer on this. I had Zoom webhooks, Vertex AI, and a Google Workspace with no Super Admin access. I built the pipeline that reads every transcript, scores it against Frank’s rubric, and gets a color-coded report to the doctor, the TC, and Frank before the patient’s follow-up window closes.

The flow, end to end

Zoom consultation finishes
        │
        ▼  recording.transcript_completed webhook
Cloud Run (FastAPI)
        │
        ├─ filter: is this actually a consult?
        ├─ resolve identity: who's the doctor, the patient, the TC?
        ├─ score: Vertex AI Gemini, schema-validated, retry once on fail
        ├─ render: color-coded HTML + PDF report
        ├─ archive: Drive folder by location / month / patient
        ├─ send: Gmail to doctor + CEO + TC
        ├─ append: one row to a master Google Sheet (48 columns, locked)
        └─ audit: BigQuery row with no PHI

Total time from transcript-ready to email in inbox: 5-15 minutes.

Three constraints I had to design around

HIPAA. Every transcript is PHI. Everything stays inside Google’s BAA boundary. No PHI in any log line, ever.

No Workspace Super Admin. I’m not the org admin. Domain-Wide Delegation (the standard way to give a service account Gmail/Drive access on behalf of users) was off the table. I used a user-OAuth grant on my own account instead, with the refresh token in Secret Manager. The Workspace sees a user account doing user-account-shaped things, which it already trusts.

Doctor-TC pairing is fully flexible. Any doctor can pair with any TC. There’s no default. The system has to figure out the doctor per meeting.

Doctor identity, three layers deep

1.  Zoom participants    →  email match → display name → alias match
2.  Transcript speakers  →  "Dr Mike:" speaker labels + alias match
3.  Gemini extraction    →  scorecard's doctor_name_candidates
4.  Unresolved           →  send to CEO only, prefix subject
                            [QA: DOCTOR UNRESOLVED]

Each layer returns a unique match, an ambiguous match, or no match. Ambiguity falls through. Unresolved cases don’t get silently dropped. They get flagged.

One detail I learned the hard way: short single-word aliases like “Frank” and “Mike” need word-boundary matching. Otherwise they fire inside patient names and casual speech all the time. Multi-word aliases like “Dr. Mike Baleno” are fine on substring.

The contract that killed half the hallucinations

Free-form LLM output is a bad pattern for anything that has to feed a database. The scorer doesn’t ask Gemini for a report. It asks for a JSON object that passes a JSON Schema.

If validation fails, the scorer retries exactly once with a hardened system prompt: “Your previous response failed schema validation. Output ONLY JSON. No prose. No markdown fences.”

If the retry also fails, it raises, alerts, and stops.

That single change cut hallucinations by ~35% versus the no-schema baseline. The model is the same. The difference is the shape it has to produce.

+130%

Treatment acceptance after every consult started getting coached, not just the few Frank had time for

Color coding against a rolling baseline

Each criterion gets a 1-10 score. The HTML email colors each one against the doctor’s own 30-day rolling average for that criterion, not a global baseline. That’s the only way the report makes sense when a new TC pairs with a doctor for the first time.

Rolling averages are read from the master Sheet every run, so the system never drifts from the ledger.

What it produced

	Before	After
Consultations scored	Frank’s hand-picked subset	Every implant consult, both Zoom orgs
Time from transcript to coaching report	Days, sometimes weeks	5-15 minutes

The number I care most about from an engineering standpoint is the hallucination cut. A schema and one structured retry turn the same model into a reliable producer of clean rows. The acceptance lift and revenue growth are downstream of what the coaching loop did with those rows.

Why this matters beyond the metrics

Each report quotes the doctor’s own words back to them, criterion by criterion, with at least one timestamped moment showing where the conversation landed and where it didn’t. The coaching is grounded in something the doctor already remembers, not an abstract principle.

That is what this project actually required: sitting with the clinicians and the TC long enough to understand why Frank’s Word doc worked for Frank, then translating that into a JSON Schema contract strict enough to produce clean database rows, inside a Workspace where I had no elevated admin rights and no margin for PHI leakage. The metrics are downstream of that translation. The engineering question was whether a hand-written rubric could become a repeatable system without losing what made it useful. It can.

How I built a clinic dashboard people actually trust

Tue, 12 May 2026 00:00:00 GMT

The previous dashboard hit Monday.com’s live API directly. It broke on rate limits, broke on schema changes, broke whenever a column got renamed. Every Monday morning the front office would open it and see stale numbers or an error. Leadership would pull their own exports. Two people would walk into the same meeting with different totals for the same metric, and the meeting would turn into an argument about the spreadsheet instead of the business.

At some point the front office stopped trusting their own reports. That is a worse problem than a broken API call.

I’m the sole engineer touching this system at Hybridge. The move I kept resisting was the obvious one: stop fighting the live API and pull from the weekly Excel exports Monday already generates. Stable files, predictable schema, no rate limits. Once I committed to that, the real problem became visible: the join was wrong.

Our dental practice runs two clinics. Each has a Patients board on Monday, both linked back to a single Leads board. To answer any real business question you have to join Patients to Leads. The old dashboard joined them by name. Two real people share a name. Typos happen. Monday inserts (copy) on duplicates.

I measured the damage one afternoon and almost didn’t believe the number:

Board	Name-based join	After the fix
Rochester Patients	49.5%	98.8%
Buffalo Patients	65.3%	99.9%

A third to half of our patients weren’t being linked to the original lead. Every funnel on every tab was off by a different amount. Leadership meetings were arguments about whose number was right.

The fix was a column I’d been looking at for months

Both Patient boards already had a real pointer field back to the Leads board. Monday calls it a board_relation. The API hides it. The Excel export shows it.

I switched the join from “match by name + creation date” to “match by the linked lead’s name string.” That one change took the linkage to 99%.

The 25 leftover patients were re-treatment cases the ops team had filed without creating a Lead row. Combined treatment value: ~$460k of patient value that nobody had been attributing.

~$460k

Orphan patient value surfaced after a single schema fix

One source of truth, finally

The old dashboard had filtering logic copy-pasted into eight tabs. They drifted. I rebuilt the data layer around three flat tables, one per Monday board, pulled from weekly Excel exports. Every metric lives in exactly one function:

function getLeads_(snap, f) {
  let n = 0;
  for (const l of snap.leads) {
    if (!locOk(l.location)) continue;
    if (excluded(l.reason_not_scheduled)) continue;
    if (!inRange(l.creation_date, f.start, f.end)) continue;
    n++;
  }
  return n;
}

Change the definition of “marketing source” in one place and every chart on every tab updates. Two tabs cannot disagree about the same number anymore.

What changed

A weekly workflow that used to eat 6-8 hours of senior time across the team now takes 3 minutes. The leadership meetings are about strategy, not arithmetic.

49% → 99%

patient-to-lead linkage, both boards

½ day → 3 min

weekly reconciliation, end to end

8 → 1

filter logics across tabs

The dashboard has six tabs: Dashboard, Monthly, History, Lead Sources, Trends, Playground. All pull from the same in-memory snapshot and the same metric functions. About 4,200 lines of Apps Script, deployed internally, costs nothing to run.

The front office uses this dashboard every day. They do not think about how it works. They open it, see one number, and trust it. That is only possible because every business rule lives in one function. When leadership asks “why does this tab say X,” there is exactly one place to look. The orphans do not disappear silently anymore. If a re-treatment patient has no Lead row, the dashboard shows them as an orphan instead of dropping them from the funnel. That is the job: not shipping code, but making sure the business can see itself clearly.

How I taught the consult grader to write report cards

Wed, 10 Jun 2026 00:00:00 GMT

Last month I wrote about the pipeline that grades every patient consult: a Zoom call ends, Gemini scores it against the CEO’s seven-criterion rubric, and a color-coded report lands in three inboxes within fifteen minutes.

That system has a quiet problem. It produces one report per consult. A doctor who did twelve consults last week got twelve separate emails, and the question that actually matters, how is this doctor doing, overall, lately?, was still answered the old way: someone scrolling through a spreadsheet, squinting.

So I built the layer on top. An AI reads all the scorecards we already saved and writes each doctor a coaching report card. Then it compares the doctors to each other, nicely.

What it does

You pick any set of doctors and any date range: last 7, 14, or 30 days, or your own. The system reads the stored scorecards. No re-watching videos, no re-reading transcripts; that work was already done at consult time.

For each doctor it writes:

✅ strengths
⚠️ things to improve
a short summary across the same 7 skill categories the per-consult grader uses

Then comes the part a spreadsheet can’t do: a comparison across everyone. What the top performers are doing differently. What’s worth copying. What isn’t. And it closes with three green “do this” and three red “avoid this” examples, each one pulled from a real consult, not invented.

The good part: it runs itself

Every Monday at 8 AM → last week’s report.
First workday of the month, 8 AM → last month’s report.

Cloud Scheduler fires, the report writes itself, and it lands in the CEO’s inbox and mine. Nobody clicks a button. Nobody remembers to run anything.

One small rule that matters more than it looks: a doctor with zero consults in the window gets skipped. No empty pages, no “N/A across 7 categories” filler, no spam. The report only contains people there’s something to say about.

Five bugs I squashed on the way

1. The picky robot. I reused the strict JSON Schema discipline from the per-consult grader: every response must validate, retry once on failure, then give up. For report cards, my schema was too strict. The model failed validation twice in a row and the batch quit with only 20% of the doctors done. The fix was humbling: I showed the model one worked example of a valid report and loosened the rules that were strictness for strictness’s sake. Now it finishes every run. Schema validation is a great servant and a terrible master.

2. The mystery email. The first version of the email contained a link. The link opened a wall of raw JSON. Technically the report was “delivered.” 🤦 Now the email is the report, readable HTML right in the inbox, with a proper PDF attached for anyone who wants to file it.

3. No clock in the box. “Every Monday at 8 AM” sounds simple until you ask the server whose 8 AM. The slim container image I deployed had zero timezone data in it. The moment the code asked for Eastern time, it would have crashed. Added the timezone package to the image. Crisis avoided before anyone got a 3 AM report card.

4. The ghost upload. My registry login had quietly expired. The image push failed silently, and the deploy yelled “image not found” at an image I was sure I’d just built. Classic. Re-logged in, verified the push actually landed this time, shipped.

5. The ugly radar chart. I gave each doctor a radar chart of their 7 categories. It looked bad. I deleted it. Zero regrets. Not every report needs a chart; some reports need fewer charts.

By the numbers

0 clicks

weekly + monthly reports, fully automatic

411

tests passing

3 + 3

real "do this" and "avoid this" examples per report

	Before	After
Per-doctor coaching view	Someone scrolls a spreadsheet	Written report card, per doctor
Cross-doctor comparison	Didn’t exist	Every report, automatically
Effort to produce it	Manual, whenever someone had time	0 clicks, Monday 8 AM + monthly
Doctors with no consults	Empty rows	Skipped entirely

Same privacy rules as the rest of the stack: no patient information ever lands in our logs.

Here’s the part worth noticing. Of the five bugs, exactly one was about the AI. The other four were an email, a clock, a login, and a chart. That’s been the pattern across everything I’ve shipped at Hybridge: the model is rarely the hard part. The hard part is the plumbing around it, and the plumbing is where the thing earns the right to run unattended at 8 AM on a Monday with nobody watching.

Building an enterprise search that knows when to say 'I don't know'

Tue, 23 Jun 2026 00:00:00 GMT

Every company my size has the same quiet problem. The answer to your question exists. It is in a slide deck from eight months ago, or a policy doc nobody re-shares, or in one person’s head, and that person is on vacation. So you ask around, you guess, and sometimes you act on a version of the truth that got replaced in March.

I am building the fix for Hybridge: an internal search where anyone signs in with their company account, types a question in plain language, and gets a real answer with the sources attached. We call it Ask Hybridge. People who are allowed to add documents drop them into a portal, and those documents flow through a careful pipeline before they ever become searchable.

The easy version of this is a weekend project now. You chunk some documents, embed them, stuff the top matches into a prompt, and call it RAG. I did not want the easy version. We work in healthcare, which means patient data, HR records, and trade secrets all live in the same building. In that setting a confident wrong answer is not a cute demo bug. It is a liability. So the whole design is organized around one idea: the system should be trustworthy first, and clever second.

The one rule everything serves

Here is the principle I keep coming back to. The system should answer from what it actually found, and when it did not find enough, it should say so. No filling the gap with a plausible guess. An honest “I don’t know, here is the closest thing” is a feature, not a failure.

That sounds obvious. It is surprisingly hard, and almost every shortcut in RAG quietly breaks it.

trust first, clever second

Every stage either makes the answer more trustworthy (hybrid retrieval, reranking, conflict resolution, citations, grounding) or it stays off the hot path until the evaluation says it earns its place.

Why I am not building a “basic” RAG

A basic RAG fails in three ways that matter in a real company, so I planned for all three from the start.

It fails on exact terms. Pure vector search is great at meaning and bad at specifics. Search a part number, a policy code, or a person’s name and a semantic-only index will hand you something that “feels related” instead of the exact match. The fix is to run keyword search and vector search together.

It fails on conflicts. Two documents disagree. One is the current SOP, one is a draft from last year that nobody deleted. A naive system picks whichever happens to rank higher and presents it with total confidence. That is the dangerous one.

It fails on permissions. The marketing team should never retrieve a document restricted to the clinical group, even by accident, even as “context” the model quietly reads. Access has to be enforced before retrieval, not bolted on after.

How a question gets answered (the read path)

When someone asks a question, the answer travels a fixed path. I kept the common case fast and simple, and put the expensive, clever steps behind a gate so they only run when a question actually needs them.

The read path, in order.

Rewrite the question only if it is vague or part of a back-and-forth chat. A well-formed question skips this.
Filter by permission first, as a database condition. Documents you are not allowed to see never enter the search.
Retrieve two ways at once: keyword search (BM25) for exact terms, vector search for meaning.
Merge the two result lists with Reciprocal Rank Fusion.
Rerank a small top slice with a dedicated ranking model, for precision without paying the latency on everything.
Resolve conflicts deterministically (see below).
Answer, citing the exact passages. If the evidence is thin, abstain.

Most questions are simple lookups, and they take the fast path and finish. Only the hard ones, the low-confidence or multi-step questions, trigger a corrective loop: re-plan, retrieve again, fall back to a web search if the answer genuinely is not in our knowledge, check the draft answer against the evidence, and only then respond.

I want to be clear about why that loop is gated rather than always-on. An agent that re-plans on every single query feels smart and behaves badly. It is slower, it costs more, and it pulls in noisier context that can make a simple answer worse. So the expensive behavior only switches on when a confidence check says the simple path did not work. The default is fast and boring. The cleverness is held in reserve.

When sources disagree, the model does not get to pick

This is the part I am most careful about. When two retrieved passages make conflicting claims, the model is never allowed to just choose one. A small piece of plain code ranks the evidence first, by rules anyone can read.

The conflict ladder (deterministic).

Group the evidence by what each piece actually claims.
Drop anything marked superseded or deprecated. A replaced document cannot win.
Higher authority wins (an official policy outranks a personal note).
If authority ties, the most recent effective date wins.
If it still cannot be resolved, declare the disagreement: show both answers with their author, date, and source, and say plainly that the sources disagree.

The model’s job is only to notice that two passages genuinely contradict each other and to write the answer in a way that honors that ranking, or to surface the disagreement honestly. The decision about which source is more authoritative is made by rules, not vibes. That is the difference between a search you can run a company on and a search that sounds confident.

What happens when a document comes in (the write path)

Retrieval is only as good as what got indexed, so the ingestion side gets the same care. A document does not become searchable just because someone uploaded it.

The write path, in order. Store the original safely and fingerprint it. Skip it if it is a duplicate. Parse it with layout awareness so tables and slides survive. Chunk it on real topic and structure boundaries, not blind fixed windows. Attach metadata and a short "document card" (a title, a one-paragraph summary, key entities, the effective date, who can see it). Embed in batches. Index the vectors, the keyword text, and the permissions together.

Two details there do a lot of quiet work. The document card stays small no matter how long the document is, so the system can route and display a document without re-reading the whole thing. And every chunk is stamped with the version of the embedding model and chunking strategy that produced it, so when I improve either one later, I can re-index safely instead of guessing what is stale.

The part most people skip: measuring it

Here is the question that started the whole project for me. How do I know the answer is good before I trust it? Most RAG demos never answer that. They look impressive in a screenshot and nobody checks the hit rate.

So I am building an evaluation harness alongside the system, not after it. It measures retrieval with the standard metrics (did the right document show up, and how high), and it measures the generation for faithfulness, whether every claim in the answer is actually backed by a cited source. It even runs a managed search product in parallel as a yardstick, so I can compare what I built against a strong baseline and know whether my extra machinery is earning its keep.

recall · nDCG · MRR

did the right source come back, and did it rank near the top

faithfulness

is every sentence in the answer grounded in a citation, or did the model improvise

vs. a managed baseline

my pipeline runs next to an off-the-shelf one so the comparison is honest

The harness is the referee. It is what decides when a fancier idea actually goes into production and when it stays a nice diagram. That rule is how I keep an ambitious system from turning into an over-engineered one.

The stack, in one box

Built on Google Cloud, open-source and GCP-native only (no third-party SaaS). Identity Platform for domain-locked Google sign-in. Cloud Run for the API and pipeline jobs, with Pub/Sub and Eventarc for event-driven ingestion. Document AI for layout-aware parsing. Vertex AI for embeddings, reranking, and Gemini for generation (a bigger model for ingestion, a fast one for most answers). Postgres on Cloud SQL holding the vectors (pgvector), the keyword index, the metadata, and the access rules in one place. Terraform for the infrastructure, Cloud Build for CI/CD. Everything chosen is HIPAA-eligible under a Google business associate agreement, with customer-managed encryption and full audit logging.

I deliberately started on Cloud SQL with pgvector instead of a heavier specialized vector database. It meets every need we have at our current size of hundreds to low thousands of documents, at roughly half the cost, and there is a clean upgrade path the day the evaluation harness tells me I have outgrown it. That is the theme again: pick the simple thing, and let the measurements, not the hype, tell me when to add complexity.

Where it stands, with no rounding up

I am building this the way you would teach it, one stage at a time, because each stage is also a chunk of RAG I wanted to learn properly by hand.

Stage	What it owns	Status
Foundation and auth	GCP setup, domain-locked sign-in, roles and groups, secrets, CI/CD, infrastructure as code	Shipped
Ingestion	upload, dedup, parse, chunk, metadata, embed, index	Designed, in build
Query serving	rewrite, filter, hybrid retrieval, rerank, conflict resolution, grounded answer	Designed
Evaluation	retrieval and faithfulness metrics, conflict tests, managed baseline	Grows alongside the two above
Search and Dropoff front ends	the chat experience and the upload portal	Designed

What is real today: the foundation and authentication layer is shipped and running. Sign-in is locked to the company domain, roles and groups are enforced, and the whole thing stands up from a clean checkout through Terraform and a tested CI/CD pipeline. The ingestion pipeline is fully specified and in build. The rest is designed in detail and queued behind it.

That is the honest status. I would rather show you a trustworthy foundation and a clear plan than a flashy demo that falls over the first time two documents disagree. The whole point of this system is to not do that.

How I caught fake news and read the mood of an election

Sun, 12 May 2024 00:00:00 GMT

Everyone says they want to “detect fake news.” That phrase is hiding two completely different jobs.

Job one: someone makes a claim. Is it true? That’s a fact-checking problem.

Job two: a million people are tweeting about that claim. How do they feel, and what are they actually mad about? That’s a mood problem.

For a grad-school project on the 2020 US election, I built both. And the fun part is: the AI models were the easy bit. The hard, messy, interesting work was everywhere else.

Two jobs, two models

I didn’t try to make one giant model do everything. That almost never works. Instead I picked the right tool for each job.

                  text comes in
                       │
        ┌──────────────┴──────────────┐
        ▼                             ▼
   Is this claim fake?           How do people feel?
   Llama 3 (8B)                  RoBERTa
   trained on labeled claims     trained on tweets
        │                             │
        └──────────────┬──────────────┘
                       ▼
              What are they arguing about?
              (topic grouping)

For the fake-news job, I needed a model that understands the meaning of a short, slippery political statement. I used Llama 3, a big language model, and trained it on a public set of claims that experts had already labeled true or false.

For the mood job, I had 1.8 million tweets and zero patience for a slow, expensive model running on all of them. So I used RoBERTa, a smaller, faster model that’s great at reading tone. The right tool isn’t always the biggest one. At 1.8 million tweets, “cheap and fast” wins.

The cheap trick that made the big model affordable

Training an 8-billion-parameter model sounds like it needs a server farm. It doesn’t, if you’re a little clever.

I used a trick called QLoRA. The short version: instead of retraining the whole giant model (expensive, slow, needs lots of memory), you freeze it and train a tiny add-on layer on top. The big model stays put; you only teach the small new piece. It fits on a single regular GPU, and the thing you ship at the end is a few megabytes instead of gigabytes.

76%

accuracy on hard, expert-labeled claims

1 GPU

all it took, thanks to the QLoRA trick

megabytes

the size of what I actually shipped

76% accuracy might not sound flashy, but these claims are short and politically loaded with no extra context to lean on. They’re genuinely hard. If I’d reported 95%, I’d have assumed I’d cheated somewhere by accident.

What actually broke (and what it taught me)

The model learned to be lazy. The labeled claims weren’t evenly split, so my first model figured out it could look smart just by guessing the most common answer. Accuracy looked fine; the model was useless. The fix was to stop trusting one number and start checking how it did on each type of claim. Lesson that stuck: a single accuracy score can lie to your face.

My two models disagreed on basic cleanup. Early on, the tweet cleaner and the claim cleaner were slightly different, so “the same sentence” got chopped up two different ways depending on which model saw it. I merged them into one shared cleanup step. Boring fix, big difference.

My “topics” were mostly punctuation. I also grouped the tweets by topic to see what people were arguing about. The first run proudly told me the hottest topics were… hashtags and exclamation marks. After cleaning those out, real themes finally showed up.

So what’s the actual takeaway?

The flashy way to describe this is “I fine-tuned an LLM to detect fake news.”

The honest way is “I figured out there were two different problems, used a cheap fast model for the big firehose and a smart one only where it mattered, and refused to believe a single accuracy number without looking underneath it.”

The model is the footnote. Knowing which problem you’re solving, and how you’ll know you solved it, is the actual job.

That’s the habit I took from this one: when someone hands you a big fuzzy goal like “detect fake news,” the first move isn’t to grab a model. It’s to ask what you’re really being asked to do.

Full project: Fake News and Sentiment Analysis.

How making movies made me a better engineer

Wed, 20 May 2026 00:00:00 GMT

I make movies. I write screenplays, direct, edit, occasionally compose music. I also build production AI systems at a dental implant company. People keep treating those two as separate. They aren’t.

The customer is the cast. The system is the scene. The job is to make the scene work for them.

Here’s the credit list, so we’re talking about specifics:

Year	Project	Role
2026	Among Monsters (IMDb)	Director / Writer / Editor / Color / Music
upcoming	Extraordinary Lives	Director / Writer
upcoming	Pupa	Writer
2025	Solistice	Editor
2024	Swecha	Editor
2022	Tiger Man	Director / Writer / Editor
2019	Strangers	Cinematographer / Music

I’m cutting Among Monsters between work weeks right now.

A film set looks like an engineering room

A small short has a director, a writer, a DP, a sound mixer, a gaffer, a costumer, an art department, an editor. Each one speaks a different vocabulary. Each one defines “done” differently. Your job as director is not to know how each department does its job. Your job is to translate the scene you’re trying to make into the eight languages on your set.

This is the same situation I walk into at work. The senior treatment coordinator who’s quoted full-arch implant cases for ten years doesn’t care about my Postgres trigger. She cares whether the system gives her the same number she quoted last month. The controller doesn’t care about my retry-with-backoff decorator. He cares whether the bank CSV makes it into the cashflow sheet before his 5pm cutoff.

Specialists. None of them wrong. One person whose job is to make it add up.

Things I do at a keyboard that I learned on set

Block before you light. On set, you walk the actors through the scene before anyone touches a lamp. In code, I write the ADR before I touch the schema. Every project I’m proud of has a spec written first. Building from a shape you’ve sketched costs less than building from a shape you haven’t.

Listen to the script supervisor. The script supervisor has the lowest credit on the call sheet and the highest practical authority on the day. The engineering equivalent is the person who does the actual work every day. Garrett knew the bank CSV glob picks up half-downloaded files. I would not have built the y/s/d prompt in the cashflow import if he hadn’t told me.

Cut to the bone. Editing a film is mostly about removing. A 20-minute short usually starts as a 45-minute assembly. The cuts that hurt to make are usually the right ones. The same with code. The dashboard rebuild replaced 2,803 lines of live-API code with 1,400 lines of weekly-Excel code that’s strictly more correct. Less is harder than more.

Show one cut to the right person. The first person I show a rough cut to isn’t another editor. It’s somebody from the target audience. I don’t ask for notes. I watch them watch it. Same thing in code: the first demo of a new feature isn’t to the engineering team. It’s to the person who’s going to use it every day. I’d rather watch Chelsea fumble through the tooth chart for thirty seconds in silence than read a stakeholder Slack thread about it.

A scene works or it doesn’t. Films don’t get judged on the elegance of the camerawork. They get judged on whether the scene works. A great scene with one bad cut is still a great scene. A polished sequence of bad scenes is a polished bad film. I’m relentless about whether the shipped thing actually solved the problem the customer brought.

What this does to the engineering portfolio

Three things, all downstream of the same instinct:

The customer is the cast. The system is the scene. The job is to make the scene work for them.

The systems I ship survive contact with non-engineers. Consider the quirks in the dashboard, the estimator, the consultation pipeline: the deliberate inclusion of “Hung up” leads in the Scheduled count, the orphan re-treatment patients shown in a Data Quality panel but still counted in CA, the three-affordance wizard orientation. None of those are technical decisions. They’re judgement calls from arguments with the people who’d be using the thing.

I can work alone in scopes that would normally need a team. A director on a small short is the writer, the editor, the colourist, the producer’s bad cop, the actor’s good cop. I went into engineering already used to wearing eight hats on a project. The single-person Hybridge work (CBCT validator + estimator + consultation pipeline + dashboard + accounting suite) wouldn’t have been possible without that muscle.

The post-mortem is part of the work. Every film I’ve made gets re-watched a year later with a list of “what didn’t work and why.” Every system I’ve shipped has a BACKLOG.md of consciously-deferred items with revisit triggers. Same instinct: name the loose ends out loud, then come back when the moment is right.

The version a hiring manager wants

If you’re hiring an engineer who can sit with a customer until the system you ship is the system they needed, that’s the work I want. The Hybridge portfolio is what comes out the other end when you treat every project like a small film. A spec written before the schema. A handful of department heads who all need to be heard. A scene that needs to actually work. A cut that gets shorter every week until it’s the right length.

Two crafts, same muscle.

I built an open-source app to run my job hunt

Sat, 13 Jun 2026 00:00:00 GMT

A few days ago I built JobPilot in about five hours: a job-search autopilot that runs on GCP while I sleep. Then I actually used it, every day, and kept fixing what annoyed me. It has since grown from a one-night hack into the thing my whole search runs on, so today I did the obvious last step and open-sourced it: github.com/SampreethAvvari/job-pilot, MIT, with a fork guide written to be handed straight to a coding agent.

Here is what it does now, and why it quietly turned into four projects wearing one trench coat.

What a morning looks like

I open the console, sort by recently posted, and run down one role category at a time. Each job already has a fit score, a one-line “why,” and the right tailored resume sitting one click away. I read the score’s reasoning, hit Apply ↗, and the posting opens in a new tab. When I come back, the console asks whether I actually applied; yes stamps the date and moves it to Applied. An irrelevant job gets one ✕ and is gone forever, but logged, so the dismissals become filter training data later.

That is the whole daily ritual. No scrolling LinkedIn, no rereading the same reposted listing, no tab graveyard. The machine did the finding, scoring, and writing overnight; I do the deciding.

Where the jobs actually come from

The trick is still to skip the aggregator lag and read companies’ own boards. JobPilot now watches 160+ company career pages directly across seven ATS types (Greenhouse, Lever, Ashby, Workday, SmartRecruiters, Workable, Recruitee), plus RemoteOK, Hacker News “Who is Hiring,” Adzuna, and LinkedIn through a pay-per-result Apify actor. Adding a company is one row in a watchlist: I paste a name and a careers URL, a resolver works out which of the seven ATSs it runs on, and that board joins the next poll. Eleven source adapters, one normalized job behind them. Free sources get polled every hour; the full run (LinkedIn, tailoring, outreach, digest) fires four times a day.

Two walls run before any compute is spent. A regex wall drops citizenship, clearance, and “cannot sponsor” postings, plus senior/staff/contract titles I’d never apply to. A new US-only location wall drops non-US roles entirely, and it knows that a state code beats a city-name collision, so “Vancouver, WA” stays and “Vancouver, BC” goes. A job posted on a company’s board this morning is in my console by the next hourly run.

The scorer, and the resume judge that argues back

Every surviving job goes to Vertex AI Gemini under a JSON-schema contract: fit 0 to 100, the reasoning, a sponsorship signal, a role category, and which of my four resume variants fits best. Anything scoring 60+ gets tailored automatically.

The piece I’m proudest of is the judge. My first version’s “ATS check” gave my real resume a 100 while ResumeWorded gave it a 73. So I rebuilt the grader as a replica: about 40 deterministic checks weighted impact 35, brevity 20, style 15, sections 15, soft-skills 15. Then every resume, master or per-job tailored, runs a judge-guided rewrite loop:

judge → violations list → Gemini rewrites (truth-locked) → recompile → judge again

Up to ten attempts, early exit at 90, and the best attempt wins. A rewrite that scores worse is thrown away; the system can only ever publish an improvement. The rewrites are truth-locked: reorder, rephrase, and re-emphasize, yes; invent an employer, a date, or a metric, never. My real score went 73 to 82 on one calibration pass, and every application ships with its own ATS report you can open in the console.

The copilot

The biggest addition since launch is a grounded chat assistant. It loads a knowledge pack (my GitHub, this portfolio, my resumes, my profile) and answers through a guardrailed Vertex chat, so it talks about my search with real context instead of guessing. Every job row also has a 💬 that opens its own independent chat drawer with the live job description fetched on the spot, and I can attach a PDF or an image (a JD screenshot, a recruiter’s note) straight into the conversation. There’s also a manual-job tailor flow for the role a friend forwards that no board ever surfaced.

More than a table

The console grew with the search. It is no longer one screen but a small app: a jobs registry I triage every morning, an applied funnel that advances itself as replies arrive, a replies feed, a resume armory that shows each of the four variants with its live ATS score and a one-click rebuild, a companies watchlist with per-board health, and an outreach console where the drafts wait. The Google Sheet underneath is still the database, so I can fix anything from my phone and the console just reflects it.

It never sends anything on its own

Two rules I refuse to ship without. The system never sends an email by itself: recruiter outreach is looked up through Apollo, written, and dropped into my Gmail drafts for me to send. For a company on my watchlist I have not applied to yet, it can find two or three hiring contacts and draft a cold intro the same way. Every one waits in drafts until I read it and hit send. And automation never overwrites my manual edits; it only moves a status forward.

The reply tracking got smarter too. An hourly inbox watcher reads the last couple of days across every inbox I connect, and a genuine next step (interview invite, scheduling request, assessment) triggers an instant alert email telling me which company replied in which inbox, with a link to the exact message. Rejections quietly update the tracker; “thanks for applying” autoresponders are ignored.

Why it ended up being four projects in one

This is the part that surprised me. JobPilot isn’t an AI project or a web project. It’s all four things I do, stacked:

Data + ML

11 source adapters behind one schema; schema-locked Gemini scoring, a calibrated judge, and a truth-locked rewrite loop

Software

Next.js 16 console behind IAP, a Cloud Run pipeline, 50+ tests, keyless CI/CD on Workload Identity Federation

Shipping

I was the user, so the spec was "what annoyed me yesterday." Every feature earned its place by surviving the next morning's search

That’s the data engineer, the ML engineer, the software engineer, and the forward-deployed instinct of building the thing that actually gets used, in a single repo. It’s the most honest portfolio piece I have, because I run it on myself.

Fork it

The whole thing is public under MIT: github.com/SampreethAvvari/job-pilot.

A fork guide (docs/FORK-SETUP.md) written to be handed directly to an AI coding agent, covering every gcloud command, every OAuth click, and exactly which Google scopes it needs and why (drafts-only email, never auto-send).
A structured bug log of everything I hit, so nobody pays the same tuition: the XeTeX PDFs that ATS parsers read as “New Y ork,” the Docker CMD that ate my job arguments, the 163-board parallel fetch that OOM’d at the default memory.
Zero secrets and zero personal data in the repo or its history. My resumes and profile live in Secret Manager; the repo ships a Jane Doe template.

By the numbers

160+ boards

company pages watched directly, plus 4 aggregator sources

73 → 82

real ResumeWorded score after one calibration pass

~1¢

per tailored resume + cover letter, rewrite loop included

	A normal job search	JobPilot
Job freshness	days to weeks old, reposts	hours old, straight from company boards
Sponsorship dead ends	you read every one	dropped before they reach you
Resume per application	one generic PDF	1 of 4 variants, tailored and judged, ~1¢
Tracking	a spreadsheet you forget	statuses update from your inbox
When a recruiter replies	you notice eventually	instant alert, with the message linked

The first post said a job search is a pipeline problem, not a willpower problem. Three days of using my own pipeline taught me the sequel: a job search is also a product problem. The reason it works is not the model. It’s the hundred small decisions around the model about what to drop, what to trust, and what to leave to me. So I open-sourced all of them.

How I built a job-search autopilot in 5 hours

Wed, 10 Jun 2026 00:00:00 GMT

Here’s what applying from LinkedIn alone actually looks like: a posting says “2 weeks ago,” it’s been reposted twice, 1,000+ people clicked Apply, and (the part that stings if you’re an international student) paragraph six says “unable to provide visa sponsorship.” You read all of it anyway. Multiply by fifty, every day, forever.

I decided my evenings were worth more than that. So one night I sat down with Claude Code and built JobPilot, a job-search autopilot that runs on GCP while I sleep. Total build time: about 5 hours.

Where the jobs actually come from

The trick is to skip the aggregator lag and go to the source. JobPilot pulls from 7 sources, almost all free:

Greenhouse, Lever, and Ashby: the ATS boards companies actually post to first. I watch 39 companies directly: Stripe, Anthropic, OpenAI, Databricks, Notion, Ramp, Figma, Datadog, Palantir, Cursor… These APIs are public, keyless, and free.
Hacker News “Who is Hiring”: free via the Algolia API.
RemoteOK: free public JSON.
Adzuna: free API key, capped to postings ≤ 2 days old.
LinkedIn: yes, it’s still in there, via an Apify scraper actor on free credits, capped at 50 results from the last 24 hours so it never costs real money.

A job posted on a company’s Greenhouse board this morning is in my inbox by the next run. That’s the whole point: I see jobs hours old, not weeks old.

The pipeline (runs 4× a day)

Cloud Scheduler kicks off a Cloud Run job at midnight, 6 AM, noon, and 6 PM ET:

fetch (7 sources)          ~100 jobs per source, in parallel
  → filter                 drop stale, senior, contract, no-sponsorship
  → dedupe                 SHA1(company|title|location) across sources
  → score                  Gemini 2.5 Flash, fit 0-100, batches of 10
  → record                 Google Sheet, 27 columns
  → scan Gmail             classify replies → update statuses
  → tailor                 auto-tailor every job scoring ≥ 60
  → digest                 one email: today's shortlist, ranked

The dedupe step matters more than it sounds: the same job shows up on LinkedIn, Adzuna, and the company’s own board. JobPilot hashes company + title + location, keeps the highest-fidelity source, and I see it exactly once.

Built for the international-student reality

This is the part no job board does for you. Before any job even reaches the scorer, 13 regex patterns auto-reject the dead ends:

“US citizenship required” → gone
”security clearance / TS-SCI / polygraph / ITAR” → gone
”unable to provide visa sponsorship” / “cannot sponsor” → gone
senior / staff / principal / 5+ years / contract / part-time → gone (I’m early-career; 0 to 2 years only)

Then the scorer double-checks: if the description hints sponsorship is unlikely, the fit score gets capped at 10 and the row is auto-rejected with a note. I never spend ten minutes reading a posting that was never going to work.

Four resumes, tailored while I sleep

I keep 4 master resumes as one-page LaTeX files: SDE, MLE, AI Engineer, and Forward-Deployed Engineer. The scorer picks which variant fits each job, then Gemini tailors it:

Automatic for anything scoring ≥ 60 (capped at 15 per run).
One click for everything else, a Tailor button in the dashboard.
Output: a tailored one-page PDF plus a matching cover letter, compiled with pdflatex, filed into Drive as {company}_resume.pdf.

Two guardrails I refuse to ship without. First, truth: the model may reorder, rephrase, and re-emphasize, but it may never invent an employer, a date, a metric, or a skill. Second, format: if the PDF spills past one page, it gets recut automatically, and an ATS check gates every resume at ≥ 85% keyword coverage.

Cost per tailored resume + cover letter? About a penny. Gemini 2.5 Flash is absurdly cheap for this.

The application pipeline, tracked

Every job moves through stages in the Sheet: New → Applied → Response → Interview → Offer (or Rejected). The fun part is that the statuses update themselves: a Gmail scanner reads the last 3 days of replies, matches them to tracked applications, and classifies each one: rejection, interview invite, next steps.

Two hard rules: the system never sends an email on its own (outreach drafts land in my Gmail drafts, I hit send), and automation never overwrites my manual edits, it only ever moves a status forward.

The dashboard

A Next.js console on Cloud Run (locked behind IAP, so only I can see it) sitting on top of a Google Sheet that serves as the entire database. Filter by fit, source, status, resume variant; click Tailor; read the “why” the scorer wrote for each match. Plus a morning digest email with the day’s shortlist ranked by fit. Most days I make my apply list from the email alone.

Tech stack & what it costs

Pipeline: Python 3.12, httpx, pydantic, on a Cloud Run job
Brain: Gemini 2.5 Flash on Vertex AI (scoring + tailoring + reply classification)
Resumes: LaTeX + pdflatex in Docker
Dashboard: Next.js 16 on Cloud Run, behind IAP
Database: a Google Sheet (genuinely; it’s free, visual, and I can edit it from my phone)
Glue: Cloud Scheduler, Secret Manager, GitHub Actions auto-deploy on push

	Cost
Setup	$0
Cloud Run + Scheduler + Sheets + Drive	≈ $0 (free tiers)
Gemini 2.5 Flash (scoring ~hundreds of jobs + tailoring daily)	pennies
Apify LinkedIn scraper	$0 to $5/mo (free credits)
Total	< $5/month

By the numbers

5 hours

idea → deployed on GCP

< $5/mo

to run the whole thing

~1¢

per tailored resume + cover letter

	LinkedIn alone	JobPilot
Job freshness	days to weeks old, reposts	hours old, straight from ATS boards
Sponsorship dead ends	read them all yourself	auto-rejected before you see them
Resume per application	one generic PDF	1 of 4 variants, tailored per job, ~1¢
Tracking	a spreadsheet you forget to update	statuses update from your inbox
Daily effort	hours of scrolling	read one digest email

One last detail: the hero image on this post was generated by Nano Banana inside the same GCP project the pipeline runs in. The job hunt is fully on-brand now.

The realization that made me build this: a job search is a pipeline problem, not a willpower problem. Recruiters have ATS systems, dashboards, and automation on their side of the table. There’s no rule that says applicants can’t have the same. Mine just had to cost less than a coffee.

How I trained Llama to argue more convincingly

Wed, 10 Sep 2025 00:00:00 GMT

I worked on this with Prof. Marco Morucci’s group at NYU, and the question sounds simple: take a controversial claim, and train a model to write a comeback that real people find more convincing than what the model already said.

Simple to ask. Sneaky to pull off. Most people assume the magic is in which training algorithm you pick. It isn’t. By the time I got to the fancy algorithm choices, that part barely mattered. The thing that decided everything was much earlier and much more boring: where do you get good examples of “convincing,” and how do you stop the model from learning the wrong lesson?

Where do you find “convincing” arguments?

You need examples of arguments that actually changed someone’s mind. Turns out Reddit has a perfect spot for this: a community called ChangeMyView, where someone posts an opinion and hands out a little award (a “delta”) to any reply that genuinely changes how they think.

That award is gold. It’s a real human saying “okay, you convinced me.” So I mined a few years of these debates and built pairs:

the winner: a reply that earned a “you changed my mind”
the loser: a reply in the same thread that didn’t

That gave me about 38,000 clean pairs. I split them carefully so the same debate never showed up in both training and testing, otherwise the model could just memorize instead of learn.

The plan, in plain English

38k "winner vs loser" pairs
        │
        ├─ Step 1: show Llama lots of winning replies
        │          (basically, "write more like this")
        │
        ├─ Step 2: train a JUDGE model
        │          (given two replies, which one won?)
        │
        └─ Step 3: let Llama practice, and reward it
                   whenever the judge likes its answer
                │
                ▼
        Test it: real people, blind, pick the better reply

Three moves. First, teach Llama to imitate good arguments. Second, train a separate judge model that can look at two replies and call the better one. Third, let Llama practice writing arguments and give it a thumbs-up whenever the judge approves. That last loop is the “RLHF” everyone talks about. It’s really just practice with a scorekeeper.

What broke (and what it taught me)

The judge fell for long-winded answers. My first judge quietly decided that longer meant more convincing. So when Llama practiced against it, Llama learned to just… ramble. More words, higher score, worse arguments. The fix was to make sure my winner/loser pairs were about the same length, so the judge had to learn quality, not word count.

Two versions of “the same” model didn’t match. A couple of pieces had been built on slightly different starting points, and the scores drifted in weird ways for no obvious reason. The fix was dull and important: lock everything to the exact same starting model.

A naming clash ate one of my runs. Two experiments grabbed the same name and one overwrote the other halfway through. I recovered from saved checkpoints and started giving every run its own unmistakable name. Lesson learned the annoying way.

The fancy-algorithm showdown that… didn’t matter much

There are two popular ways to run that “practice with a scorekeeper” loop: one’s called PPO, the other GRPO. People argue about them a lot. So I ran both from the exact same starting point, same judge, same everything, the cleanest comparison I could set up.

~67%

of people preferred my trained model over the base

38k

real "you changed my mind" examples

~71%

how often the judge model picked the true winner

The result? GRPO got there faster. PPO was a bit smoother. In a blind test where real people picked the better reply, both beat the original model about 66 to 67% of the time, and against each other it was basically a coin flip. The big, much-debated algorithm choice was the least important decision in the whole project.

The takeaway

The judge model is the whole ballgame. Spend your time on the examples you feed it, not on the fancy training algorithm.

A great judge with a basic training loop beats a weak judge with the most exotic algorithm you can find, every time. GRPO is faster. It will not save you from a judge that secretly rewards rambling.

And the part I’m actually proud of isn’t the 67%. It’s that I saw the “longer = better” trap coming before it wasted a week of computing, because I stopped to think about how the judge could cheat. That’s the kind of engineer I want to be: the one who plans around the obvious mistake before it happens, not the one who explains it afterward.

This was research with Prof. Marco Morucci’s group at NYU.

How I built the boring parts of an ML system on purpose

Thu, 01 May 2025 00:00:00 GMT

The hardest part of ML in production is not the model. The hardest part is everything that happens after: how you know when to retrain, who approved the version running right now, what data it was trained on, and how fast you can swap it out when something goes wrong. Most projects skip those questions. They show up as the post-incident follow-up six months later.

Loan Radar was a grad-school project built with that gap in mind. The domain is loan-default scoring, where the modeling problem is well-understood. I picked it precisely because it let me put all my time into the operational layer: lineage, gates, automated retraining, rollback paths. The stuff teams usually defer until the first fire.

The whole system in one diagram

Container: train.py --config configs/baseline.yaml
        │
        ▼
MLflow run = code commit + data hash + hyperparams + metrics + weights
        │
        ▼ candidate
┌────────────────────────────────────────────────┐
│  6 quality gates                               │
│  ── min AUC                                    │
│  ── calibration vs reference                   │
│  ── subgroup fairness                          │
│  ── inference latency p95 ≤ 50ms               │
│  ── output-distribution KL on canary           │
│  ── serialised size cap                        │
└────────────────────────────────────────────────┘
        │  all green
        ▼
Staging → Slack ack → Production (canary rollout)

Weekly Airflow DAG re-runs the whole loop against fresh data.

The six gates are the project

Every model run goes through the same six checks before it can be promoted. Any failure short-circuits the build:

gate_01_min_auc            held-out AUC ≥ floor
gate_02_calibration        Brier score within tolerance
gate_03_subgroup_fairness  no subgroup with TPR delta > threshold
gate_04_inference_latency  containerised p95 ≤ 50ms on the harness
gate_05_drift_canary       output-distribution KL within bounds
gate_06_size               serialised model under size cap

Reason they’re scripts in git instead of checkboxes in a dashboard: it makes “did the model pass our quality bar” a deterministic, auditable thing instead of an opinion.

Honest latency numbers, not vibes

A benchmark harness runs against the production model on a single 2-CPU container. Results: 0.79ms median latency for a single caller, 0.87ms at p95, sustained throughput around 33,000 samples/second before p99 climbs.

0.79 ms

median single-caller latency

~33k req/s

throughput before p99 climbs

6 gates

before any model can be promoted

Numbers exist because the harness exists. Plenty of teams quote “tens of thousands of QPS” off back-of-envelope math. Running the load test is the difference.

Retraining is half automated, half human

The Airflow DAG runs weekly:

Pull the latest data manifest.
Skip if manifest diff is below threshold.
Train the container against the new manifest.
Run the six gates.
If green, promote to staging + Slack ack required.
After human ack, canary roll to production.

The Slack ack is deliberate. Fully automated rollouts on a financial model only make sense when rollback is trivially safe. A five-minute human pause is cheap compared to an automatic rollout that violates a calibration assumption nobody’d thought to gate on.

What this taught me

The boring parts are the parts. A 99% accurate model with no lineage and no gates is operationally worse than a 92% accurate model with both.

The Hybridge work I did later carries the same DNA. The CBCT validator has a gate before any promotion. The consultation QA pipeline has schema-validated outputs and a single-retry contract. Both use a hot-swap deploy shape so retrains don’t need a rebuild. Both share a single ETL module across train and serve.

Those patterns came out of Loan Radar.

The kind of engineer I want to be is the one who asks “how do we roll this back” before asking “what accuracy did we hit.” Demos age out; gates are what survive contact with reality. Loan Radar was the project that taught me to build in that order.

Live demo: Loan Radar.

How I rebuilt a brittle call grader into a coaching platform

Sun, 21 Jun 2026 00:00:00 GMT

The job of a New Patient Coordinator is the first phone call. Someone is nervous, maybe in pain, and the way that call goes decides whether they ever walk in. The practice founder, Dr. Frank LaMar, wrote a careful playbook for those calls. The question was how to coach forty people against it without a manager listening to hundreds of recordings a week.

We did not start from zero. An earlier grader, built in a no-code tool called n8n, already pulled the call recordings off a server every hour and produced a report. It proved the idea was worth something. And then it hit a ceiling I could not raise without rebuilding the thing underneath it.

So I rebuilt it. This is the whole story: what was wrong, how it grades a call now, the architecture decisions I would make again, the bugs my tests never caught, and the dashboard a manager actually lives in.

What the prototype did, and where it stopped

The old version graded each call as a flat sum out of 60, wrote the result as a blob of text into a single Google Doc, and emailed a link. That Doc was the only record.

That design quietly broke in a lot of places at once.

What the prototype could not do. No database, so no trends, no per-coordinator averages, and no way to answer the question a manager actually asks: how is this person doing this month? The score had no quotes behind it, so nobody could see why a call got a 47. It kept no record of which non-negotiables passed or failed. It shared the patient's name and the full transcript to the entire company. And if the workflow died halfway through, the call was skipped in silence.

I kept the same playbook and the same model family, and rebuilt everything around three things the prototype never had: evidence behind every score, patient safety as a first-class signal, and a real system of record you can query.

	The prototype	What runs now
Score	Flat sum out of 60	Weighted 40/40/20 out of 100, plus 3 hard gates and a patient-urgency override
Evidence	A number with nothing behind it	A verbatim transcript quote behind every one of six criteria
Output	Text parsed by position	Validated structured data, scored by code, not the model
Record	One Google Doc per call	A queryable BigQuery store feeding a 26-endpoint dashboard
Privacy	Full transcript and name shared company-wide	A dashboard locked to the practice domain behind sign-in
Reliability	A mid-run failure dropped the call silently	Deterministic call IDs, so a call is never graded twice or lost

The one rule the whole thing is built on

The principle under all of it comes straight from the playbook: the coordinator is the patient’s first advocate, not a clinician and not a salesperson. The system grades judgment and patient safety. It never grades booking rate.

That sounds soft. It is actually the hardest constraint in the build. A call where the patient politely defers is not a failure. A patient who books an appointment just to get off the phone is a failure of advocacy, not a win. Correctness beats conversion, every time, and I had to write the grader so it can never quietly reward the reverse.

What runs now, end to end

A call happens. The phone system drops the recording on a server, or our other source hands an inbound call back with a transcript already attached. From there the pipeline does six things.

The pipeline.

Ingest the day's recordings, or accept the live webhook. Each call gets a deterministic ID so it can never become two records.
Transcribe. Outbound recordings go through Vertex Gemini. Inbound calls reuse the transcript that already exists, which keeps that cost near zero.
Classify what the call actually is. A new-patient conversation goes forward. A voicemail, a wrong number, or an existing patient gets tagged and set aside.
Score the relevant calls against the playbook, criterion by criterion, with a quote behind every judgment.
Resolve identity so every call to and from the same person links to one stable patient ID.
Report and store. The verdict lands in BigQuery, the transcript and report in Cloud Storage, and the dashboard renders both.

How it grades a call

People ask about the score first, so here is the real math. Every relevant call is graded on six criteria, each from 0 to 10.

The six criteria. C1, role identification and advocacy. C2, patient identification and referral framing. C3, rapport and emotional connection. C4, classification before conversion (pin down the scope before pushing an appointment). C5, sequencing and scheduling logic (the right appointment, not the fastest one). C6, use of differentiators, only when a patient concern actually calls for one. Most calls do not, and the absence is never penalized.

Those six roll into three weighted buckets. The headline is a plain weighted sum, nothing fancier.

final_score = 10 × ( 0.40 × mean(C1, C3)    # rapport
                   + 0.40 × mean(C2, C4)    # classification
                   + 0.20 × mean(C5, C6) )  # scheduling

That maps to four bands: Gold at 85 and up, Strong at 70 to 84, Developing at 50 to 69, Fail below 50. On top of the number sit two safety layers that have nothing to do with how nice the call was: three hard gates (did the coordinator identify their role, capture the patient’s name, and frame the referral correctly) and a patient-urgency override (if someone is in real pain and the coordinator delays intake or pivots to financing, that is recorded as a safety failure).

The decision I reversed

The first version of the rubric capped any gate-failing call at 49 and subtracted points for a safety miss. It looked principled. Miss a non-negotiable, crater the score.

In practice that cap destroyed information. A genuinely warm, well-sequenced call that happened to use one bit of retail framing would collapse to 49, which told a coach nothing about everything else the coordinator did well. So I removed the cap entirely. The score became the pure weighted sum, and the gate failure became a loud red badge next to it.

a flag, not a cap

A call can now read 84 and still be flagged as failed. The coach sees both at once: how good the call was, and which non-negotiable was missed. The number and the safety flag stopped fighting each other.

Why I took the math away from the model

This is the part I would defend hardest. The model produces only three things: the six integer scores, the gate booleans, and the urgency state. A pure Python function turns those into the final number.

Keeping the arithmetic out of the model means the headline score is reproducible. Same inputs, same number, every time. And if the practice decides scheduling should count for 30% instead of 20%, that is a one-line change to a function, not a prompt rewrite and a re-check of every past call. The model does the part it is good at, reading a conversation and judging it with a quote to back it up, and none of the part it is bad at, consistent arithmetic.

The architecture I would do again

A few design choices shaped everything else. None of them are clever. They are boring on purpose, which is exactly why they held up when real patient data started flowing.

Ports and adapters, so the cloud is swappable. Every external dependency (storage, the transcriber, the scorer, the classifier, the patient registry, delivery) sits behind a port. The real Google Cloud services are wired in at a single place. In tests, the same ports get in-memory fakes.

safe by default

One flag, NPC_BAA_ACCEPTED, gates every path that touches real patient data. When it is off, the app wires in fakes and touches nothing real. That is the safe default for demos and local work, and it is why 1,156 tests run with no network and no cloud credentials.

That one flag came out of a compliance fact that bites a lot of healthcare projects: a Google Workspace agreement does not cover Google Cloud services. Cloud Storage, Vertex AI, and BigQuery need a separate Cloud agreement, and nothing real is allowed to flow until that is signed. I made that a single line of config instead of a rule someone has to remember.

Cost discipline through structural dedup. Inbound calls already arrive with a transcript, so we never pay to transcribe them twice. At the practice’s volume, that is the single biggest reason the cloud bill lands around 50 to 250 dollars a month instead of several times that. The cheapest API call is the one you never have to make.

Ship the smaller correct thing first. The full design is an event-driven mesh with queues between every stage. For the first real run I deliberately did not build all of that. I wired a direct, single-process pipeline so the dashboard could light up on real calls while the heavier plumbing waited its turn. That choice paid off twice: real calls got scored early, and the whole delivery layer the coordinators actually feel (emailed reports, inline recordings, a daily summary) landed on that simple pipeline instead of blocking on the full mesh.

Four bugs my test suite could not catch

The polished version of a project hides exactly the parts worth writing down. Every one of these passed a green test suite and still went wrong against reality.

The wheel that passed a thousand tests and still failed to deploy. The first deploy failed at build time even with the whole suite green. A packaging setting tried to add the same asset files to the image twice. The tests never saw it because they use an editable install that never builds a real package. The Docker image does a real install, so it tripped on the first deploy. A green suite proves the code runs, not that it packages.

Forty percent of real calls came back "not gradeable." The output schema required an exact transcript quote for any non-zero score, and on a garbled transcript the model could not always find an exact substring, so a perfectly reasonable score got rejected on a technicality. I loosened the quote requirement from mandatory to advisory, made the remaining failures report why instead of failing silently, and added a relevance gate so calls that should never have reached the scorer get filtered earlier.

Reruns that forked a call's history. A rerun could create a fresh record instead of updating the original, splitting one call across two IDs. I scoped the claim to the original call ID, so a rerun reattaches to the same call rather than minting a new one. One call, one record, no matter how many times it is reprocessed.

A transcriber that misheard the practice name a dozen ways. It rendered "Hybridge" as "High Bridge," "Amadana," "Hyperjet Omaha," and more. There is no Omaha office. Re-transcribing costs money, so I edit the stored text in place for known mishearings, and feed the real practice names into the transcription prompt going forward so the model has the right vocabulary up front.

diagnosable beats silent

A call that fails grading and tells you why is a to-do item. A call that fails silently is a hole in your data you find weeks later, if ever.

The dashboard a manager actually opens

The pipeline grades the calls. The dashboard is the surface a coordinator and a manager live in. It is a single-page React app behind Google sign-in, backed by 26 endpoints, with one mantra pinned in the sidebar the whole time: correctness over conversion, no patient data in logs.

The heart of it is the call detail view. It opens with a live pipeline stepper (Ingest, Transcribe, Tag, Score, Report) that refreshes while a call is still moving. Then the coaching report itself.

What a coach sees on one call. A red banner if a hard gate failed, naming which one, and stating plainly that the score is still calculated normally because the gate is a flag, not a cap. A score-breakdown panel showing the three buckets as bars, then the weighted sum and final number, so the math is on the screen instead of hidden in the model. Each of the six criteria with its score, the model's reasoning, the exact transcript quote it cited, and a one-line coaching note. The recording plays inline, right next to the report.

every judgment, a quote

A coach does not just see the number. They see the exact moment in the transcript that earned it, so the coaching is grounded in something the coordinator already remembers.

The surprise feature is Settings. The scoring rubric is not buried in the source. It is editable in the browser, and it is the same rubric the scorer runs. A manager can tune the playbook, save a new immutable version with a change note, and roll back without losing history, all without opening a code editor or pinging me.

And a lot of the best features were never in the spec. They came from looking at real output: a voicemail tag that pulls voicemails off the grader, an uncooperative-caller flag so an unfair call does not drag down an average, the relevance gate that came out of the “not gradeable” hunt, and a daily 5pm summary where Gemini rolls the day’s calls into one digest for the manager.

Where it landed

On one real day, the system ingested about 285 recordings, found and scored 40 real new-patient calls with quoted evidence, auto-filtered 3 voicemails, and flagged 28 calls for missing a non-negotiable.

Metric	Value
Calendar time, first to latest commit	18 days
Python source	~20,800 lines across 20 modules
Tests	1,156, all on synthetic data, no cloud
API endpoints	26
Scoring	6 criteria, 3 hard gates, 40/40/20 weighting, 4 bands
Target volume and cost	1,000 to 5,000 calls a month, about 50 to 250 dollars

The prototype told you a call scored 47 out of 60. This tells you the call scored 84, names the exact moment the coordinator missed a gate, quotes what they said, and puts that next to their own 90-day average. That is the difference between a number and a coaching tool.

If there is one lesson under all of it: a green test suite is necessary, not sufficient. It proved the logic ran. It did not catch the packaging break, and it did not tell me 40% of real calls would not grade. The real calls did. Ship the smaller correct thing, watch what real data does to it, and let that drive the next feature, not the original plan.

How I caught my pipeline lying to me (and made it confess)

Fri, 29 May 2026 00:00:00 GMT

A while back I wrote about the pipeline that grades every implant consult against our CEO’s seven-criterion rubric. Zoom drops a transcript, Gemini scores it, an email goes to the doctor + treatment coordinator + CEO, and a row appends to a master Sheet. Beautiful on paper.

In practice it was a polite liar. Runs would proudly show ✅ complete while the email never went out, the Sheet never got the row, and half my coordinators’ meetings just… weren’t there. I’d been manually rerunning consults for two weeks and didn’t know why, while the CEO was actively testing in prod. Cool cool cool.

The task: stop the lying. Every failure visible, every transient error retry-able, every state in sync, and the logs readable by humans who don’t write Python.

Nine flavors of silent failure, stacked like a sad lasagna

The missing-host mystery. Two coordinators were migrated to @hybridgeimplants.com mailboxes; the allowlist only knew their old @elmwooddental.com ones. Every meeting they hosted just quietly return-ed. Now multi-email TCs live in host_mapping.yaml, a YAML edit, no Secret Manager dance.
The rerun ghost button. RerunBody.send_email: bool = False. Click Rerun, get a green checkmark, no email lands. Flipped the default.
The bare-except graveyard. Gmail, Sheets, and OAuth blips all swallowed while the run marched on to mark itself “complete.” Each one now surfaces as amber needs attention with a plain-English line.
The yellow that wasn’t there. One tab painted running yellow, another painted failed yellow. Same run, two meanings. I unified the legend: 🟢 done · 🟠 needs attention · 🔴 failed · 🔵 running.
The retry that wasn’t. A single 429 or broken pipe was a silent kill. Added exponential backoff with jitter for transient errors (more below).
The rerun-creates-duplicates problem. A successful rerun left two rows for one consultation. Built rerun-replaces-old: successful reruns delete the original and dedupe the Sheet; failed reruns leave the known-good baseline alone.
The disappearing runs. Events that died at the host gate or download step, before scoring, left zero trace. Moved dashboard row creation to the very top of the webhook handler, so every event leaves a clickable row even if it died at step zero.
The “logs are in Cloud Logging” wall and 9. the orphan-state drift, both below.

Make the failures retry themselves

The connection-level errors were the sneaky ones. HttpError covers the 429/5xx case Google’s client knows how to raise, but a BrokenPipeError or ConnectionResetError comes up from the socket layer and never wears an HttpError jacket, so a decorator that only caught HttpError waved them straight through to a silent kill. The fix: retry on all three families, with jittered backoff so a herd of reruns doesn’t synchronize into the next rate-limit wall.

RETRYABLE = (HttpError, RefreshError, BrokenPipeError,
             ConnectionResetError, TimeoutError)

for attempt in range(MAX_RETRIES):
    try:
        return fn()
    except RETRYABLE as e:
        if attempt == MAX_RETRIES - 1:
            raise            # loud: surfaces as amber, never swallowed
        sleep(BASE * 2**attempt + jitter())

A transient blip is no longer a death sentence, and a permanent failure still raises loudly instead of being marked complete.

Logs humans can read, state that can’t lie

The biggest cultural fix was killing “the logs are in Cloud Logging” as an answer. Every run detail page now has a Logs tab with two views: an Easy view, the nine stages as a stepper (✅ ⚠️ ❌ ⏭ 🔄 ⏸), each non-passed stage carrying a plain-English line plus what to do, and a Developer view with BigQuery audit events, tracebacks, and the raw Firestore doc. A non-technical operator can finally tell what failed without learning what a RefreshError is.

Behind it runs a consistency reconciler after every status change: if the doc says “Sheet appended” but the row isn’t there → flip to amber; if the row is there but the flag says no → flip to green. The dashboard mirrors reality instead of trusting a flag set optimistically before the work finished.

0 drift

Doc state and real-world state reconcile after every status change, so the flag can't lie about what actually happened

A sprinkle of one-off cleanup scripts repaired the existing damage: resent 13 silently-failed emails (no duplicates), backfilled 4 missing Sheet rows, deduped one stray row, and reconciled one stubborn consultation that had lost its scorecard to a broken pipe.

Where it landed

51 / 0 / 0

green / amber / red, with 0 drift and 0 duplicates in the audit

234

tests green, +50 of them covering the exact silent-fail paths

7 → 1

production deploys shipped in a single push

The best part: the next time something breaks (and something always breaks) I’ll know in five seconds, because the dashboard isn’t allowed to lie to me anymore.

The lesson, free of charge: bare except is technical debt accruing interest. Every silent failure I caught had been swallowed by one. Make your code loud when things go wrong. Your future self will thank you, and your CEO will stop emailing at 11pm asking “why didn’t I get the report?”

Reconciling a dental day without opening the spreadsheets

Sat, 20 Jun 2026 00:00:00 GMT

Every day, each location in the group sees roughly 40 patients. For the books to be right and the chart to be defensible, every one of those encounters has to line up across three separate documents: the schedule (who was supposed to be seen), the production ledger (what got charged), and the clinical notes (what got documented). When the three agree, there is nothing to do. The whole job is the disagreements.

Two front-office staff were finding those disagreements by hand, eyeballing three spreadsheets side by side. It took each of them about three hours a day, every day, forever. And because it was manual, it failed exactly where mistakes are most expensive: a patient treated and documented but never billed (lost revenue), or billed with no clinical note behind it (a compliance liability).

I built Reconciliation to do the cross-check automatically and hand the staff only the handful of flagged patients instead of the whole schedule. It is shipped and live (v1.6.0) on Cloud Run, it reads two completely different practice-management systems through one engine, and no patient data has ever touched the repository.

Two systems, same underlying reality

The first complication is that the two practices run different software, and the exports look nothing alike on disk.

The general practice runs Eaglesoft: legacy exports, binary .xls then CSV, Windows cp1252 encoding, and duplicate column headers (three different start_time columns in one file). The implant centers run Denticon: .xlsx with title and footer junk rows, merged cells, a header that is not on the first row, and a column name literally spelled OIffice Name. Same problem, two hostile file shapes.

The second complication is HIPAA. Every one of those files is full of protected health information, so anything I built had to treat patient data as radioactive: never logged carelessly, never committed, never sent anywhere it should not go.

A deterministic engine, then everything else wraps it

The single most important decision was to split the system into a pure reconciliation engine and a thin application shell around it.

engine/   pure Python. No network, no database, no clock, no UI.
          Three files in, one structured auditable result out.

app/      FastAPI. Auth, upload, dashboard, history, email, and the
          in-progress AI clinical matcher. All of it wraps engine.reconcile(...).

The engine is the part that has to be correct, so I kept it free of side effects. No I/O, no randomness, no reading the wall clock. It even takes the “generated at” timestamp as a parameter instead of calling now(), so identical inputs produce byte-identical output. That is what makes the result auditable: same three files, same answer, every count traceable back to specific source rows. The messy real-world concerns (sessions, OAuth, uploads, email) all live in the shell, where they can be messy without threatening correctness.

Parsing: map columns by name, and fail loud

The parsers follow two rules. Map columns by name rather than position, because positions drift between exports and names are more stable, and when a name is duplicated, pick the right occurrence deterministically. And give each system its own adapter that validates the columns it needs and emits clean typed records. A missing required column is a loud, specific error, never a silently wrong answer. In a tool people use to sign off on money and compliance, “wrong but confident” is the worst possible failure.

Both adapters emit the same typed models, so once parsed, Eaglesoft and Denticon records are indistinguishable to the rest of the system. A small SOURCES registry dispatches to the right adapter based on a source argument, which means adding a third practice-management system later is one new adapter, not a rewrite of the matching logic.

Matching: patient_id is the spine

To compare three files you need a reliable join key. The schedule and ledger both carry a clean patient_id. The Eaglesoft notes file has no ID column at all. What it does have is a sort_name like ROTHFUSS, JAMES E15612, with the patient ID hiding as trailing digits on the name string, so the matcher recovers the key from there. I confirmed that was 100% extractable across a real notes export before relying on it.

Keying on the ID rather than the name means two patients with the same name never collide. Names are only a fallback: when an ID cannot be lined up, the system attempts a normalized last-first match and tags the patient as low-confidence, needs human review. It never silently guesses. “I am not sure, look at this one” is always a safe answer.

Classification: a small set of honest buckets

For each scheduled patient, the engine computes two facts: has_money (at least one real production charge, explicitly excluding credits, adjustments, and courtesy codes) and has_note (at least one non-deleted clinical note). Those two booleans produce the verdict.

Bucket	Condition	What it means
verified	money and note	Done and documented, no review needed
note_no_money	note, no production	Documented but nothing posted (lost revenue)
money_no_note	production, no note	Posted but undocumented (compliance risk)
neither	no money, no note	No-show or missed
review_non_scheduled	production for someone not on the schedule	Walk-in or mis-post
review_low_confidence	matched only by fuzzy name	Needs a human to confirm

The green verified bucket is the whole point. On a representative day of about 41 scheduled patients, roughly 30 land there automatically and disappear from the staff’s workload, leaving about a dozen exceptions to actually look at. Every record carries the evidence that placed it in its bucket (the specific ledger and note rows), a plain-English reason, and the input files’ SHA-256 hashes and row counts for audit.

fail loud, never guess

A missing column errors out. An uncertain match gets flagged for a human. In a financial and clinical tool, a confident wrong answer is far worse than an honest "look at this one."

HIPAA-safe testing, with no compromise

This is the constraint that shaped the whole test strategy, and I am happy with where it landed. No real patient data lives in the repo: .gitignore blocks every .xls, .xlsx, .csv, and .pdf, and real exports stay on local machines only. The 150+ tests run against synthetic fixtures generated at runtime that reproduce every real-world quirk (duplicate headers, the trailing-ID sort_name, deleted notes, credits, multi-appointment patients, non-scheduled production, fuzzy-name-only patients) without a single byte of PHI, so CI runs entirely clean. A golden test does run against a real day’s files, but it is opt-in, gated behind a REAL_DATA_DIR variable, and skipped automatically when that is absent. The acceptance numbers from that real day became the literal definition of done.

The shell: auth, dashboard, history, email

Around the engine sits a FastAPI app on Cloud Run, with Firestore holding users, recipients, saved reports, and config. Google sign-in is restricted to the practices’ own domains plus an admin-managed allowlist, with two roles and self-serve user management so nobody files a ticket to add a colleague. The dashboard has a source tab, then upload three files, reconcile, and read color-coded summary cards; click any card and a popup shows every patient’s schedule, ledger, and note rows down to tooth, surface, provider, dollar amount, full note text, and the original spreadsheet row numbers. Every run is saved and searchable, with a reversible mark-as-fixed so a staff member can tick off a flagged patient once they have resolved it. Email needs no IT involvement: an admin clicks Connect Gmail once, and the app sends reports as that user through a stored refresh token.

The next frontier, built but not switched on

The current verdict is structural: production exists and a note exists, so the patient is verified. The real prize is clinical matching, confirming that the specific procedures billed are the specific procedures documented, tooth by tooth. I have built that layer on Gemini through Vertex AI, matching ledger procedures against note text by tooth, surface, description, and procedure code with a curated clinical-terminology dictionary (a “Cement Crown” charge maps to a “Delivered Crown” note, surface-letter counts have to match the procedure code, X-ray and tray codes are normalized, billing and admin lines are ignored).

It is deliberately not wired into the live verdict yet. Clinical matching is high stakes, and the two practices document differently (per-procedure at the general practice, long consult narratives at the implant centers). Turning it on is gated on finalizing the terminology lists with each practice’s billing lead, so the engine asks instead of guesses. The plan is a preview mode that shows the AI’s read alongside the official structural verdict before it is ever allowed to change a count.

Where it landed

Shipped and live at v1.6.0, in daily use. About six person-hours of manual cross-checking became a few minutes of exception review. Lost-revenue and compliance gaps are caught structurally every day instead of depending on a tired human noticing a discrepancy across three windows. Two practice-management systems flow through one engine and one dashboard. The output is deterministic and auditable, the repository has never held a byte of PHI, and the AI clinical matcher is ready and waiting behind a conservative rollout rather than rushed into a place where it could quietly change the books.

How I built a recommender for 22 million records

Sat, 18 May 2024 00:00:00 GMT

Most recommendation tutorials hand you a tiny dataset and one neat algorithm, and everything fits in your laptop’s memory. That teaches you the math and none of the real problem.

The real problem shows up the moment you have 22 million records. Now you can’t just compare every person to every product, that’s trillions of comparisons, and your computer quietly bursts into flames. The question stops being “which fancy algorithm?” and becomes “how do I avoid doing work I don’t need to do?”

That question has a well-known answer, and building it was the whole point of this project.

Why you can’t do it in one shot

If you try to score every user against every item, the numbers explode instantly. So real recommenders split the job into two steps, like a hiring funnel:

22 million records
        │
        ▼  Step 1: Shortlist (fast and rough)
  Group similar things together,
  only compare within a group
        │  a few hundred candidates per person, not millions
        ▼  Step 2: Rank (slow and smart)
  Score just that shortlist properly
        │
        ▼
  Top picks for each person

Step 1 is the bouncer. Its only job is to throw out the obviously-irrelevant stuff fast. I used a trick that groups similar users and items into the same “buckets,” so each person only ever gets compared to a few hundred likely matches instead of millions. It’s a little sloppy on purpose, speed matters more than perfection here.

Step 2 is the judge. Now that the list is short, I could afford the smarter, slower math (the part that actually learns personal taste) and run it only on the few hundred survivors. Cheap, because the bouncer already did the heavy filtering.

Spreading the work across many computers

Even the shortlist step is too big for one machine at 22 million records. So the whole thing ran on Spark, which is basically a way to split a giant job across a cluster of computers and have them all chip away at once.

Getting that split right, who does what, when the machines have to talk to each other, is honestly most of the real engineering. The algorithm is the easy part to write. Making it run across a cluster without choking is the hard part.

22M+

records, split across many machines at once

+20%

better than just recommending what's trending

100s

items ranked per person, not millions

The number I’m proud of is +20% better than just showing what’s popular. Beating random guessing is easy. Beating “just recommend whatever’s trending” is the honest bar, because that’s the lazy option that’s secretly pretty good. Clearing it by 20% means the personalization actually earned its keep.

What broke (and what it taught me)

A few mega-popular items jammed everything. When you split work across machines, a handful of super-popular items can dump a giant pile on one poor machine while the others sit idle, and the whole job crawls. The fix is to spread those hot items out deliberately. Nobody warns you about this in the tutorials, because tutorials never have a mega-popular item.

The “shortlist” step is a dial, not a setting. Make the buckets too tight and good matches fall out; too loose and the bouncer stops saving you any work. I had to tune it on purpose, treating it like the trade-off it is.

New users broke the smart step. The ranking math has nothing to say about someone with zero history. So for brand-new users, I just fell back to “show them what’s popular”, which is also why having that popularity baseline built in from day one paid off twice.

The takeaway

The lesson here isn’t about the dataset. It’s that the two-step shape, shortlist fast, then rank smart, is exactly how the big recommendation teams (think the “you might also like” on any huge site) keep things running. I built the small version of the real thing.

When the data is huge, the model is only half the system. The other half is refusing to compute things you don’t actually need.

That stuck with me. Faced with 22 million rows, the instinct shouldn’t be “find a fancier algorithm.” It should be “what work can I avoid?” That’s the move that keeps a system standing when the data grows another ten times bigger.

Full project: Customer Segmentation and Recommendation System.

How we went from 42nd to 1st in a class AI contest

Sun, 08 Dec 2024 00:00:00 GMT

In our deep learning class, the professor turned the final into a competition. 55 teams. Two weeks. One job: build the best image classifier for CIFAR-10. Two rules. Keep it a ResNet, and keep it under 5 million parameters. Inside those lines you could do anything, any ResNet variant, any trick you’d read about. The bar to clear was 85% accuracy.

We cleared it. And then the leaderboard came out and we were sitting at 42nd.

That did not sit right with me.

Two weeks, one stubborn ceiling

So I put my head down. I tried different ResNet architectures. I swept hyperparameters, learning rates, schedules, weight decay, batch sizes, until I found a combination that genuinely worked. Our accuracy climbed to about 92%.

I shared the winning hyperparameters with my team. That jumped us to 16th in the class.

Better. Not good enough. Because I could see where this was going: the teams ahead of us were hitting 94 to 94.5%, and no amount of extra tuning was closing that gap. Under a 5-million-parameter cap, the model can only get so smart. The rules said I couldn’t buy more accuracy with more parameters, and I’d already squeezed hyperparameters dry. I’d hit a wall.

42nd → 16th

after architecture + hyperparameter tuning (~92%)

94 to 94.5%

what the teams ahead of us were hitting

5M params

the cap that made "just tune harder" a dead end

(If you want the receipts, every run and result is in our results sheet.)

So I asked a different question

If the model is already as good as the rules let it be, and the hyperparameters are dialed in, what’s actually left to improve?

Not the model. The data.

More data makes almost any model better. But there was a catch: we had to stick to CIFAR-10. We couldn’t go grab more images. So how do you get more data out of a fixed dataset?

Augmentation.

It’s a simple idea. Take each training image and make new versions of it on the fly: rotate it a little, flip it, crop out a piece, nudge the colors. The label doesn’t change, a cat rotated ten degrees is still a cat, but the model now sees far more variety. You get a flood of new training examples without collecting a single new image, and without adding a single parameter to the model.

Which was the whole point. The cap was on parameters, not on data.

The game changer

This is where it turned. Feeding my already-good models all that augmented data, accuracy just shot up. We landed at 97.12%.

That put us 2nd in the entire class, a heartbreaking 0.17% behind the team in 1st.

97.12%

final CIFAR-10 accuracy, 2nd of 55 teams, 0.17% off the top spot

We were thrilled. And then came the cherry on top.

The secret test set

The professor had held something back: a set of images none of us had ever seen while building. After submissions closed, he ran every team’s model against it.

Every model did worse on the secret set than on CIFAR-10’s own test data. That was the tell, most teams had quietly memorized the CIFAR-10 test images. Their models knew the test, not the world.

Ours dropped the least. By a lot. Because we’d trained on all those rotated, cropped, flipped versions, our model had learned the actual shapes of things instead of the exact pixels of the test set. On data it had never seen before, it came first in the whole class.

We did not see that coming. We partied that night. Genuinely did not know we had it in us.

Why I keep telling this one

Here’s the part I love. Going in, we thought we were average. Other teams were pulling out heavy machinery, teacher-student setups, exotic architectures, things we’d only half-heard of. We assumed someone like that would run away with it.

Instead we:

kept the problem simple and refused to over-engineer it,
read everything, papers and open-source repos, to see how the best people in the world were attacking CIFAR-10,
learned from them, used a little common sense, and just put our heads down for two weeks.

That’s it. No magic. The team that thought it was average finished 2nd on the test set and 1st on the data that actually mattered, the stuff the model had never seen. The professor handed us a bonus grade point for the effort.

The teams ahead of us had fancier models. We had more data and a model that generalized. On unseen data, generalization wins.

The lesson stuck: when the obvious lever (a bigger model) is off the table, don’t push harder on it, step back and find the lever nobody’s pulling. Ours was data. It cost zero parameters and won the only test that didn’t tell us the answers ahead of time.

Full results: our CIFAR-10 competition sheet.

How I rebuilt a 10-year-old pricing tool in a month

Mon, 18 May 2026 00:00:00 GMT

Hybridge’s treatment coordinators were closing full-arch implant cases worth $24,000 or more while mentally adjusting numbers the software got wrong. The quoting tool was ten years old. It worked, roughly, but three problems had been quietly absorbing coordinator effort the whole time.

One price for every clinic. Rochester, Buffalo, and the planned Syracuse location all shared a single set of numbers. Want to charge differently? Fork the script.

No tiers. Chelsea, our senior treatment coordinator, has been quoting full-arch implant cases for a decade with a structure like “first implant $2,800, second $2,300, third+ $1,800.” That structure lived in her head, not in the tool. Coordinators were hand-editing the printed estimate.

No price freeze. Write a $24,300 quote today. Raise prices next month. Patient comes back to accept. The legacy tool happily reads the new price book. The “6-month guarantee” at the bottom of the PDF was a promise the software couldn’t keep.

A vendor spent a decade trying to fix this. They never shipped. I shipped in a month.

The decoupling that made it all work

Before any code, I wrote an ADR with one decision the rest of the system falls out of:

Code-driven decision tree. DB-driven price catalog. Prices snapshotted onto each estimate at capture time.

The flow of an estimator session lives in TypeScript. The prices live in Postgres. They meet at one function. The result is written to disk in a form no later price update can touch.

Five pricing models, one resolver

flat            One price. Night guard, sedation, CT scan.
tiered          Nth time you add this procedure, you pay tier-n's price.
                First implant cheaper than the second? Wait, no, more expensive.
tiered_zoned    Same idea, but tiers are per zone. Premium #7-10 crowns
                have their own ladder.
price_range     Catalog gives min/max. TC picks within the range.
per_surface     Surface count picks the tier. Fillings.

Exactly one function in the codebase decides what tier any line item is. Add a new pricing model and forget to update the resolver: the TypeScript compiler refuses to build. Compile-time guarantees on money.

The 6-month guarantee, as a database constraint

Every line item snapshots four things at write time: the price, the tier number, the procedure label, and the price book version ID active at that moment.

A Postgres trigger refuses any change to those columns:

CREATE TRIGGER trg_freeze_capture
BEFORE UPDATE ON estimate_line_item
FOR EACH ROW EXECUTE FUNCTION freeze_capture();

If application code tries to recompute a price into an existing line, Postgres throws. The 6-month guarantee is no longer a sticker on the PDF. It’s a database invariant.

1 month

From ADR to working end-to-end, versus a vendor attempt that never shipped in ten years

Per-clinic, with a lifecycle

Each clinic has its own price book version chain with a status: draft → proposed → approved → published. You edit a draft, propose it, get approval from an org admin, then publish with an effective-from timestamp. Past versions stay readable forever.

Rochester at version 12 and Buffalo at version 8 coexist. No fork. No shared global table.

The wizard, the only piece of UI worth lingering on

The legacy tool’s real problem was that coordinators got lost mid-consult. Ten steps, no orientation. Patient is in the chair, watching the screen.

The redesign stacks three things that tell the TC where they are:

Top progress strip: phase chips: ✓ done, ▶ here, ⌧ locked, skipped.
Left rail checklist: shows their answer in parentheses: Extractions (#4, 6, 8) ✓. Click to jump back.
Right rail “Selections so far”: sticky, color-coded blue (upper) / green (lower), with running subtotals.

By the numbers

1 → 5

pricing model kinds, one resolver

$35/mo

target cost at S1 volume on Cloud Run

100%

branch coverage on the pricing engine

	Legacy	New
Pricing models supported	1 (flat)	5
Per-clinic pricing	Hardcoded everywhere	First-class object with a lifecycle
6-month price guarantee	PDF sticker	Postgres trigger
Wizard orientation	”Which step am I on?”	Three stacked affordances
Cost target	n/a	$35/month at S1 volume on Cloud Run
Time to working end-to-end	The vendor 10 years ago: never shipped	About one month

Drizzle and Postgres and Next.js are everywhere these days. The tools were not the hard part. The hard part was sitting with Chelsea until her mental pricing model was precise enough to write a schema for, writing nine ADR decisions before touching code, and knowing that a service-level check on price changes would always be one missed call away from a broken promise. A Postgres trigger cannot be skipped. A business guarantee probably can.

That gap, between what an org says it does and what the system actually enforces, is where this kind of work lives. Draw the line in schema and code, and the next engineer extending it cannot blur it by accident.