When a user approves a deploy, selects a plan, or confirms a purchase, the interactive UI should become a permanent record of what happened. Without this, scrolling back shows a live button for a decision that was already made, confusing at best, dangerous at worst if someone clicks it again.

A receipt state replaces the interactive controls with a confirmation of the choice. It's proof of the decision, visible to both the user and the assistant. This is the natural counterpart to decision actions: the action captures the choice, the receipt displays it.

Why Receipts Matter

Without receipts, decisions vanish into the conversation history.

The receipt shows what was chosen. The follow-up confirms the outcome and offers an undo path.

Writing Receipt Copy

Receipt copy describes a past decision.

The Decision Label

Decision labels use past tense: they describe what the user decided.

The Action Description

Action descriptions stay in imperative form: they describe the request, not the outcome.

The pattern is: [Past-tense decision] [Imperative action]

• "Approved: Back up database" (the request to back up was approved)
• "Denied: Delete all project files" (the request to delete was denied)
• "Selected: Merge duplicates" (the option to merge was selected)

Components with Receipt States

Pass a choice prop to switch any of these components into receipt mode:

Message Draft uses a similar pattern with an outcome prop ("sent" or "cancelled") that renders a one-line confirmation receipt after a message is sent or cancelled.

When to Use Receipts

Use receipts for decisions that:

• Change state (approvals, deletions, submissions)
• Can't be easily undone
• The user or assistant might need to reference later

Skip receipts for reversible controls like:

• Sorting or filtering data
• Adjusting parameters
• Navigating between views

The assistant's follow-up should reference the receipt and, when appropriate, offer a way to undo or modify the decision.