Plenty of advice about transforming documents with AI stays at the level of principles—understand your constraints, mind the failure modes, verify the output. All true, and all useless when you have an actual report open and a deadline. This article is the opposite of that. It is a sequence. Do this, then that, then the next thing, and at the end you have a transformed document you can trust.
You can follow it today, on whatever document is in front of you. We will assume you already grasp the basic idea that document transformation means turning a source document into a target document with a model. If that part is fuzzy, the beginner's guide to document transformation builds it from scratch. Everything here is the procedure itself.
Work through the steps in order. The order matters: each step produces something the next step needs. Skipping ahead is how people end up with confident-looking output that is quietly wrong.
Step 1: Write Down the Target
Before you touch a prompt, decide exactly what you want out. Vague targets produce vague results.
Answer four questions
- Format: a summary, a table, an outline, structured data, a rewritten version?
- Audience: who reads this—an executive, a client, a teammate, a system?
- Length: roughly how long should the output be?
- Purpose: what decision or action will this output support?
Write the answers down in a sentence or two. This becomes the target specification you will hand the model. If you cannot describe the target clearly to yourself, the model has no chance.
Step 2: List What Must Not Change
This is the step that prevents most disasters. Go through the source and identify the elements that must survive the transformation exactly.
Build a preservation list
- Names of people, companies, and products.
- Numbers: amounts, dates, percentages, identifiers.
- Quoted language and any legally or technically precise terms.
You will paste this list into the prompt as explicit preservation rules. The model treats facts as editable unless told otherwise, so this list is what turns "rewrite this" into "rewrite this without breaking anything that matters."
Step 3: Assemble the Prompt
Now build the prompt from parts rather than writing one long paragraph.
The structure to follow
- State the goal and the audience in one line.
- Paste the source, clearly delimited so the model knows where it begins and ends.
- Give the target specification from step one.
- Give the preservation rules from step two.
- Add prohibitions: "Do not invent information. If something is missing, mark it as missing."
- Specify the exact output shape.
This component-based structure mirrors the prompt anatomy in the complete guide to document transformation. Assembling from parts means you can reuse the structure on the next document instead of starting over.
Step 4: Run, Then Self-Check
Run the prompt. Then, before you even read the output closely, run a second prompt that asks the model to check its own work.
The self-check prompt
Ask: "Compare your output to the source. List every fact, name, number, or date that differs, and list anything in your output that does not appear in the source." This forces the model to surface its own fabrications and drift. It will not catch everything, but it catches a great deal cheaply, and it costs you one extra prompt.
Step 5: Verify Against the Source Yourself
The model's self-check is a filter, not a guarantee. You still verify the things that matter with your own eyes.
What to verify
- Every item on your preservation list appears unchanged in the output.
- Nothing in the output was invented—each claim traces to the source.
- The tone and format match the target specification, all the way through.
For high-stakes documents, have a second person do this pass. Verification scaled to the stakes is the dividing line between experimenting and depending on the technique, a theme in our best practices for document transformation.
Step 6: Decompose If It Is Too Big
If the document is long or the transformation involves several distinct operations, do not force it into one pass. Break it up.
How to decompose
- Split the source into sections and transform each, then assemble.
- Separate distinct operations—extract first, then restructure, then rewrite—into their own prompts.
- Verify each stage before moving to the next, so an error does not compound.
Decomposition trades a little extra effort for a lot of reliability. On anything that will be sent to a client, the trade is almost always worth it.
Step 7: Save the Prompt as a Template
The final step is the one that pays you back on every future document. Once a transformation works, do not throw the prompt away.
Turn the run into reusable structure
- Replace the specific source with a clearly marked slot.
- Keep the target specification, preservation rules, prohibitions, and output shape as a reusable skeleton.
- Note any adjustments you had to make mid-run, so the next person does not rediscover them.
A saved template means the next document of the same kind starts at step three with most of the work already done. It also makes your output consistent across people, because everyone fills the same structure rather than improvising. The first time you reuse a template instead of writing from scratch, the value of saving it becomes obvious.
Handling Edge Cases
Real documents do not always cooperate. A few situations come up often enough to plan for rather than improvise.
Common edge cases and responses
- The source contradicts itself. Instruct the model to surface the contradiction rather than silently pick a side, and resolve it yourself.
- A required field is genuinely absent. Confirm the model marked it missing rather than guessing, then decide whether to chase the source or note the gap in the output.
- The output is right but formatted slightly off. Do not rerun the whole transformation; a small follow-up prompt that adjusts only the format is faster and safer than regenerating content you already verified.
Planning for these in advance means an awkward document does not derail your process—it just routes through a known response.
A Quick Self-Audit Before You Send
Before the transformed document leaves your hands, run a final thirty-second pass. This is not the same as the verification in step five; it is a sanity check on the whole result as a unit.
The audit questions
- Does the output actually serve its stated purpose, or did it answer a slightly different question than you intended?
- Is anything in it that you cannot point to a source for? If so, that is fabrication and it does not ship.
- Would the intended reader understand it without the original document in hand? If not, the transformation is incomplete.
This last check is easy to forget because you have the source fresh in your mind, but the recipient does not. A transformation that only makes sense alongside its source has not finished the job. Catching that here, before you send, saves a round trip and protects the trust that makes the whole technique worth using.
Frequently Asked Questions
Can I really do this on my first try?
Yes, if you follow the steps in order. The procedure front-loads the thinking—target, preservation rules—so the prompt itself becomes mechanical. Most first-try failures come from skipping steps one and two.
How long does the whole process take?
For a short document, a few minutes including verification. For a long one that needs decomposition, longer—but the time goes into checking, not fighting the model, which is time well spent.
Do I have to do the self-check prompt every time?
For anything you will act on or send, yes. It is one extra prompt and it catches fabrication and fact drift that are easy to miss by eye. Skip it only on throwaway work.
What if the output is still wrong after all this?
Identify the specific thing that is wrong and add an explicit rule about it, then rerun. Wrong output is almost always a missing instruction, not a limit of the technique.
When should I split the document instead of doing it in one pass?
When the source is long enough that content starts getting dropped, or when the job involves several distinct operations. Decomposing and verifying each stage prevents errors from compounding.
Key Takeaways
- Define the target—format, audience, length, purpose—before writing any prompt.
- Build an explicit preservation list of names, numbers, and exact language; this prevents most fact errors.
- Assemble the prompt from parts: goal, source, target spec, preservation rules, prohibitions, output shape.
- Run a self-check prompt, then verify the preservation list yourself before trusting the result.
- Decompose long or multi-operation jobs into stages and verify each one.