July 2, 2026 / 5 min read

Xela: Teaching AI to Think Like a Statistician

So the actual design problem was never "can AI clean survey data." It obviously can, in the sense that it can produce something plausible. The problem was: how do you get an AI to make judgment calls, while keeping the pipeline itself deterministic and auditable? The answer I landed on was to stop treating "the AI" as one big black box that touches everything, and instead break the whole workflow into small, single-purpose stages, each one explicitly labeled by what kind of work it's doing:

Xela: Teaching AI to Think Like a Statistician

The problem that started it

Anyone who has sat in a research or M&E team knows the ritual. A survey closes. Two hundred, five hundred, sometimes five thousand responses land in a spreadsheet. And then the real work begins and this type of work is usually not the not the fun kind. Someone has to figure out which columns are actually usable. Someone has to decide whether that outlier is a data entry error or a genuinely extreme respondent. Someone has to work out which questions belong together as a composite score, which variables need recoding, which missing values are random and which are hiding a pattern.

Someone! Someone! Someone!

Then, once the data is finally clean, SOMEONE has to design the analysis, pick the right test for the right question then run it, interpret it, and write it up in language a non-statistician can trust.

Depending on the dataset, that whole cycle can eat a week. Sometimes more. And a huge share of that week isn't insight, it's plumbing. I wanted to know: how much of that plumbing is actually a series of judgment calls that a well-instructed model could make consistently and how much is just mechanical work that never needed a human in the first place? That question became Xela.

The uncomfortable part about "AI-powered analysis"

Aside from data privacy, here's the thing that makes most "AI does your data analysis" tools untrustworthy: if you ask a language model to clean a dataset twice, you may get two different answers. That's fine for a chatbot. It's not fine for something that's going to sit in a methods section of a report someone's organization will act on. So the actual design problem was never "can AI clean survey data." It obviously can, in the sense that it can produce something plausible. The problem was: how do you get an AI to make judgment calls, while keeping the pipeline itself deterministic and auditable? The answer I landed on was to stop treating "the AI" as one big black box that touches everything, and instead break the whole workflow into small, single-purpose stages, each one explicitly labeled by what kind of work it's doing:

DISCOVER stages — pure Python, no AI at all. They scan the data and produce evidence: outlier reports, missing-data patterns, entropy scores on messy free-text columns. Deterministic, repeatable, boring in the best way.

PROMPT AI stages: a model is handed a compact, structured summary of what the discovery stage found (never the raw dataset) and asked to make a specific, narrow judgment call: is this outlier a real value or a broken one? Is this missingness random or systematic? What's the right statistical test for this objective?

IMPLEMENT stages: back to plain Python, which takes the AI's verdict and mechanically applies it. No creativity here. Just execution.

That rhythm (discover, judge, implement ) repeats through the whole pipeline, from the moment a raw file lands to the moment a finished, written-up report comes out the other end. The AI never gets to freelance across the whole dataset. It gets asked narrow questions it's actually good at answering, and every answer it gives becomes a permanent, logged decision.

I won't walk through the actual prompt engineering or the statistical decision trees, that's the part I'd rather keep in the workshop for now. But the pattern every stage follows is simple enough to share, and honestly, it's the part I'm proudest of, because it's what makes the whole system replayable:

python
class PipelineStage:
    """
    Every stage in the pipeline follows the same contract, whether
    it touches AI or not. That uniformity is what makes the pipeline
    replayable and debuggable stage-by-stage.
    """

    role: str          # DISCOVER | PROMPTAI | IMPLEMENT
    usesai: bool
    writestoledger: bool

    def run(self, evidencein, context):
        """
        DISCOVER stages return an evidence bundle.
        PROMPTAI stages return a verdict, given evidence + context.
        IMPLEMENT stages return a transformed dataset, given a verdict.
        """
        raise NotImplementedError

And every judgment call ( human-triggered or AI-issued ) gets written to something we internally call the Action Ledger: an append-only record of what was decided and why, keyed to the specific variable it touched. By the time a dataset reaches the final report stage, there's a full paper trail: which columns were recoded, which outliers were capped versus nulled, which missing-data strategy was used where, and (this is the part that saves the most time) that ledger is what actually gets turned into the methods section of the report. Instead of a human paraphrasing their own memory of what they did three days ago we have the ledger, converted straight into prose. There's also a scenario layer sitting on top of all this: because every stage's output is snapshotted, a researcher can go back, change one assumption ( say, swap which variables form a composite score, or tweak an analysis objective) and have only the downstream stages replay, instead of re-running the entire pipeline from scratch. Cleaning is expensive. Re-asking "what if" shouldn't be.

Why this matters more than it sounds

None of this is really about survey data specifically. It's about a broader bet: that a lot of "expert judgment" work is actually a sequence of small, well-scoped decisions, and the moment you can isolate each decision, log it, and make it replayable, you can hand a meaningful chunk of it to AI without losing the thing that made expert judgment trustworthy in the first place which is the ability to explain, defend, and reproduce it. The goal, plainly stated: get from raw dataset to a defensible, written analysis in hours instead of days, without the researcher ever wondering "wait, why did it do that to my data" because the answer is always sitting in the ledger, not buried in a model's head.

Where it's headed, and where I could use hands.

Xela right now is a working, multi-service pipeline, and just a backend, a cleaning/analysis engine running as background jobs but it's still very much a workbench, not a polished product. There are stages that need better fallback behavior when a model gives an ambiguous verdict. There's a visualization layer that deserves a much better design pass. There's an entire class of "what if this dataset isn't a survey at all" that I've only started poking at. If any of this is interesting to you statisticians who want AI-assisted cleaning to actually be trustworthy, engineers who like the discover/judge/implement pattern, frontend folks who want to make an analysis ledger genuinely readable to a non-technical stakeholder, I'd love to talk. This isn't finished at all. It's an open problem looking for people who find it as interesting as I do. I wish it could have qualified for a portfolio project but I reserve that side of things so things I will be sharing 100% of.

I am pretty sure someone reading this will be as fascinated by this as I have been so far. If you are that person , kindly get in touch. I am open to conversations if you want to contribute, poke holes in the approach, or just argue about whether "deterministic AI pipeline" is an oxymoron.

Keep reading

Related insights

All insights ->

So Good It Hurts: My Drugstoc Internship Experience