One idea, three useful forms

Choose the form around the reader's next action.

Some information needs to be understood. Some needs to be remembered while your hands are busy. Some needs to tell you which way to go.

The same paragraph rarely does all three equally well.

Three forms serve different purposes: a source, saved-copy and access checklist helps remember; an unavailable-source decision leaves the task unresolved; an explanation says a failed fetch cannot establish what changed.

We've been building a small source-checking guide. Let's take one idea from it: a failed check leaves the source's current state unknown. Here are three ways to carry that idea. These are worked examples you can adapt, not reports of three completed user tests.

When someone needs to remember

Before closing a source check:

Name the source and the saved version used for comparison.
Record the material you actually inspected.
Describe a meaningful difference, or record that none was found in the checked material.
If access or extraction failed, leave the result unresolved.
Save the next action with the result.

A checklist helps with omissions. It is compact because it assumes you already understand why the items matter. Give this list to a newcomer without the surrounding explanation and “meaningful difference” may still leave them guessing.

When someone needs to choose

Can you inspect the relevant source material?

If no, record what is unavailable and keep the check unresolved. If yes, compare it with the saved version. If the meaning changed, explain the affected conclusion and propose a revision. If the checked meaning did not change, record that limited result.

This is a branching instruction. Its value comes from making different conditions lead to different actions. It needs conditions a person can actually distinguish. “If the source is good, continue” wouldn't help much; good in what sense?

When someone needs to understand

Why a failed check stays open:

You can only conclude that the relevant content is unchanged after inspecting and comparing it. A failed attempt gives you information about the attempt—perhaps a page was unavailable—but doesn't tell you what the page currently says. Leaving the result unresolved preserves that distinction for the next person.

The paragraph explains the reason. It costs more attention in the middle of repetitive work, but it gives the reader a principle they can apply when an unfamiliar exception appears.

Our own procedure uses these forms together: ordered actions for the usual path, a table for failures and decisions, and explanation around limits. That structure reflects the work the procedure needs to support.

Here's how I'd choose. If a person keeps forgetting a known step, start with a checklist. If they keep taking the wrong branch, make the decision visible. If they don't understand why the step matters, explain the relationship.

You may need more than one form, but give each a distinct job. Three versions that merely repeat the same words create more reading without more help.

Take the point your reader is most likely to miss. Change its form once. Then check whether the new version still carries the condition that made the original statement true.