Lifecycle stages from create to archive need explicit names

What it is

A piece of content passes through stages in the product: draft, published, archived, sometimes in-review or expired. Each stage needs a name, a visible mark, and a statement of what can be done there (edit, appear in search, share). Without an explicit state machine, people guess the stage from folder location or whether the row looks gray. This defines which states exist. Whether archive equals delete, whether auto-archive vanishes without notice, and how idle items are cleaned all assume those names already exist.

Why it happens

What people do to an object depends on “what it counts as now.” Drafts can be rewritten; published changes need to notify readers; archived items should leave the daily list but remain. If that lives only as a backend enum and one chrome draws every object, people edit a published piece as a draft, or share an archive as a live file. Explicit states turn stages into learnable words and constrain entries: Publish appears on drafts, Restore on archives. States must be exclusive and explainable: one object cannot be draft and published without a version. A hidden state (“soft-deleted but still in the list”) unhooks stage from visibility; people act on what they see and take consequences from what it actually is.

Studying it

Ask what stage an object is in and what they can do. Compare no mark, color only, name plus allowed acts. Then walk a draft to archive and see whether each step has a matching act.

Independent variables: whether the state name sits beside the object, whether allowed acts differ by state, whether illegal acts are hidden or fail after tap. Dependent variables: stage judgment accuracy, irreversible acts in the wrong stage, steps to walk the full lifecycle.

A lab that draws the state machine on the worksheet lets people answer from the diagram. Read it off the object. Do not mix permission roles: a viewer facing published and an author facing draft are two dimensions.

Where it stops holding

One-shot chat messages have no archive stage; sent / unsent may be enough. Heavy workflows (contract signing) have more stages, but each name still has to be readable on the object, not only in an admin console. A personal doodle can simply exist; forcing publish/archive is burden. When a peer system has no matching stage, mark “peer state unknown” rather than mapping to a fake published.

Applying it

• Write exclusive stages per object type, and show the current name beside the object.
• List allowed acts per stage. Illegal entries do not appear, rather than failing after a tap.
• Record stage changes in activity, so “when did this leave draft for published” has an answer.
• Verify: without opening settings, ask what this is now, whether it can be edited, whether it appears in the main list. All three answers must match the machine. Walk a draft to archive; no unnamed intermediate state should appear.

Related

• Within the group: H8.14.2 Archive is retrievable recovery, not deletion · H8.14.3 Auto-archive rules must be announced before items vanish · H8.14.4 Inactive cleanup balances storage cost against later retrieval
• Adjacent: H8.01 CRUD Operations · H3.08 Soft Delete and Trash · H8.09 Edit Mode vs View Mode
• Search terms: content lifecycle · draft published archived · state machine