Rewrite a dense internal policy into something people will actually read
Someone finds the travel approval rule after booking the flight. Rewriting the policy isn't a tone exercise: a plain-English version that quietly contradicts it is worse than a policy nobody reads, because people will follow it.
What you'll make
a checked rules table and a plain-English guide to one policy section, ready for the policy owner’s sign-off.
What you'll need
the current policy text with its definitions and appendices, ChatGPT, Claude, Gemini or Copilot in a work account your organisation allows for that material, and a named policy owner. Allow about forty minutes for one section.
Example result.
Before you book. If your trip includes an overnight stay or travel outside the UK, get your Budget Holder’s approval first. One approval covers a trip that’s both. If the estimated total cost is above £750, you also need the Finance Manager’s approval before booking.
Making the booking. Book through Portal. Only if Portal is unavailable may you book another way, and then you must ask your Budget Holder to approve it afterwards. The approvals above still apply.
1. Choose one section and its reader
Start with one task, such as booking business travel. Write down who the guide is for and what they need to do, plus the policy’s title, version and location so the guide can point back to it.
Include the definitions, exceptions and any appendix the section relies on. “The thresholds in Appendix 2” isn’t a complete input without Appendix 2. If you can’t get a referenced section, mark it missing and pause the guidance that depends on it.
For HR, contractual, legal, compliance, safety or safeguarding policies, involve the responsible specialist before drafting. For an ordinary booking guide, the normal policy owner is enough.
Why this works: complete inputs stop the model guessing at what a cross-reference says.
What you should see: one section, its definitions and appendices, and a line naming the reader and task.
2. Extract the rules before any prose
Help me prepare a plain-English guide to a policy. First extract the rules; do not write the guide yet.
Audience and task: [audience and task]
Policy title, version and section: [policy details]
Use only the policy material below. Make a table with one rule per row: Who | Rule | Timing | Conditions and exceptions | Source. Include requirements, prohibitions, permissions and recommendations, and keep must, must not, may and should distinct. Keep amounts, thresholds, role names and defined terms exact. For Source, give the clause and a short exact quotation. Keep each exception attached to its rule.
If a person, deadline or other detail is absent, write "not specified". Flag conflicting clauses and quote both. After the table, list undefined terms, missing referenced material and anything ambiguous.
POLICY MATERIAL
[policy text][audience and task] is your line from step 1; [policy details] the title, version and section; [policy text] the section, definitions and appendices.
Why this works: a table of rules is easier to check than polished sentences, and “not specified” keeps a gap visible instead of filling it.
What you should see: one row per rule with a quoted source, then a short list of terms and questions.
3. Check the table and take the gaps to the owner
Read each row against the original, then read the original again for rules the table missed. Look for:
- Invented detail: “in advance” becoming “at least 48 hours before booking”.
- Changed strength: “must” becoming “should”, or a permission becoming a requirement.
- Lost limits: a rule for travel outside the UK appearing to cover every trip.
- Changed meaning: a defined “Budget Holder” becoming “your manager”.
If a row is wrong:
Correct this row using the exact source below. Keep the source's meaning, level of obligation and conditions. Do not add a deadline, approver or exception the source omits. Return the corrected row and any unresolved question.
ROW: [row]
SOURCE: [clause and definition]Send the open questions to the policy owner. They may point to a definition, approve an explanatory note or decide the policy needs changing. Keep those outcomes separate: an informal answer that adds a deadline isn’t an existing policy requirement.
Why this works: mistakes are cheapest to fix in the table, before they’re dressed in readable sentences.
What you should see: a checked table, and written answers (or a clear “still open”) for each question.
4. Draft around the reader’s task
Write a plain-English guide for [audience and task], covering [policy details]. Use only the checked table and definitions below. Organise it by the reader's tasks, with short headings and sentences, in UK English, addressing the reader as "you".
Include every rule in scope with its timing, conditions and exceptions. Preserve must, must not, may and should, and keep defined terms, roles, amounts and thresholds unchanged. Do not add advice, deadlines, examples or reassurance. Where a detail is unresolved, say so. End with the policy title and version and a line saying the policy is authoritative. Afterwards, list anything that needs review.
CHECKED TABLE AND DEFINITIONS
[table][audience and task] and [policy details] are the same as in step 2; [table] is the checked table, definitions and any owner-approved notes, labelled as such.
Why this works: task headings put the rule where people look for it, and keeping defined terms means a few formal words survive. That’s fine if they still name the right person.
What you should see: a short guide with task headings, every table row represented, and a review list.
5. Check the guide and get sign-off
Work from each table row to its sentence in the guide, then back from each guide sentence to the policy. Check the original too, so an extraction error doesn’t pass through both stages.
Send the owner the source, table, guide and remaining questions. Save the approved guide with its policy link and version.
Why this works: two-way checking catches both dropped rules and added ones.
What you should see: owner sign-off, or a question that holds the guide back.
Check the result
- Every table row appears in the guide, and every guide instruction traces to a clause.
- The small words survived: “before”, “after”, “only”, “unless”, “more than”, “at least”.
- Defined roles keep their names; nothing has become “your manager” without support.
- Each gap says it’s a gap, not a plausible deadline.
The usual failure: a readable sentence that changes the rule. “Above £750” becomes “£750 or more”; “only if Portal is unavailable” becomes “if Portal is down, book another way and get approval later”, which quietly drops the approvals still needed in advance. Spot it by comparing every threshold and exception word for word with the source.
This guide sentence changes the rule: [sentence]. The source says: [clause]. Rewrite the sentence to keep the source's threshold, conditions and level of obligation. Check the rest of the guide for the same change and list any you find.[sentence] is the guide line; [clause] is the exact policy text it should match.
Worked example: clause 4.3
Fictional example. A travel policy, version 3:
Definitions: Portal is the company's travel booking system. Budget Holder is the person responsible for the trip's cost code. The Travel Team administers this policy.
4.3 Where travel is undertaken in connection with business activities, employees shall ensure that bookings are made through Portal save where Portal is unavailable, in which case alternative means may be used and retrospective approval must be sought from the Budget Holder, without prejudice to any prior authorisation otherwise required hereunder. Travel involving overnight accommodation and/or destinations outside the United Kingdom shall require prior authorisation from the Budget Holder and, in the case of the latter, notification to the Travel Team. Expenditure exceeding the threshold set out in Appendix 2 shall require additional approval.
Appendix 2: The threshold in clause 4.3 is an estimated total trip cost of £750. Additional approval: Finance Manager, before booking.One sentence structure, six rules, a cross-reference and an “and/or”. The checked table:
| Rule | When and conditions | Source |
|---|---|---|
| Book through Portal | Unless Portal is unavailable | 4.3 “bookings are made through Portal” |
| May book another way; seek retrospective Budget Holder approval | Only if Portal is unavailable; deadline not specified; advance approvals still apply | 4.3 “save where Portal is unavailable” |
| Get Budget Holder approval | Before booking; overnight stay or travel outside the UK | 4.3 “prior authorisation from the Budget Holder” |
| Notify the Travel Team | Travel outside the UK; timing not specified | 4.3 “notification to the Travel Team” |
| Get Finance Manager approval | Before booking; estimated cost above £750 | Appendix 2 |
The first draft guide said: “If your trip costs £750 or more, get Finance approval. If Portal is down, book another way and get approval afterwards.”
- The failure. Two small words moved. Exactly £750 doesn’t exceed £750. And “get approval afterwards” lets an outage waive the advance approvals that “without prejudice” keeps.
- The repair. The repair prompt, run on each sentence with its clause, gave the example result at the top of this page.
- What the owner’s review produced. The “and/or” question had never been considered; the owner confirmed one approval covers a trip that’s both overnight and abroad. The deadline for notifying the Travel Team was genuinely absent, and the owner asked the guide to say so. The rewrite surfaced a real gap in a live policy. It didn’t fill it.
Task kit for this job: Download (ZIP) · Reusable instructions
Go deeper
Optional training: Run a second coverage check
A second pass can spot missing or added instructions. It’s another model output to verify, not independent assurance.
Check this guide against the policy and the checked rules table. Do not rewrite it. For each table row, find the matching guide sentence or mark it missing. List guide statements the policy doesn't support, including advice, deadlines and approvers. Flag changed requirements, permissions, definitions, thresholds or conditions, quoting both versions.Review each finding yourself. An answer saying “all rules covered” doesn’t replace the source check.
Optional training: Handle long or consequential policies
For a long policy, work one reader task at a time, carrying shared definitions and exceptions across. A decision tree can help with several routes, but every branch needs the same source checks.
Don’t use a summary to decide an individual case. The table may also reveal a rule that deserves changing; record that as a question for the owner. Improving the writing doesn’t authorise changing the process.
Optional training: Keep the guide in step with the policy
Give the guide a named owner, keep the checked table and record which policy version it summarises. When the policy changes, update the affected rows and the guide, and retire the old guide until the owner approves the new one. To work out what changed between two versions first, use Find out what a policy change means for your team.