Let the model write HTML, not file internals

The idea is simple: give the model last year's report and this year's facts, and let it update the document. The obvious approach doesn't hold up.

Runs are not sentences

I gave the model an outline of the PowerPoint file, close to how the file stores it, and asked for edits. It answered with operations on runs, the formatting fragments Office splits text into. One sentence was stored as 24 runs. The new sentence came back glued onto 23 old pieces. A request to turn an interim report into the final report changed 15 of 127 lines and left the rest saying "interim".

The model isn't bad at writing. It's bad at bookkeeping inside a file format it can only half see.

Fixed-size HTML pages

So the model doesn't see the file anymore. It sees each slide or page rendered as HTML at its real size, with an id on every block of text. It answers one question per block: keep it, rewrite it, or flag it. Code puts the text back into the file. The browser measures whether the new text still fits its box, and prints the PDF.

On a real interim report asked to become the final one, all 171 blocks get a verdict and no figure appears without a source. Size matters too: shrinking the pictures in that HTML takes it from 128 MB to 18 MB, which is the difference between a model call that works and one that doesn't.

Rules in code, not in the prompt

Some edits should never happen, whatever the model says. A rewrite that cuts a text box to less than half its words is refused. Geometry changes are refused by name: the model doesn't get to move shapes. New operation types arrive forbidden until I allow them. Putting the main operation first in the instructions also cut the model's answers from about 1,000 tokens to 180.

I also tested whether the model does better with HTML or with the file's own notation, three runs each. No clear winner. So the reason for HTML is not that models like it. It's that I can render it, measure it and check it.