How English Works | The Procedure

A policy can be perfectly clear and still leave a person standing in front of the screen asking:

What do I do first?

The policy says assessment records must be stored in the approved system.

Fine.

Which system?

Who uploads them?

When?

What happens if the file contains an error?

What record proves the upload happened?

Who handles an exception?

This is where the procedure begins.

A procedure is English arranged in the order reality needs.

It takes a rule, goal or process and converts it into a route a competent reader can execute.

Quick Read

One-sentence answer: a procedure works when it tells the right person what to do, in what order, under which conditions, using which inputs, producing which records, and what to do when the normal sequence cannot continue.

Current GOV.UK standard-operating-procedure guidance describes familiar structural elements: document control, title and version information, purpose, scope, responsibilities and step-by-step task descriptions. It also recommends explaining jargon and acronyms. A 2026 Registers of Scotland procedure similarly uses purpose and scope, process stages, information requirements, confidentiality, protection, roles and responsibilities, approval and review.

Those examples reveal the procedure’s main architecture:

• purpose: what outcome the procedure exists to produce;
• scope: when and to whom the procedure applies;
• prerequisites: what must already be true before Step 1;
• roles: who performs, checks or approves;
• sequence: what happens first, next and last;
• decision points: what changes when conditions differ;
• records: what evidence of completion must be created;
• exceptions and recovery: what happens when the normal route fails;
• document control: which version is current.

The Procedure Is Not the Policy

Policy:

All verified assessment results must be stored in the approved central system.

Procedure:

1. Open the central assessment system.
2. Select the current class and assessment period.
3. Upload the verified result file.
4. Review the import summary.
5. Correct rejected entries and repeat the upload.
6. Save the completion receipt in the class record.

Policy defines the required state.

Procedure defines the route.

policy = what must be true
procedure = how the organisation makes it true repeatedly

The Procedure Is Not the Checklist

A checklist can confirm that important steps or conditions were not forgotten.

A procedure usually carries more explanatory structure.

Checklist:

• File verified
• Correct class selected
• Upload completed
• Receipt saved

Procedure:

If the import summary shows rejected entries, do not mark the upload complete. Correct the listed rows and repeat Step 3.

The checklist protects memory.

The procedure carries sequence, conditions and recovery.

Purpose Should Describe the Outcome, Not the Document

Weak:

This procedure explains the procedure for uploading results.

Stronger:

This procedure ensures verified assessment results are uploaded to the central system, rejected records are corrected and a completion record is retained.

The stronger version tells the reader what successful completion looks like.

Scope Tells the Reader When This Route Applies

A procedure without scope can be followed in the wrong situation.

Useful scope language can say:

This procedure applies to verified internal assessment results for Primary and Secondary classes. It does not apply to external examination results received directly from awarding bodies.

The reader now knows both the included and excluded worlds.

GOV.UK SOP guidance explicitly recommends stating scope and, where useful, what is out of scope.

A correct procedure used in the wrong context is still an operational error.

Prerequisites Prevent Step 1 from Starting Too Early

Some procedures quietly assume the reader has already:

• the right access;
• the correct file;
• approval;
• required equipment;
• completed training;
• a verified input.

If these conditions are not stated, the procedure may fail before the first numbered step.

Example:

Before starting, confirm that the result file has been independently checked and that you have upload permission for the selected class.

Prerequisites are the hidden Step 0 made visible.

Responsibilities Should Follow the Work

Current SOP guidance includes a responsibilities section because procedures often involve several roles.

For example:

• Teacher verifies marks.
• Level coordinator approves the final file.
• Administrator uploads the file.
• System owner resolves access problems.

Without role clarity, a procedure can contain all the right steps while nobody knows which steps belong to them.

sequence without ownership is only a description of what somebody should do.

Each Step Should Begin with an Observable Verb

Weak step:

Consider the file.

What action proves completion?

Stronger verbs include:

• open;
• select;
• compare;
• enter;
• upload;
• verify;
• record;
• send;
• approve;
• archive.

A good procedural verb reduces interpretation about what the reader should physically or cognitively do next.

One Step Should Contain One Main State Change

Weak:

Open the file, check the names, fix any errors, upload it, review the summary and email the coordinator if anything looks wrong.

The reader must hold six actions in working memory.

Better:

