Most lists of best practices read like they were written to be agreed with rather than used—be clear, be specific, check your work. Fine, but uselessly generic. This article takes positions. Each practice below comes with the reasoning that justifies it and, where relevant, the tradeoff it accepts. You may disagree with some, which is the point: a best practice you have to defend is one you actually understand.
These come from the recurring reality of transforming documents with a model in work that ships to clients, where being wrong has a cost. They assume you already know the mechanics; if you do not, the complete guide to document transformation covers the foundations and this article covers the judgment.
The throughline is a single conviction: a transformation you cannot verify is not a transformation you can use. Everything below serves making the output checkable and the process repeatable.
Treat Preservation as the Default
The opinionated stance: assume the model will change anything you do not explicitly protect, and write your prompts accordingly.
The reasoning
The model has no model of what matters to you. It optimizes for fluent, helpful-seeming output, which means it will round numbers, smooth precise terms, and reorder content if it thinks that helps. Rather than hoping it behaves, list what must not change in every prompt. The tradeoff is slightly longer prompts. The payoff is the elimination of the most damaging failure—silent fact drift. That trade is not close.
Specify the Output Shape Exactly
Never leave the format of the output to the model's discretion when the format matters.
The reasoning
An underspecified output is a negotiation you lose. Ask for "a summary" and you get the model's idea of one; ask for "three bullets, each under fifteen words, naming the action, owner, and date" and you get something you can drop straight into a deliverable. The precision also makes the output verifiable—you can check it against the spec. Vague requests produce results that are hard to evaluate because you never said what right looked like.
Decompose Aggressively
Bias toward breaking a transformation into stages rather than doing it in one heroic prompt.
The reasoning
A single prompt that extracts, restructures, and rewrites divides the model's attention and compounds errors invisibly. Stages let you verify between steps, so an error is caught where it happens rather than discovered three operations later. The tradeoff is more steps and more prompts. For anything consequential, the traceability is worth it. This sequencing discipline is the same one that prevents the multi-step failure in our common mistakes with document transformation.
Make the Model Check Itself
Always run a self-verification pass on output you intend to use.
The reasoning
The model can compare its output to the source and surface its own discrepancies more cheaply than a human reading line by line. Asking it to list every changed fact and every addition not present in the source catches a large share of fabrication and drift for the cost of one prompt. It is not a substitute for human review, but it is a high-leverage first filter. The mistake is treating a fluent output as trustworthy because it is fluent—polish and correctness are unrelated.
Scale Verification to the Stakes
Do not apply the same scrutiny to a throwaway summary and a client contract.
The reasoning
Verification is expensive, and uniform verification either over-spends on low-stakes work or under-protects high-stakes work. Match the effort to the cost of being wrong:
- Low stakes: a quick self-check prompt and a glance.
- Medium stakes: self-check plus human verification of the preservation list.
- High stakes: self-check, full human review, and a second reviewer on the facts that matter.
Calibrating effort to consequence is what lets you depend on the technique daily without grinding to a halt, the practical reality behind our real-world examples.
Build and Reuse Templates
Stop writing transformation prompts from scratch.
The reasoning
A bespoke prompt every time means quality depends on who wrote it and how rushed they were. A template with slots for the source, target spec, preservation rules, prohibitions, and output shape encodes the practices above into the default workflow. People who fill in a good template produce good results without needing to remember every principle. The tradeoff is upfront effort to build the template; it pays back on the second use. The step-by-step assembly in our step-by-step approach to document transformation is essentially a template waiting to be saved.
Forbid Invention Explicitly
Always tell the model what to do with gaps, rather than leaving it to improvise.
The reasoning
A model abhors an incomplete output. Left to its own devices, it fills gaps with plausible inventions that look like real content. An explicit instruction—"mark anything you cannot find as missing; never guess"—redirects that instinct. This is opinionated because some people assume the model will naturally flag uncertainty. It will not, reliably, unless told.
Delimit the Source Unambiguously
Always mark where the source document begins and ends, separate from your instructions.
The reasoning
When the source and your instructions blur together, the model can mistake part of your instruction for content to transform, or part of the content for an instruction to follow. The result is bizarre, hard-to-diagnose output. A clear delimiter—a labeled block, a fenced section, an explicit "the source document is everything between these markers"—removes the ambiguity. This costs nothing and prevents a category of confusing failures that people often misattribute to the model being unreliable. It is not unreliable; it is being asked to guess where the boundary is.
Prefer Instructions It Can Verify Against
Write rules the model and a reviewer can both check, rather than rules that depend on taste.
The reasoning
"Make it professional" is unverifiable—neither the model nor a reviewer can definitively say whether it was met. "Use full sentences, avoid contractions, and keep each paragraph under four sentences" is verifiable. Verifiable instructions produce verifiable output, which closes the loop between what you asked for and what you can confirm you got. The opinionated stance is that vague quality words like "clean," "polished," and "professional" are nearly useless in a transformation prompt and should be replaced with concrete, checkable criteria wherever the quality actually matters.
Iterate on the Prompt, Not the Output
When a transformation comes back wrong, fix the prompt and rerun rather than hand-editing the output.
The reasoning
Hand-editing a bad output fixes one instance and teaches you nothing. The next document of the same kind will fail the same way, because the cause—a missing instruction—is still there. Fixing the prompt fixes the whole class of document going forward and turns each failure into a permanent improvement. The tradeoff is that rerunning feels slower than a quick manual patch in the moment. It is not slower over any horizon longer than a single document. The opinionated position: treat every wrong output as a defect in the prompt, diagnose what instruction was missing, add it, and rerun. Manual fixes are a last resort for one-off documents you will never see again, not a standard practice.
Frequently Asked Questions
Aren't these just common sense?
Some are, but common sense is unevenly applied under deadline pressure. The value is in treating them as defaults rather than things you remember when you happen to have time. Defaults survive busy days; good intentions do not.
Is decomposing always worth the extra effort?
No. For a simple single-operation transformation it is overhead. The practice is to decompose aggressively for multi-operation or high-stakes jobs, where the traceability earns its cost.
Does the self-check prompt actually catch much?
It catches a meaningful share of fabrication and fact drift for the price of one prompt, which makes it high-leverage. It does not catch everything, which is why it sits alongside human review rather than replacing it.
How detailed should the output specification be?
Detailed enough that you could check the output against it mechanically. If you cannot tell whether the output met the spec, the spec was too vague to be useful.
What is the single most important practice here?
Treating preservation as the default. Assuming the model will change anything you do not protect, and listing what must not change every time, prevents the most damaging and least visible failure.
Key Takeaways
- Assume the model edits anything you do not explicitly protect; list preservation rules every time.
- Specify the output shape precisely enough that the result is mechanically checkable.
- Decompose multi-step jobs and verify between stages so errors surface where they occur.
- Run a self-check prompt as a cheap first filter, then scale human verification to the stakes.
- Encode these habits into reusable templates so good results are the default, not a matter of who did the work.