I build AI systems, and I check whether the numbers behind them are real.

Eleven years in enterprise software. I build assistants that answer questions from a company's own documentation, the pipelines that keep that knowledge current, and the systems that say whether any of it actually works.

That last part is where most of my time goes — because more than once, the measurement turned out to be the thing that was broken.

Leads an engineering function of 30+ engineers
Builds AI systems hands-on while leading it
Chennai, India · open to remote

What production actually taught me

Not tutorials. The things I got wrong first, and the measurements that told me so.

All writing →

Six things I keep running into

Recurring problems across the systems I've built. I'd rather show the pattern and what it cost than list technologies.

When the measurement liesA test that flattered me for months — first because it was small and skewed toward one kind of question, then because part of it had no answer key to score against. A forecast I checked two months later: the bug projection wrong by more than twice over, the broader one by about 30%. Read → Governing what the AI readsTreating the information you feed a model the way you treat code — versioned, checked, approved by a person, reversible. Including the uncomfortable part: the authority ranking we built for it was wired in everywhere and did nothing at all. Read → Search that answers questionsA fix for "list all of them" that worked perfectly and quietly degraded questions that wanted an explanation. A slow step whose timings had been recorded on every request all along — three-quarters of retrieval time, and the reason an eight-way parallel check ran one request at a time. Read → Failures that went around the gateA job that destroyed most of a live index, then a different job did the same months later, after the safeguards existed. Read →
Seeing how an engineering org worksBuilding the system that tracks how work actually flows. Raising an assistant's high-confidence answers from 81 to more than 90 out of 100 (its own confidence label) was not a data problem: the data had been there all along, and the failures were routing gaps and tool bugs. Soon
Capacity as a modelTurning "the team feels underwater" into a projection leadership could plan against. Then scoring my own forecast against what happened, finding it too pessimistic, and then finding my first correction had only scored part of it. Soon

Most teams tune their systems against a ruler nobody has checked. The outputs are the part everyone worries about — but the measurement drifts too, and it drifts quietly, because nothing measures the measurement.

— the habit behind most of what's here
The lab — not built yet

Three demos, planned

These don't exist yet. They're listed because I'd rather show what I plan to build than claim it's finished — and a site about honest measurement shouldn't open with three links that go nowhere. Each becomes a working link the day it runs.

The release gate PLANNED
Run an automated update against a small knowledge base and watch the safety checks catch a bad one before it reaches users. Then override them on purpose, watch it break, and put it back with one click.
The unreliable ruler PLANNED
Score the same forty questions twice, with nothing changed in between, and get two different results. See which ones flipped. Then run it repeatedly and watch a trustworthy number appear out of the noise.
Question answering, opened up PLANNED
Ask questions of a public documentation set and get answers with sources you can click. See which passages were found, which were thrown away, and how long each step took. Ask something it can't know, and watch it say so rather than invent.