1. Open the verified result file.
2. Confirm the class and student names.
3. Correct any identity errors before upload.
4. Upload the file.
5. Review the import summary.
6. If errors remain, follow the rejection-recovery steps.

The sequence is longer on the page and shorter in the reader’s head.

Good procedures spend more space to demand less working memory.

Decision Points Need Explicit Branches

Reality does not always proceed straight downward from Step 1 to Step 9.

Procedure:

If the import summary shows zero rejected rows, continue to Step 7.
If one or more rows are rejected, open the error report and follow Steps 5A–5C.

The branch names the condition and the route.

Weak branch:

If there is a problem, deal with it appropriately.

Appropriately is not a procedure.

Decision language should tell the reader what observable condition changes the next step.

Records Turn Completed Work into Inspectable Work

A procedure may end successfully while leaving no evidence that it happened.

Useful completion records include:

• receipt number;
• timestamp;
• signed form;
• system status;
• completed checklist;
• approval record;
• exception log.

Example:

After a successful upload, save the system receipt in the class record and record the upload date in the assessment tracker.

The procedure now produces both an outcome and a trace.

Recovery Steps Matter More Than Perfect-Path Optimism

Many weak procedures describe only the world in which everything works.

Real users meet:

• missing fields;
• rejected records;
• unavailable systems;
• incorrect permissions;
• duplicate entries;
• unclear ownership.

A mature procedure describes the expected abnormal routes.

If the system is unavailable, do not use an unapproved local storage location. Save the verified file in the designated temporary queue and retry when service is restored.

Recovery is not an afterthought. It is part of the executable model.

Document Control Tells the Reader Which Route Is Current

GOV.UK SOP guidance recommends document-control information such as a short title or ID, revision number and date, and often approval and version information.

This matters because procedures change more often than policies.

A new system screen.

A different form.

A changed approval threshold.

A new responsible role.

Useful control fields include:

• Procedure ID;
• Version;
• Owner;
• Approved by;
• Effective date;
• Next review;
• Supersedes;
• Related policy.

A procedure is safe only if the reader can tell whether it is still the procedure.

Version Changes Should Explain What Changed

Version 4.2 is less useful when nobody knows why it replaced 4.1.

A compact change note can say:

v4.2 — Updated Steps 5–7 to reflect the new import-summary screen; no change to approval requirements.

This tells experienced users whether they need to relearn the whole route or only one section.

It also protects policy stability by showing that the procedure changed operationally while the governing rule remained intact.

Procedures Should Be Tested by Someone Who Did Not Write Them

Writers carry invisible knowledge.

They know which button to click.

They know what “the tracker” refers to.

They know which exception is obvious.

A new reader does not.

The strongest procedure test is therefore practical:

Can a competent person who was not in the design conversation complete the task correctly using only the procedure and normal authorised resources?

Observe where they hesitate.

Every hesitation may reveal hidden context, ambiguous wording or missing branch logic.

Screenshots Can Help and Still Become Stale

A screenshot can make a complex interface step instantly obvious.

It can also become wrong after a small visual redesign.

Good procedures avoid making screenshots the only carrier of meaning.

Use text such as:

Select “Review import” from the action menu.

Then use the screenshot as support where useful.

This preserves some resilience when the button moves but the labelled action remains the same.

Visual aid should support the instruction, not become the instruction’s only surviving language.

Handoffs Are Where Procedures Often Break

One person completes Step 4.

Another person must begin Step 5.

The procedure needs to define the handoff.

After approval, the Level Coordinator sends the verified file to the Administrator through the approved workspace and records the handoff date in the tracker.

Without explicit handoff language, each role may believe the other role owns the transition.

The task stalls between perfectly written sections.

Procedure quality is often weakest at the boundary between people, not inside the steps assigned to one person.

Escalation Is a Procedure for When the Procedure Stops Being Enough

Some cases do not fit any normal branch.

Useful escalation language identifies:

• the trigger;
• the receiving role;
• what information must be supplied;
• what the original operator should stop doing;
• how the case is recorded.

Example:

If the same record is rejected after two verified correction attempts, stop the upload process and send the error report and source file to the System Owner. Record the case as “Escalated — technical review.”

Escalation prevents improvisation from pretending to be procedure.

A Procedure Can Become Too Rigid

Procedures create consistency.

