Trust tokens

Trust tokens are intended to provide a focused subset of tokens used to communicate confidence, risk, and user assurance in sensitive or high-impact flows.

Why trust tokens?

Users trust that certain interface components can be relied upon to communicate important risks, confidence levels, provenance information they can trust, and the effective consequences of any choices or actions they make.

Trust tokens attempt to address the question of how such components can be quickly identified and reliably distinguished from other components in the context of AI-generated user interfaces.

Setting aside specific dedicated tokens for use by critical components helps provide these assurances.

Proposed semantic token groups

1) Risk tokens

Used when users need to understand potential harm or irreversibility.

• trust.risk.low.*
• trust.risk.medium.*
• trust.risk.high.*
• trust.risk.critical.*

Example suffixes:

• .bg
• .fg
• .border
• .icon

2) Confidence tokens

Used when the system communicates certainty/uncertainty in outputs.

• trust.confidence.low.*
• trust.confidence.medium.*
• trust.confidence.high.*

These should be visually distinct from risk states, even if both use warm/cool palettes.

3) Verification tokens

Used for identity/state provenance and attestation.

• trust.verification.verified.*
• trust.verification.unverified.*
• trust.verification.expired.*
• trust.verification.revoked.*

4) Action-safety tokens

Used to frame sensitive actions in confirmations and review steps.

• trust.action.requires-confirmation.*
• trust.action.destructive.*
• trust.action.data-sensitive.*

Example tokens (illustrative)

{
  "trust.risk.high.bg": "{colors.orange.50}",
  "trust.risk.high.fg": "{colors.orange.900}",
  "trust.risk.high.border": "{colors.orange.400}",
  "trust.risk.high.icon": "{colors.orange.600}",

  "trust.verification.verified.bg": "{colors.green.50}",
  "trust.verification.verified.fg": "{colors.green.900}",
  "trust.verification.verified.icon": "{colors.green.600}",

  "trust.confidence.low.bg": "{colors.slate.100}",
  "trust.confidence.low.fg": "{colors.slate.800}",
  "trust.confidence.low.border": "{colors.slate.300}",
}

Example usage patterns

Status chips

• verified identity
• unverified source
• model confidence: high/medium/low

Banners and callouts

• "This action cannot be undone"
• "This answer is generated and may be incomplete"
• "Document signature expired"

Confirmation dialogs

Before destructive actions:

• apply trust.action.destructive.*
• include explicit intent + scope
• require clear primary/secondary button distinction

Guidelines for component authors

1. Never map trust semantics directly to generic success/warning/error without intent.
2. Prefer tokenized semantics over ad-hoc color decisions in component code.
3. Pair color with iconography and copy for accessibility and clarity.
4. Treat trust tokens as policy surface, not purely visual decoration.