Do UI patterns for verifiability actually build user trust?

AI UX Playground names "Trust Scaffolding" as a category to "Use when people must decide whether to believe or rely on the system, from first run through evidence, control, and long-term use," and lists patterns for that decision: "Citations: Attach verifiable sources, quality signals, and claim previews," "Chain of Thought: Reveal step-by-step reasoning behind an answer," "Source Browser: Inspect retrieved sources and context beside the answer," "Granular Consent: Per-capability permissions with scope, expiry, revoke, and drift," "Failure Disclosure: Say clearly when the system cannot answer or a tool failed," and "Data Ownership & Control: User control over AI data usage."

The patterns split into two kinds of support for a trust decision: ones that let a user inspect the basis for an answer (Citations, Chain of Thought, Source Browser) and ones that let a user set and change the terms on which the system may act on their data (Granular Consent, which names "expiry, revoke, and drift" as properties a permission needs over time, and Data Ownership & Control). Failure Disclosure sits apart from both — neither evidence for an answer nor a permission over data, but a third mechanism: stating the system's own limits plainly when it cannot do what was asked.

This supplies a design vocabulary for a gap Does human-in-the-loop design actually enable effective oversight? argues builders leave unfilled: that primer finds builders ship intervention and some control while downplaying knowledge and observation — in this library's terms, shipping Granular Consent without equally building Citations, Chain of Thought, or Source Browser, the patterns that would give a user the knowledge and observation the primer says intervention depends on. Granular Consent's named properties of "expiry, revoke, and drift" also give concrete shape to what "control" means in that primer's four-part framework, beyond its own more abstract definition. It is a different design problem from Can autonomy controls stay distinct rather than collapse into one toggle?, drawn from the same library: that category scopes what the system may do, this one scopes what the user believes about what it did or will do.

As with the neighboring category, the excerpt is a set of named patterns with one-line definitions, not a study — it gives no evidence that citations or chain-of-thought reveal actually change trust, that users notice or act on "drift" in a granted permission, or that Failure Disclosure is applied consistently rather than selectively. What it establishes is which trust-relevant interface elements the design community has named and distinguished from each other, not which of them work.