They can also create tunnel vision.

If a procedure is followed even when observable conditions show that the situation has left its intended scope, compliance can become mechanical rather than intelligent.

This is why scope, exceptions and escalation matter.

A good procedure says both:

Follow this route under these conditions.
Stop and escalate when these conditions no longer hold.

Primary School: Put the Instructions in an Order That Works

Give children five mixed steps for borrowing a library book.

• Return the book by the due date.
• Choose a book.
• Take the book to the borrowing desk.
• Check that the book is suitable for borrowing.
• Keep the receipt.

Ask them to put the steps in a workable order.

Then ask:

What would happen if Step 4 came after borrowing?

The child learns that procedural order is causal, not decorative.

Lower Secondary: Add the Missing Branch

Give students a straight-line procedure that assumes success.

Then introduce:

The system rejects the file.

Ask students to add:

• the condition;
• the recovery steps;
• the point where the normal route resumes;
• the escalation point if recovery fails.

This teaches procedures as branching systems rather than numbered paragraphs.

Upper Secondary: Audit Executability

• Is the purpose outcome clear?
• Is scope explicit?
• Are prerequisites visible before Step 1?
• Does every step use an observable verb?
• Is each main action small enough to execute reliably?
• Are branches based on observable conditions?
• Do handoffs identify sender and receiver?
• Are completion records defined?
• Do recovery and escalation routes exist?
• Can I identify the current approved version?

This turns procedure reading into a lesson in sequencing, conditional language, human factors and operational design.

Ten Failure Modes of Procedure English

1. Scope failure. A valid procedure is followed in a situation it was never designed for.
2. Hidden prerequisites. Step 1 assumes access, approval or inputs that were never stated.
3. Ownerless steps. The sequence is clear but nobody knows which role performs each part.
4. Multi-action steps. One sentence forces the reader to remember several state changes at once.
5. Vague verbs. “Handle,” “consider” or “deal with” replaces an observable action.
6. Branch ambiguity. “If there is a problem, act appropriately” leaves the hardest cases undefined.
7. Perfect-path bias. The procedure describes success but not common errors, unavailability or recovery.
8. Handoff gap. Two roles each perform their own steps but the transition between them is unspecified.
9. Version staleness. Old screenshots or instructions remain in circulation after the process changes.
10. Mechanical compliance. Readers keep following the route after the case has moved outside its scope because no stop or escalation condition exists.

How to Write a Better Procedure

Start from the desired completed state and work backwards.

1. What outcome defines success?
2. When does this procedure apply?
3. What must already be true?
4. Which roles participate?
5. What is the smallest reliable sequence of actions?
6. Where do decisions branch?
7. What records prove completion?
8. What common failures require recovery?
9. When should the operator stop and escalate?
10. How will readers know this is the current version?

Write steps with observable verbs. Keep one main state change per step. Use conditions that readers can actually test. Define handoffs. Link the governing policy. Test the procedure with a competent person who did not write it.

Then perform the cold-start test:

If a trained person begins this task six months from now with no access to the original author, can they complete the work correctly, recognise when the normal path has failed, and leave an auditable record of what happened?

The Deeper Idea: Procedure Turns Language into Repeatable Motion

Policies can remain abstract.

Procedures touch time.

First.

Next.

If.

Then.

Until.

Record.

Escalate.

Complete.

These are words arranged to shape a sequence of human actions.

policy intention → procedural sequence → human action → recorded outcome

That is why procedure writing belongs to how English works.

It is language engineered so the same important task can be carried out reliably by different people at different times.

Reader Checklist

• What successful outcome does this procedure produce?
• When does it apply?
• What must be ready before Step 1?
• Who performs each part?
• Are steps observable and ordered?
• Where does the route branch?
• What happens when the normal path fails?
• What record proves completion?
• When should a case be escalated?
• Is this the current approved version?

Related eduKateSG Reading

• How English Works | The Policy
• How English Works | The Memo
• How English Works | The Brief
• How English Works | The Checklist
• How English Works | The Error Message

Research and Further Reading

• GOV.UK — Guidelines for Standard Operating Procedures
• Registers of Scotland — Whistleblowing and Raising a Concern Procedure

Final idea: a procedure is good when a person can follow the words into action, recognise when reality has left the normal route, and still know what to do next.