Shorten a Procedure with AI: Find the Missing Branches

The sentence that loses the return journey

A poster has editor-approved text, but two comments are still open. The shortened instruction says to get approval, check the poster and save it for printing. Does the earlier approval let the colleague continue?

The source says to return the file to the editor, wait for the comments to be resolved and get text approval again. A shorter sentence has removed the route back. That is the failure to look for when AI condenses a procedure: the missing condition can matter more than the words saved.

This article uses a complete fictional internal-poster procedure. The review exercise below follows eight situations, separates ten source requirements and adds back four repair clauses. It compares instructions; it cannot approve a real process or establish that anybody tested a printed QR code.

Use this method for routine, low-stakes instructions. Safety-critical, regulated or otherwise consequential procedures need their specialist review process.

Keep the complete source in view

The intended output is a working instruction, so a reader must be able to choose the right action. An orientation summary can instead point to the full procedure, provided it is clearly labelled as a summary.

Fictional source procedure

• S1. Confirm that the content editor has approved the poster's text before preparing a print proof.

• S2. If any comments remain unresolved, return the file to the editor. Resume proof preparation only after the editor resolves the comments and approves the text again.

• S3. Prepare one print proof. If the poster contains a QR code, test that code on the print proof. If the destination is wrong, correct the code and prepare and test a new proof.

• S4. After the proof has been checked, save the checked file in the ready-to-print folder. Never put an unchecked file in that folder. S1–S4 are the complete source for this exercise, preserved from the recovered draft. The operational roles, rules and test situations are invented; they are not a Google-approved poster process.

Try the shorter draft against an exception

This version is more plausible than “Get approval, check the poster and save it for printing.” It retains a proof and a QR check, but still loses important meaning.

Deliberately flawed shortened draft

• T1. Confirm that the content editor has approved the poster's text before preparing a print proof.

• T2. Prepare and check one print proof. If the poster contains a QR code, check its destination. If the destination is wrong, correct the code.

• T3. Save the file for printing. Start with “Earlier approval, unresolved comments”. Compare what the source requires with the words available in the shorter draft. Then restore the approval loop and compare again. Next, try “QR corrected, fresh proof not tested”. The correction is present in T2; the return to a new proof and test is missing.

The exercise compares conditional instructions. Marking a clause as present never marks a physical task complete. Work through it in text; no software is required.

Eight situations to compare

For each situation, write the source action, what T1–T3 actually requires and the repair needed. Cover the suggested source action before deciding for yourself.

1. Approved text, no comments, no QR: prepare and check the proof, then save the checked file in ready-to-print.
2. Text has no approval: do not prepare the proof; obtain editor approval first.
3. Earlier approval, comments still open: return to the editor; wait for resolution and renewed text approval before resuming.
4. QR present, physical proof not checked: test the QR on that print proof before filing it.
5. QR reaches the wrong destination: correct the code, create a new proof and test again.
6. Digital QR checked but no physical proof tested: the required print-proof check is still outstanding.
7. QR corrected after a failed proof, fresh proof not tested: the correction does not inherit the previous check; prepare and test the new proof.
8. No QR, but the proof remains unchecked: keep it out of ready-to-print until checked.

These are expected decisions from S1–S4, not observations from a real printing job.

Ten requirements to locate

The review key for the deliberately flawed draft is:

• Preserved: editor text approval before proof preparation; preparation of a print proof; a QR check conditional on a QR being present; correction of a wrong QR destination.
• Missing: returning unresolved comments to the editor; resuming only after resolution and renewed approval; making a new proof after a QR correction; testing that new proof.
• Unclear: testing the QR specifically on the physical proof; admitting only the current checked file to ready-to-print.

Record the exact T sentence beside each judgement. If you disagree with an “unclear” result, state what a colleague could reasonably infer and what the wording guarantees. That discussion is more useful than treating the count as a grade.

A repaired working draft

