Give every status a meaning your team can use

A task marked done can leave the next person with a question: done in which sense? The document may be stored, checked or available to a customer. If the label covers all three, someone has to open the work and find out.

A useful status makes a smaller, clearer promise. It tells the next person what happened, which version it happened to and what action can follow. This article offers a practical way to write that promise for one workflow.

Start with the result behind the label

We recommend these definitions.

Saved means the current version is stored in the agreed place. Evidence could be the record itself, a version number and the time of the last successful save. Saving makes no promise about whether another person has checked it.

Reviewed means a named person has checked that version against agreed criteria and recorded a decision. The decision might allow the next action or request a correction. A review record should say which version was considered and what the decision covers.

Published means the intended audience can access the intended version in the agreed destination. For a public article, opening its public page is one useful check. An internal update might instead need to appear in the team's shared workspace.

These are proposed working definitions. A team's tools may use different labels or combine steps. The important part is making the meaning explicit before people rely on it.

One example from our own journal

In our documented WGMI Journal test on 24 September 2026, a saved draft's public URL returned 404. After publication, the article appeared on its public page, in the journal, feed and sitemap. This was one test of our own publishing flow.

The recorded result gives us a specific distinction to explain: a successful save and a public result were separate events. It does not establish that every future publication will work, or that a status label alone proves a person has reviewed the content.

That is why a status definition should point to evidence of the result. A receipt from the sending tool and a page visible to the reader answer different questions. Both can be useful; the team needs to know which one supports its next decision.

Write a small status contract

For one workflow, write five short lines for each status: its name, the condition it describes, the evidence, the next owner and the action that owner can take.

Here is a proposed entry for an article awaiting a publishing decision:

Name: Reviewed. Condition: The editor checked version 6 against the agreed editorial criteria. Evidence: A review note attached to version 6, with the editor and decision recorded. Next owner: The person responsible for publication. Next action: Publish that version if the decision permits it, or return the requested changes to the writer.

This is an illustrative contract, not a record from the WGMI test. The version and role names are examples. Your own entry should use the evidence and responsibilities your team can actually maintain.

Decide what a later edit changes

Suppose the writer changes the article after that review. The old decision describes version 6. The team still needs a rule for the changed version.

One possible rule is to return any changed article to review. Another is to allow defined corrections while requiring a new decision for changes to meaning. Either way, record the boundary and its owner. Leaving it implicit makes the next person interpret the old label.

Read the label from the next person's position

A useful final check is whether someone can identify the evidence and take the next action without asking the previous person what the status meant. If they cannot, the definition may need a clearer result, version reference or owner.

The output can be a short shared note. It does not require a new platform or a redesigned board before the team can use it.

Choose one status your team uses and write down exactly what it proves.

Prepared for WGMI with AI assistance.