Dashboard

Prompt AI to Turn a Policy Into a Checklist

A single-pass checklist looks competent and quietly drops requirements. Two passes let you check coverage, which is the only thing that makes the output trustworthy.

Cecilia Iona
Cecilia Iona
Senior Editor, AI & Product
19 October 20261 min read

To turn a policy into a checklist with AI, do it in two passes. First make the model extract every obligation verbatim with the clause it came from, and only then convert those extracts into actions. Asking for the checklist in one step produces something readable that quietly drops requirements and invents others, and because the output looks like a competent checklist, nobody notices what is missing.

The two-pass method exists for one reason: it lets you check coverage. A single-pass checklist cannot be verified against the source without redoing the work by hand.

Pass one: extract, do not summarise

The first prompt asks for no interpretation at all.

text
Below is a policy document. Extract every statement that creates an
obligation, a prohibition, or a condition someone must meet.

For each one, output a row with:
- the obligation, quoted exactly from the source
- the section or clause number it appears in
- who it applies to, only if the text says so
- any deadline or frequency, only if the text says so

Do not paraphrase. Do not merge similar items. Do not add anything
that is not in the text. If a sentence creates two obligations,
give it two rows.

Policy:
[paste]

The constraints are doing specific jobs. "Quoted exactly" means you can search the source for any row and confirm it exists. "Do not merge similar items" prevents two near-identical obligations that apply to different roles from collapsing into one. "Only if the text says so" stops the model filling gaps with plausible defaults, which is the single most common way an invented requirement enters a checklist.

Expect more rows than you want. A ten-page policy might yield sixty. That is correct at this stage, and the consolidation happens in pass two where you can see what is being combined.

The coverage check

Before going further, spend two minutes on the check that makes the whole method worthwhile.

Ask: which sections of the source produced no rows? Then look at those sections yourself. Usually they are definitions, scope statements or boilerplate, and the absence is right. Occasionally one is a section full of obligations phrased in a way the model did not recognise, often because it uses "is expected to" or "should ordinarily" rather than "must".

A second useful prompt here:

text
List every section heading in the policy. For each, say how many
obligations you extracted from it. Mark any section where you
extracted none.

That is a cheap audit of the model's own work and it catches the one failure that matters, which is silent omission. It is the same principle as getting the model to check its own work, applied to coverage rather than correctness.

Pass two: convert to actions

Now, and only now, the checklist. Feed back the extracted rows, not the original policy.

text
Here are extracted obligations from our policy. Convert them into a
checklist for [role] to use [when].

Rules:
- Each item must be a single action someone can do and then tick.
- Start each item with a verb.
- Keep the clause reference on each item.
- If an obligation is not actionable by this role, put it in a
  separate list called "Not this role".
- If two obligations always happen together, combine them and cite
  both clauses.
- Do not add items that do not trace to a row above.

The clause reference is the part people leave out and later wish they had. Six months on, somebody asks why a step exists, and without the reference the honest answer is that nobody remembers. With it, the answer takes ten seconds.

The "Not this role" list is also load-bearing. A policy covers several audiences, and a checklist that silently drops the finance team's obligations because you asked for the warehouse checklist leaves you believing the policy is covered when a third of it is not.

Both passes lean on the same discipline as our framework for prompts that hold up: say what you want excluded, not only what you want included.

What to fix by hand

Two things reliably need a person.

Ordering. The model will output items in source order, which is almost never working order. Rearranging into the sequence someone actually performs is a five-minute job that decides whether the checklist gets used.

Conditional items. "If the shipment contains hazardous goods, complete form B" is an obligation, but as a flat checkbox it makes every user stop and think about whether it applies. Pull conditionals into a clearly marked branch at the end, or split into two checklists, and the main list becomes something a person can move through without deciding anything.

If your organisation has its own terms for things, feed them in rather than correcting the output afterwards, using the approach in prompting AI to use your own terminology. A checklist that calls it a "goods receipt note" when everyone says "GRN" reads as something imported from outside.

Keeping it in step with the policy

The failure mode six months out is a checklist that no longer matches an amended policy. Two habits prevent it:

Keep the clause references. When the policy is revised, you can find every affected checklist item by searching for the clause number instead of re-reading everything.

Store the pass-one extraction, not just the final checklist. When the policy changes, re-run pass one on the new version and diff the two extractions. That tells you exactly which obligations were added, removed or reworded, which is far faster and far more reliable than regenerating the checklist and comparing the results. It is also the point of difference from writing an SOP from scratch with AI: here the source document is authoritative and the checklist has to stay traceable to it.

For a checklist that will be used by someone outside your team, the structural advice in writing a client onboarding checklist with AI applies on top.

FAQ

Can I just paste the policy and ask for a checklist?

You can, and for a one-page policy with ten obvious rules it is fine. For anything longer, the single-pass output cannot be verified against the source without doing the extraction by hand anyway, which is the work you were trying to avoid.

What if the policy is too long for one prompt?

Run pass one section by section and concatenate the rows. Extraction is the step that tolerates chunking well, because each row is independent. Do pass two on the combined rows.

How do I know it did not invent an obligation?

Every pass-one row is a verbatim quote with a clause reference, so search the source for it. Rows that do not appear in the document are the ones to delete, and they are rare once the prompt forbids paraphrase.

Should the checklist include the policy's rationale?

Keep rationale out of the checklist items and put the clause reference there instead. Someone working through a checklist wants to know what to do. Someone questioning an item wants the source, and the reference takes them to it.

How did this land?

About the author

Cecilia Iona
Cecilia Iona

Senior Editor, AI & Product

Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.

Share

Get the next post in your inbox

One email a month. Product updates, engineering posts, and the best of Built with Swarmz.

I agree to receive emails about AI building tips and Swarmz product news. Unsubscribe any time.