1. Obtain the content editor’s approval of the poster text. If comments remain unresolved, return the file to the editor and resume only after the comments are resolved and the editor approves the text again.
2. Prepare and check a print proof. If it contains a QR code, test the code on that physical proof. If the destination is wrong, correct the code, prepare a new proof and test again.
3. Save the checked file in the ready-to-print folder only after the current proof has passed the required checks. Never place an unchecked file there.

This repair restores the approval loop, physical-proof context, correction-and-retest loop and checked-file gate. Compare all eight situations again before accepting it as a faithful condensed instruction.

Review the requirement, not the general impression

Give each source obligation its own entry: actor, prerequisite, condition, required action, order, return point and destination. Record the exact source location, shortened location and a reason for calling the meaning preserved, missing or unclear.

In this baseline, four of the ten mapped requirements are preserved, four are missing and two are unclear. That breakdown describes the fictional text. It is not a reliability percentage, a learner grade or evidence that the procedure works in practice.

The unresolved-comment branch contains two obligations: return the file to the editor, then resume only after resolution and renewed approval. Adding “ask the editor” alone leaves the return condition incomplete. The wrong-QR branch similarly requires both a correction and a new proof-and-test cycle.

Keep “unclear” distinct from “missing”. T2 says to check a QR destination but does not explicitly attach that check to the physical print proof. It also says to check a proof before T3, yet fails to protect filing after a later correction. A reader might do the right thing, but the wording does not reliably carry the source gate.

Google’s sentence-structure guidance recommends placing conditions before instructions. That supports an editorial pattern: state when the branch applies before the action the reader must take. Our ten-requirement mapping is an original application of that idea.

Retest the return path after a correction

A digital QR code can lead to the intended destination while the print-proof test remains undone. Changing a code after a failed proof also creates a new version that has not inherited the old proof’s result.

For a real-world rehearsal of this low-stakes fictional example, print the current approved file and test the QR code on that physical proof. Compare the observed destination with the intended destination. If it is wrong, correct the code, make a new print proof and test again. Repeat if necessary. Keep the unchecked file out of ready-to-print.

A useful record would identify the file/version, physical proof, intended and observed destinations, tester, date/time, result and correction. Link each changed file to its fresh proof and observation. These record fields are our suggested review aids; they are not extra requirements claimed to come from Google or the recovered source.

Label every real result in your copyable plan “not run / not recorded here” until a person performs and records the relevant check. A restored clause, selected scenario or checked box is a statement about the exercise, never evidence that a physical check took place.

Shorten the wording without redesigning the process

Remove repeated background and put long explanations in a clear reference. Keep each condition attached to its action and return point. Where the source is ambiguous, ask the procedure owner rather than inventing a neat replacement rule.

Google’s procedure guidance describes numbered sequences, generally one action per step and clear labelling of optional steps. Its prescriptive-writing guidance distinguishes requirements, recommendations and optional actions. Those are writing principles; neither source validates this procedure, the tool or an AI model’s ability to preserve meaning.

A bounded AI request could be: “Propose a shorter version of this procedure. Preserve every prerequisite, actor, required action, exception and ordering constraint. Map each source requirement to a proposed step. List anything unclear or omitted separately. Do not invent a replacement rule.” Check the returned mapping against the source, just as you check the prose.

Hand over a reversible change

Keep the source, exact proposed rewrite, requirement map and retest observations together. Review the ordinary no-QR case, the approval stop, unresolved comments, the working physical code, the wrong destination, the digital-only check, a corrected but untested code and an unchecked no-QR proof. One ordinary path cannot establish that an exception survived.

Use the organisation’s existing procedure-owner review before replacing a real instruction. Preserve the current version until that review is complete. If a short working instruction cannot retain the necessary meaning, use a labelled orientation summary linked to the full procedure.

For related reading, Better AI Instructions for Small-Business Work helps frame a bounded drafting task. Plan an AI Workshop Your Team Can Use the Next Day helps turn the comparison into useful team practice.

Practise with your team

Practise a procedure review in an AI workshop

Primary sources checked 4 October 2026

• Google developer documentation: Sentence structure
• Google developer documentation: Procedures
• Google developer documentation: Prescriptive documentation