Never Let the Model Type a Number

The last thing the pipeline produces is a client-ready report: pages of exact figures, dates, and tables, every cell of which has to be right. That makes it the single worst place to hand a language model a keyboard. Ask a model to render a table of numbers and it will, most of the time. Then, on some run, it transposes a digit, rounds one total differently, or helpfully "corrects" a figure that was already correct. So in this pipeline the model never types a number at all.

The document is assembled in two layers

A deterministic renderer builds the entire report skeleton first: every table, every date, every figure, fully populated and arithmetic-correct, with <!-- NARRATIVE --> markers left wherever prose belongs. Only then does the model step in, and its whole job is to fill those markers with sentences. It reads finished numbers and writes about them; it never authors them.

## §2  Plan at a glance                       ← heading: rendered
| Scenario     | Success | Median @ 90 |       ← table: rendered
| P1R_P2R keep | 100%    | 11,249,276  |       ← every figure: rendered

<!-- NARRATIVE: plan_summary -->              ← the model writes ONLY here

The boundary isn't a suggestion, it's a wall. The agent is told, in as many words, not to re-type any table, not to write a helper script to fill the markers, not to post-process the numbers, only to replace each marker with prose, in place. Everything numeric is upstream of the model's reach by the time it arrives.

The model writes about the numbers. It never writes the numbers.

A wrong number that looks right is the worst kind

Two reasons the model doesn't get to transcribe. The first is arithmetic: a renderer computes a total once from the same tested functions as everything upstream, whereas a model retyping that total is a fresh chance to be wrong on every run. And the failure it produces is the most expensive one there is: not a crash, not a blank, but a plausible figure that's quietly off by a digit and sails straight past the eye.

The second is that the renderer is more right than the model, not just more consistent. Because the numbers flow from the pipeline's own computation layer, it even fixes arithmetic the model would have fumbled if asked. Letting the model retype a value doesn't just risk an error; it throws away a guarantee you already paid for.

A wrong number that looks right is the most expensive kind. It survives review.

Give each half the job it's actually good at

None of this is distrust for its own sake. It's routing each half of the document to the tool suited to it. The numbers want determinism, and code delivers it flawlessly. The narrative wants judgment: which of the client's questions to answer first, how to explain sequence-of-returns risk in plain language, what to flag as worth a human conversation, and that is exactly what a language model is good at and what code cannot do at all.

Split the document along that line and each side plays to its strength: the prose reads like a person wrote it; the figures are exact, because a function produced them. It's the same principle as the harness note: the model decides, the code computes, carried all the way out to the last rendered cell.

The polish is the model's. The truth is the code's.

Any document that mixes data with explanation

This isn't specific to reports or to finance. Any time you have an LLM produce a document that interleaves exact data with prose about it, be it an invoice with a note, a dashboard with commentary, a summary citing figures, the same split applies. Render the data deterministically, leave marked slots for the language, and make the seam between them a hard wall rather than a hope. The reader gets one voice; underneath, it was always two.