Most of us have written a one off parser for somebody else's ugly export format, and most of us have written the same parser twice. I want to lay out a pattern that made that problem go away for me, because it generalises well past the specific case it came from.
The Problem Shape
Scientific instruments are the extreme version of a problem every developer meets eventually. A plate reader dumps repeated well grids under an undocumented header. A different vendor interleaves time columns. An Excel workbook might carry a header row of well names, or a plate grid, or both on different sheets. Every one of them is internally consistent, none of them is the shape pandas wants, so somebody writes a script, and six months later somebody writes another one.
Two Jobs, Not One
The move that fixes this is noticing that a parser is doing two very different jobs.
Recognising the shape of a file is interpretation, and you only have to do it once per format. Reading values out of that file is mechanical, and it has to be correct every single time.
Once you separate them, the model only ever gets the first job. In labparse the shape becomes a recipe, a small JSON description of where things live in the file, and a deterministic engine executes that recipe. Known formats parse instantly with no model call at all.
The Verification Gate Is The Whole Design
When an unknown format shows up, the raw file goes to your own model once and the model proposes a recipe. That recipe is only accepted if it actually parses the file. Wrong recipe, rejected, retry.
The model never emits a value that lands in your table. It emits a description of a format, and that description has to survive a mechanical test against the exact file in front of you before anything flows through.
That is the property worth stealing. A wrong guess can fail loudly, which you can handle. What it cannot do is quietly produce plausible wrong numbers, which is the failure that actually costs you.
Accepted recipes cache in your home directory, so a format costs at most one model call ever and every parse after that runs offline. Recipes are plain JSON, so you can read them, diff them, and check them into a repo.
Where Else This Applies
Anywhere you are tempted to have a model transform data directly, ask whether it could write the transformation instead, and whether you could test that transformation against real input before trusting it. Config generation, schema mapping, log parsing, scraper selectors, data migrations. Same shape every time: the model proposes, something deterministic disposes.
