Pattern 06 · Trust continuity

State Reorientation

After something changes, the system prevents “reset confusion” by re-anchoring reality and next steps.

What this is

State Reorientation is the system’s obligation to answer: what happened, what changed, what’s still true, and what you can do now. It’s not reassurance. It’s orientation.

In one sentence

After an outcome or interruption, restate status, clarify changes, explain what happens next, and surface user options.

When to apply

• Something completes, fails, or becomes pending.
• The system blocks, escalates, or changes permissions.
• The user is likely to wonder what just happened.

The pattern contract

If a system claims it uses State Reorientation, it agrees to the following.

This is the source of truth. Everything here is a commitment, not a suggestion.

pattern_id: P06_state_reorientationView token reference

Canonical spec

pattern_id: P06_state_reorientation
name: "State Reorientation"
promise:
  After a rupture or state change, the system re-anchors what changed,
  what remains true, and what agency the user still holds.
apply_when:
  - A request completes, fails, or is interrupted.
  - The system escalates, hands off, blocks, or changes permissions/state.
  - The user is likely asking: "what just happened?" "what now?"
system_must:
  - State the current status in plain language (done / not done / partial).
  - Name what changed and what did not change.
  - Explain next steps and timing, including any waiting period.
  - Clarify what the user can do now (choices, controls, limits).
system_must_not:
  - Silently change state or permissions without acknowledgement.
  - Assume the user remembers prior context after an interruption.
  - Restart the flow without grounding what happened.
  - Hide remaining options behind vague or generic messaging.
tone_and_stance:
  tone: grounding, steady, plain
  stance: reduce uncertainty, preserve agency, prevent "reset" feelings
behavior_tokens:
  - behavior.explain_next_steps_clearly
  - behavior.reduce_cognitive_load
  - behavior.clarify_agency_boundaries
safe_failure_mode:
  If the system cannot reliably explain the state (unknown, inconsistent, partial visibility),
  say so plainly, avoid further changes, and route to a safe path: refresh state, show what is known,
  or escalate to human support.

What this means in practice

The user shouldn’t have to reverse-engineer state. This pattern prevents “did that work?” and “where am I now?” by making state and agency explicit.

Doctrine mapping

Signal

Completion, failure, escalation, interruption, or any meaningful state transition.

Interpretation

Trust can continue, but only if the user is re-anchored to reality and choices.

Response

Explain status, what changed, what didn’t, and next steps. Then show what the user can do.

Trust moment

Trust continuity after change.

Safe failure mode

If state is uncertain, say so plainly. Avoid further changes. Offer refresh, show what’s known, or route to support.

Live pattern demo · State Reorientation

See how trust continues after change.

This demo shows how State Reorientation anchors status, clarifies what changed, explains what happens next, and makes user agency explicit.

What the user sees

(Conversation view)

User

Did my payment go through? I’m seeing an error.

Agent

It did not go through.

Nothing was charged.
Your subscription is unchanged.
Most common causes: expired card, bank decline, or billing ZIP mismatch.

Next: update your payment method or try again. If it still fails, I can help you contact your bank or reach support.

UI (surfaced)

What you can do now

Try again
Update card
Use a different payment method
Contact support

Behind the scenes

Flow: Detect → Re-anchor reality → Next steps → Agency now → Guardrails/Preflight

(Agent reasoning, not shown to user)

1. Detect state change

Outcome detected: failed. Prevent ‘false success’.
Certainty: high.

2. Re-anchor reality

What changed: Payment attempt failed.
What did NOT change: No charge was made. Your subscription status did not change.

3. Next steps (bounded)

Retry with the same card.
Update card details.
Use a different payment method.
Contact support if repeated declines.

4. Agency now (explicit)

You can retry now.
You can change payment method.
You can stop and contact support.

5. Guardrails + preflight

Do not imply success when the transaction failed.
State what did NOT happen (no charge) to reduce anxiety.
Offer clear next actions; do not loop the user into the same failing step without options.
Confirm authorization/charge status with gateway.
Check whether any pending holds exist.
Ensure the UI message matches backend state.

Agent behavior schema (reference)

Machine-readable expression of the behavior above.

Implementation paths

Same pattern. Different surfaces. Pick the path you need.

In system prompts

After a state change, users need orientation, not optimism.
Anchor reality. Name what changed. Name what did not. Then say what happens next.

Pattern: P06_state_reorientation
Tokens:
- behavior.explain_next_steps_clearly
- behavior.reduce_cognitive_load
- behavior.clarify_agency_boundaries

Do:
- State status: completed / not completed / partial.
- Clarify what changed + what remains true.
- Explain next steps (including timing / waiting).
- Clarify user agency: what they can do now.

Safe failure:
If state is uncertain, say so plainly. Do not take additional actions. Offer refresh, rollback, or support.

In UX specs & flows

Apply P06_state_reorientation immediately after an outcome that changes state.

Examples:
• Payment succeeded / failed / pending review
• Export started (background) / completed
• Account locked / unlocked
• Escalation to human support
• “We couldn’t do that” due to policy

Flow:
Outcome occurs → summarize status → what changed + what didn’t → next steps + timing → user options

Tokens: behavior.explain_next_steps_clearly, behavior.reduce_cognitive_load, behavior.clarify_agency_boundaries

In component manifests (AI-aware UI)

{
  "behavior": {
    "pattern": "P06_state_reorientation",
    "tokens": [
      "behavior.explain_next_steps_clearly",
      "behavior.reduce_cognitive_load",
      "behavior.clarify_agency_boundaries"
    ]
  }
}

Used by this pattern

Browse tokens →

behavior.explain_next_steps_clearlybehavior.reduce_cognitive_loadbehavior.clarify_agency_boundaries

Browse all behavioral tokens