Deterministic parsing or a model — when is the cheapest call the one you never make?

Deterministic parsing or a model — when is the cheapest call the one you never make?

Our contract-review pipeline ingests a customer's legal playbook. If it arrives as a spreadsheet, the ingestion costs nothing at all — no model calls. If it arrives as a PDF, the same stage costs dozens.

Same product, same output, same downstream pipeline. The customer's choice of file format sets the unit economics, and almost nobody designs for that.

For the engineering lead whose per-document cost is higher than it needs to be. 7 minute read.

Two paths, same destination

The playbook is the set of rules a legal team applies. It has to become structured data: terms, the categories they belong to, the risk criteria attached to each.

From a spreadsheet, that is parsing. Rows are terms, columns are attributes, the structure is already there. Deterministic code reads it. Zero model calls.

From a PDF or a Word document, that is extraction. There is no structure — just text that a human would recognise as organised. So the pipeline chunks it, uses a model to pull terms out, and uses a model again to enrich them. Dozens of calls, and a few minutes.

The destination is identical. Both produce the same structured playbook the rest of the pipeline consumes. Nothing downstream can tell which path was taken.

What the spreadsheet already knows

The difference is not that one format is more machine-readable. It is that a spreadsheet contains a decision that a PDF does not.

When somebody puts a term in row twelve, column C, they have already answered "what kind of thing is this, and what does it belong to?" The schema is the answer. The work of classification happened when a human made the file.

A PDF has thrown that answer away. It contains the same information, rendered for a reader, and the structure exists only in typography — headings, indentation, bold. Recovering it means inferring what the author knew and did not record.

That is what you are paying a model to do: reconstruct a decision somebody already made. Which reframes the cost. It is not the price of understanding a document. It is the price of a format that discarded structure on the way in.

The comparison

• Input — Deterministic parsing: Spreadsheet with a known schema · Model extraction: PDF, Word, anything
• Model calls — Deterministic parsing: None · Model extraction: Dozens per playbook
• Time — Deterministic parsing: Effectively instant · Model extraction: Minutes
• Failure mode — Deterministic parsing: Loud — a missing column throws · Model extraction: Quiet — a plausible-looking wrong term
• When the format changes — Deterministic parsing: Breaks immediately and visibly · Model extraction: Absorbs it, possibly wrongly
• Auditability — Deterministic parsing: Row twelve became term twelve · Model extraction: An inference you cannot replay
• What it demands — Deterministic parsing: The customer uses your template · Model extraction: Nothing

The last two rows are where the real argument lives, and they cut in opposite directions.

Deterministic parsing fails loudly. A missing column raises an error before anything reaches a lawyer. Model extraction fails quietly — a mis-extracted term is a plausible-looking rule that will be applied to every contract, and nothing about it looks wrong.

But deterministic parsing demands something from the customer, and the model path demands nothing. That is not a technical trade. It is a sales one.

The upload form is a cost lever

Here is the practical conclusion, and it is not an engineering change.

If you offer a template, most customers will use it. Not all — but each one who does moves from the expensive path to the free one, permanently, for every document they ever send. No model gets cheaper, no prompt gets shorter, and the saving is total rather than marginal.

Most teams treat ingestion as a solved problem and the upload form as UI. It is neither. It is the point at which you find out what every subsequent operation will cost, and it is one of the few places where a product decision changes unit economics rather than shaving them.

The framing worth carrying: the cheapest model call is the one you never make. Optimising a prompt gets you a percentage. Removing the call gets you all of it — and removes a failure mode at the same time, because a call you never make cannot fail, cannot hallucinate and cannot be retried nine times during an outage.

What the free path might not get

There is a cost to the cheap path that the comparison table above does not capture, and it is worth being precise about because we are not certain of its extent.

Model extraction is not one step. It is three: chunking the document, extracting terms from the chunks, and then enriching those terms. Enrichment is the part that adds what the source document did not say — searchable phrasings, reference terms, the material that makes retrieval work later.

The deterministic path skips all three, enrichment included. A spreadsheet row becomes a term because a human typed it, and nothing adds to it.

So the two paths may not produce equally useful playbooks, even though both produce the same structure. The expensive path buys enrichment as a side effect of needing extraction at all. The cheap path never pays for it — and never receives it.

We are stating this as a design consequence rather than a measured difference, because our own documentation records the call counts and the output shape without saying whether the structured path receives the same enrichment. That is a question worth answering before recommending the template to anyone, and it is the kind of gap that only appears when you read a cost claim and a capability claim side by side.

If it holds, the framing sharpens rather than collapses. Offer the template, and offer enrichment as a deliberate second step for customers who want it — so the saving is real and the trade is visible, instead of arriving as a quietly thinner playbook nobody chose.

Where deterministic parsing breaks

It is brittle, and that brittleness is the price of the auditability.

A template only helps if it is followed. Merged cells, a helpfully renamed column, an extra header row somebody added for clarity — each breaks a parser that a model would have absorbed. The flexibility you removed to gain determinism is flexibility your customer did not agree to give up.

And templates age. The schema you designed encodes what you thought a playbook contained. When a customer needs a field you did not anticipate, they will put it somewhere — a spare column, a note in an existing cell — and your parser will either ignore it or misread it. Model extraction would at least have seen it.

So the honest position is not "deterministic is better". It is that both paths should exist, and the cheap one should be the default you make easy — which is exactly the shape our pipeline takes. Offer the template, support the general path, and accept that some proportion of customers will always send a PDF.

The failure mode of insisting on structure is a customer who cannot onboard. That costs more than the model calls ever will.

What we would build, and the check for Monday

How we build it. Make the structured path the obvious one — a template offered at the point of upload, not buried in documentation — and instrument which path each document took. You cannot manage a cost you are not measuring per document, and the split between paths is the single number that predicts your ingestion bill.

Then validate the structured input properly and fail early. A parser that throws on row three is doing its job; a parser that guesses is a model extraction with none of the tolerance and all of the risk.

Status, stated plainly. This is a system we built. It runs, it is demonstrable on a call, and it has zero delivered engagements. We build these on request, against your documents. No number here describes anyone's business but our own.

The check worth running, and it needs nothing from us. Take your highest-volume ingestion path and ask one question: is there a format in which this input would need no model calls at all? If there is, and you are not offering it, you are paying every month for structure your customer would have given you for free.

About Cognilium Cognilium is an AI engineering company — agent systems, retrieval, knowledge graphs, voice AI and the production plumbing that makes them survive contact with real workloads. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Want to know which of your ingestion paths is costing you? Book a 15-minute call — we will walk the split with you, on your formats if you bring them. No deck.

Sources

This article draws on our own build. The pipeline stage described here feeds the routing and analysis covered in the sibling chapters.