Pattern

Publish / irreversible

Go live

Required if product publishesSource pattern
ContractPublish / irreversible
Job
Go live
Requirement
must specify if product publishes
States / rules
Confirm; success = done; failure = retry
Specified means
Publish ≠ cheer
Hardest context
Publish + nav open
Example

Stack: publish > nav

Counter-example

Emerald “Ready, set, publish” as system voice if off-register

Flow

Trigger: A product moves work from draft/private/reversible state into a live, external, or otherwise consequential state.

  1. Show the current state and the destination state.Show the current state and the destination state.
  2. Run any required preflight checks before the final commitment.Run any required preflight checks before the final commitment.
  3. Summarize impact in product language, including audience or downstream consequences where relevant.Summarize impact in product language, including audience or downstream consequences where relevant.
  4. Use a final action that names the transition, such as Publish.Use a final action that names the transition, such as Publish.
  5. Show progress without allowing accidental duplicate commitment.Show progress without allowing accidental duplicate commitment.
  6. Land in a final state that confirms what is live and exposes any legitimate follow-up or recovery path.Land in a final state that confirms what is live and exposes any legitimate follow-up or recovery path.

Typical Building Blocks composition

Composition below is baseline guidance for the pattern; it does not rename or add source checklist rows.

ButtonDialog when consequence warrants itProgress / loadingStatus / banner

Flow rules

  • The final verb names the transition.
  • Do not hide blocking preflight failures behind a generic error.
  • If the action cannot be reversed, say so before commitment rather than after.

Responsive behavior

Keep impact and the final action in the same reading context at small widths; do not hide critical consequences in hover or secondary chrome.

Accessibility is tested across the sequence.

Keyboard order, focus movement, state announcements, touch targets, cancellation, and recovery must be verified for the whole flow—not only for each participating component in isolation.

Recovery is part of the pattern.

A complete pattern defines what the user sees when the happy path breaks, what is preserved, where focus goes, and how the user safely resumes or exits.

Catalog connection

A product Catalog can show this pattern only when the product actually implements the flow. If it is absent, keep the section honestly Not yet rather than mounting a fictional working pattern.