LearnGrokNothing here is clinical advice, and nothing here should touch identifiable patient information.
Use this workflow when an administrative process has changed and you need a policy document ready for governance review. It gives you a controlled draft with responsibilities, steps, exceptions and a clear approval record.
Use only de-identified operational material. Do not paste patient names, dates of birth, contact details, record numbers, free-text case notes or any other identifiable patient information into the model.
Key point
Start with agreed evidence
A policy update records a decision already made. It does not decide whether the operational change is safe, lawful or clinically appropriate.
1. Assemble the change pack
Create one working folder for the update. Give it a neutral reference, such as OPS-POL-2026-04, rather than a patient, team member or incident name.
Put these items in the folder:
- The current approved policy, including its title, owner, version, approval date and review date.
- The agreed change record. This may be meeting minutes, a signed decision log or an approved process map.
- The revised administrative procedure, if one exists.
- The list of roles involved in the process.
- Known exceptions and escalation routes.
- Your organisation's policy template and document-control requirements.
- The names or job titles of the people who must review and approve the draft.
Before you use the model, make a short change register. This is the source of truth for the draft. Use a table with these fields:
| Field | What to enter |
|---|---|
| Change ID | A simple reference, such as C01 |
| Existing position | What the current policy says or does not say |
| Agreed change | The approved new process |
| Reason | The operational reason supplied by the change owner |
| Owner | The role accountable for carrying it out |
| Evidence | The source document and section |
| Open point | Anything not yet agreed |
Do not fill gaps with assumptions. Mark them OPEN in the register.
Watch out
Separate agreement from suggestion
A discussion note is not an approved change. Keep proposed wording out of the source pack until the responsible lead has confirmed it.
2. Extract the current policy structure
Read the existing policy first. List its actual headings in order, including document control, purpose, scope, responsibilities, procedure, exceptions, training, audit, references and appendices. Do not assume every policy uses those headings.
Then compare each change-register item with the current policy. Mark whether it requires one of these actions:
- Amend: replace existing wording.
- Add: create a new section, step or exception.
- Remove: delete a process that no longer applies.
- Confirm: leave the policy wording unchanged, but record that it was checked.
- Open: the evidence is insufficient to draft safely.
This gives you an amendment map. It prevents a common failure: adding a new procedure step while leaving an older, conflicting step elsewhere in the document.
3. Prepare a bounded drafting prompt
Paste only the de-identified policy text, the change register and the amendment map. Ask the model to preserve the policy's existing structure and distinguish confirmed content from unresolved points.
Use a prompt like this:
Draft a revised administrative policy using the supplied policy structure and change register. Apply only agreed changes. For each procedure, state the responsible role, trigger, ordered actions, required record, exception and escalation route where supplied. Mark missing information as [OPEN: question]. Do not add clinical instructions, legal claims, timeframes, systems, responsibilities or approval statements not present in the source material. Return: 1) a clean draft, 2) a change log by section, and 3) a list of open questions.
If the source material is long, work section by section. Keep the same change IDs throughout. Model behaviour and available features can vary, so check the current guidance in the xAI documentation overview before relying on a particular document-handling method.
Note
Use role titles, not people
Write Booking coordinator, Service manager or Governance lead. Named individuals make a policy harder to maintain and can expose staff information unnecessarily.
4. Build the responsibilities and procedure sections
Review the draft against the change register. For every changed action, make sure the policy answers five operational questions:
- Who performs the action?
- What triggers the action?
- What do they do, in the right order?
- What record do they create or update?
- What happens if the usual route cannot be followed?
Use precise administrative wording. For example, prefer The referral administrator records the outcome in the approved scheduling system over Staff should update the system promptly.
Where more than one role is involved, add a responsibility table.
| Role | Required action | Handover or escalation |
|---|---|---|
| Intake administrator | Checks the submission against the agreed intake fields | Sends incomplete submissions to the stated return route |
| Service coordinator | Allocates work using the approved process | Escalates capacity issues to the service manager |
| Service manager | Reviews unresolved operational exceptions | Records the decision through the local governance route |
Do not invent an escalation route. If the source documents do not state one, retain [OPEN: escalation route to be confirmed].
5. Test the draft for conflicts and omissions
Run a structured check before sending anything for review. Read the draft as if you were a new administrator running the process on a busy Monday.
Check each item in the table below.
| If you see this | Treat it as wrong when | What to do |
|---|---|---|
| A new step | No role owns it | Add the agreed role or mark it open |
| A responsibility | It has no action or record | Specify the action and evidence of completion |
| An exception | It says only use judgement |
Add the agreed route or raise an open question |
| A changed section | Old wording elsewhere contradicts it | Amend or remove the conflicting text |
| A statement of compliance | No approved source supports it | Remove it and ask governance to decide |
Also compare every change ID in the register with the change log. Each one should appear once as applied, not applied with a reason, or open. Search the document for [OPEN: and make sure each item has an owner and a review question.
Check
The draft is ready for review when
Every agreed change has a traceable section reference, every action has a role, and every uncertainty is visible rather than hidden in polished wording.
6. Package the document for governance review
Create three files or sections in your document-management process:
- Clean policy draft: formatted in the approved template, with proposed version, document owner, review date and approval fields left for the authorised process.
- Tracked or marked-up draft: shows additions, removals and replaced wording.
- Review note: lists the change IDs, source evidence, unresolved questions, operational owner and requested decision.
Use a version label such as Draft for governance review. Do not label the document approved, final or effective until the authorised approver has completed your organisation's process.
Ask reviewers specific questions. For example: Confirm the owner for C03, Confirm whether the exception in C05 requires a separate local procedure, or Confirm that section 6 replaces the previous allocation route.
When the draft does not work
Stop and return to the change owner if the model adds unsupported requirements, merges two distinct processes, or cannot trace a sentence back to the source pack. Do not repair uncertainty by making the language vaguer.
If reviewers disagree, record the disputed change ID, the competing wording and the decision needed. Send that record through your normal governance route. The model can help produce a clearer draft, but the accountable operational and governance roles decide what the policy says.
