1 August 2026
What our rules cost an AI, and what they buy
Synthetic narration · 4 min
unPaper hands your AI a set of constraints: one fixed page size, no scripts, nothing fetched from the internet, and only the kinds of elements that survive becoming an editable PowerPoint file. Constraints have an obvious cost — the interesting question is whether we were paying it. So we gave the same models the same briefs twice: once working freely, once under the rules.
The fear worth testing
A constraint can make a model build something plainer than it would have built on its own, and nobody ever reports that as a fault. The deck looks fine. It is simply less than the model could do, and you would never know, because you never see the version you did not get. That is the failure this comparison exists to catch.
What we found
The rules did not cost structure. On the briefs where a model built something genuinely structured on its own — a driver tree, a waterfall, a network map — it built the same structure under our rules. What changed is that it had to assemble that structure by hand, because our template had no name for it. In two-thirds of those cases the model reinvented the same shape from scratch, which is how we learned which elements were missing, and it is why the template has 10 more named structures than it did a week ago — each one added only after it was measured converting into real, editable PowerPoint objects.
And the rules bought a great deal. Working freely, roughly one deck in five did not survive conversion into editable PowerPoint. Under the contract that share shrank, more decks were drawn as real vector diagrams rather than pictures, and every deck came out at a fixed, printable page size.
| Working freely | Under the rules | |
|---|---|---|
| Converted to fully editable PowerPoint | 81% | 91% |
| Built at a fixed, printable page size | 97% | 98% |
| Drew real vector diagrams | 46% | 57% |
| Unreadable to the converter | 3 | 1 |
| Content that vanishes without JavaScript | 2 | 0 |
The one that matters most in a meeting
Asked where a subscription price goes, one model built a beautiful slide whose table and both charts were drawn by JavaScript from a block of data. On screen it is perfect. Printed, or converted, it is nearly empty — the numbers never existed in the file itself. That happened more than once among models working freely, and not once under the rules, because forbidding it is one of the rules. It is the clearest example of a constraint that looks like bureaucracy until you watch what it prevents.
What we changed
Every structure a model kept rebuilding by hand became a named element in the template, each one added only after it converted to real, editable PowerPoint objects. The point of the comparison was never to prove the rules are harmless. It was to find the places where they were quietly costing something, and fix those.
How honest this is
Method and limits
165 slides in total across 7 model families, each rendered in a real browser with scripts disabled — the same view our converter has — and then converted, where the result is counted as fully native objects, partly flattened, or unreadable. The briefs describe content that demands a structure without ever naming one, and they are held fixed so later models stay comparable.
The limits. “The same structure” is a judgement made by reading the rendered slides; the conversion counts, page sizes and script checks are machine facts. The two columns do not contain the same number of decks, so they are rates, not a paired test. And one thing deliberately absent: how much CONTENT each side produced. A deck built on our template carries the template’s own frame, which inflates any element count, so comparing richness across the two columns would mostly measure our own furniture. That question needs its own instrument.
Nothing here involves anyone’s documents. Every deck was generated from invented briefs, and unPaper itself still sends no document anywhere.