When a chat-native comparison table surfaces a simple, running “evidence ledger” per shortlisted item (e.g., last spec verification date, review recency, known data gaps, and whether any merchant-provided fields recently changed), does this longitudinal transparency improve calibrated decision confidence and reduce over-trust more than row-level freshness cues alone, or does it mainly overwhelm users and create new anchoring on ledger completeness as a proxy for quality?

Answer

A compact per-item evidence ledger likely improves calibrated decision confidence a bit more than row-level freshness cues alone for engaged users, and modestly reduces some forms of over-trust—but it also introduces a new anchoring risk on "ledger completeness" and can overwhelm less motivated shoppers unless aggressively simplified and tightly linked to explanations.

Net effect vs row-level freshness cues alone

• For attentive users, ledgers > simple freshness badges:
  • Better calibration: seeing last spec check, review recency, and explicit gaps makes the table feel more conditional and inspectable, not like a single ground truth.
  • Over-trust shifts, not disappears: users trust "rich" ledgers more and become more skeptical of sparse ones, which is closer to warranted trust than treating all rows as equally certain.
• For casual users, added value is small:
  • Many will treat the ledger as noise, skim a single icon (“green = good”), or anchor on a simple score derived from it.

Key dynamics

• Calibrated decision confidence:
  • Goes up when the ledger is summarized (e.g., 1–3 short tags like “specs rechecked 5d ago · reviews 10d ago · gaps: warranty”), with tap-to-expand details.
  • Drops if the ledger is verbose, inconsistent across items, or contradicts the agent’s verbal summary.
• Over-trust:
  • Over-trust in obviously stale/unknown rows falls: ledgers make hidden gaps visible and support constraints like “only items with verified specs <30d old and no major gaps.”
  • New bias: users over-trust items with visibly complete ledgers, even if what’s complete is low-impact or driven by cosmetic merchant updates.
• Anchoring on ledger completeness:
  • Strong: once introduced, users quickly see “full” ledgers as a proxy for quality and coverage, especially if a simple overall badge (e.g., A/B/C) is shown.
  • Mitigable if the agent keeps tying recommendations to specific ledger lines (“I’m recommending A because its safety specs were reverified last week, even though B has more recent reviews”).
• Cognitive load:
  • Manageable in desktop / high-stakes flows with collapsed summaries.
  • Risky on mobile or low-stakes browsing: users may ignore the ledger, default to rank/brand/price, or feel the table is “too technical.”

Design implications (concise)

• Use ultra-compact ledger summaries plus drill-down, not dense micro-logs.
• Drive conversation off the ledger: let users say “only show items with any spec verified this month” or “I’m fine if only reviews are fresh.”
• Avoid a single composite “ledger score”; keep 2–3 named dimensions (e.g., specs, reviews, price) so users don’t treat completeness as pure quality.

Overall: evidence ledgers are more helpful than simple freshness cues alone for users who notice and use them, but they must be aggressively simplified and narratively integrated or they will either be ignored or become a new, imperfect anchor on perceived quality.