Search

Search components, tokens, patterns, architecture

Patterns

Provenance

Every recommendation carries its sources: a “based on…” line plus the signals the engine actually used. Provenance is rendered inside the surface it justifies — trust is built contextually, not in a help center.

Rules

  1. 01“Recommendations based on: …” lists the signal categories used.
  2. 02signalsUsed[] comes from the engine — the UI never invents sources.
  3. 03Missing inputs are listed separately (max 3) so provenance stays honest about gaps.

Examples

FuelingCard

“Based on: training load · sleep · cycle context” — and if sleep was assumed, that appears under assumptions instead.

Anti-patterns

What breaks this pattern

  • A static boilerplate source line that doesn't change with the data.
  • Citing cycle phase as a source when pattern confidence is low.

Do

  • ·Render sources from engine output
  • ·Keep the line scannable — categories, not raw fields

Don't

  • ·Fake specificity
  • ·Bury provenance in settings