Ai trust design

AI Trust Design

Role / Purpose

AI Trust Architect. Every AI product faces the same structural problem: users are impressed before they trust, and they trust before they pay. "Wow" is free. Trust is earned. This skill designs the bridge between them.

Note: capability claims precision, limitation statement requirements, and the demo edge-case principle are in pmm/DOMAIN.md (AI product content section). This skill covers the product and onboarding design layer — the mechanisms that build trust inside the product experience itself.

---

Contract

This skill guarantees:

• The three trust types are identified and distinguished — interventions are matched to the specific trust type blocking conversion
• The distrust spike is treated as a designed stage, not an accident to avoid
• Limitation statements follow the specific/contextual format — vague legal disclaimers are flagged
• Output identifies which trust type is the actual conversion blocker before recommending a mechanism

---

Before starting

Confirm (ask or infer):

• Conversion problem — which transition is failing? Discovery → trial / trial → active / active → paid / paid → enterprise?
• ICP — developer trialist / business user / enterprise buyer? (different trust types block different ICPs)
• Current onboarding design — does the product have a first-run experience? A playground? A limitations page?
• Available evidence — what capability evidence exists? (benchmarks, case studies, usage data)

---

Inputs

Required before proceeding:

• Description of the AI product and its primary use case
• Which conversion step is underperforming
• Current onboarding or first-run design (if any)
• ICP or user type experiencing the drop-off

---

The three trust types

Most AI products conflate these and address none of them properly:

Trust type	User question	When it blocks conversion
Capability trust	"Can it actually do what it claims?"	Prevents first trial; users won't start if they don't believe
Reliability trust	"Will it work consistently, not just in demos?"	Blocks production adoption after initial trial
Safety trust	"What happens when it's wrong, and is that recoverable?"	Blocks enterprise purchase and high-stakes use cases

Decision logic:

• Discovery → trial drop: capability trust gap
• Trial → active/paid drop: reliability trust gap
• Active/paid → enterprise drop: safety trust gap

Do not apply reliability mechanisms to a capability trust problem, or vice versa.

---

Decision logic — matching mechanism to trust type

Capability trust mechanisms

These establish "it actually works" before the user invests time:

CAPABILITY TRUST DESIGN

Curated first-run experience:
  The first output should be as close to perfect as possible.
  Do NOT show the full capability range in onboarding — show the
  highest-reliability use case first. Broad capability claims attract;
  high-quality first output converts.

Social proof from technical peers:
  An engineer's benchmark result is worth 100 marketing claims.
  Surface case studies and community results from users with similar
  technical contexts — not generic testimonials.

Live playground with real inputs:
  A locked demo that always works is weaker than a playground where
  users see the model working on their own inputs — even if the output
  is imperfect. Imperfect real output > perfect scripted demo.
  (This is the playground-as-trust-signal principle.)

Reliability trust mechanisms

These address: "will this work consistently for production use?"

RELIABILITY TRUST DESIGN

Accuracy / confidence indicators:
  Show the model's certainty where meaningful.
  An AI that says "I'm not confident about X" is more trustworthy than
  one that asserts everything with equal confidence.

Failure mode documentation:
  Explicitly describe when the model fails, under what conditions, and
  what the user should do. "This model struggles with X" builds more
  trust than silence about X — users will discover it anyway.

Regression testing visibility:
  If accuracy metrics are tracked, publish them. Users who know you
  measure reliability trust you more.

Version consistency:
  For API products, version pinning is a reliability trust feature
  as much as a technical one. Users need to know that a prompt that
  worked last week still works today.

Safety trust mechanisms

These address: "what happens when it's wrong?"

SAFETY TRUST DESIGN

Explicit use case scoping:
  State clearly what the product is and is not appropriate for.
  "This is not suitable for [high-stakes use case]" is a trust signal —
  it tells the user you've thought about where the product breaks.

Human-in-the-loop design:
  For high-stakes actions, the user must always have a review step.
  AI products that skip this to feel more autonomous lose enterprise trust.

Error transparency:
  When the model is wrong, acknowledge it clearly. Products that make it
  hard to identify AI errors lose trust faster than products where errors
  are visible and recoverable.

Data handling transparency:
  Where does user input go? What is it used for?
  For enterprise, this is a prerequisite, not a nice-to-have.

---

The trust arc

FIRST CONTACT → WOW → DISTRUST SPIKE → TRUST BUILDING → RELIABLE USE → ADVOCACY

The distrust spike is not a bug — it is the natural response to seeing a powerful demo. After the initial wow, users think: "That was impressive in a controlled setting. Will it work for MY situation? What if it's wrong?" Products that acknowledge this spike design better onboarding. Products that pretend it doesn't exist lose users who experience it alone.

Stage	What the user needs	Design response
Wow	Understand what is possible	Curated demo path with high success rate
Distrust spike	Acknowledgment that their skepticism is valid	Explicit limitations page; "when to trust this output" guidance
Trust building	Evidence of reliability in their use case	Examples from users like them; sandbox with their own data
Reliable use	Consistency signals over time	Usage history; accuracy indicators; error transparency
Advocacy	A story to tell colleagues	Output shareability; benchmark results to reference

---

Making limitations a growth asset

The counterintuitive principle: stating limitations increases conversion for serious users.

Serious users (the ones who will pay and stay) are evaluating whether they can trust the product. A product that acknowledges limitations credibly signals:

1. The team understands the product well enough to know where it breaks
2. The product is honest — which implies the claims it does make are real
3. The user won't be surprised in production

Limitation statements that build trust: specific, contextual, with guidance.

Good: "This model performs poorly on [specific input type] — for those cases,
try [alternative approach]."

Bad: "Outputs may not be accurate." (tells the user nothing useful)

Gate: any limitation statement that uses only a general disclaimer without specifying the failure condition and the user action is flagged. Require a specific version before publishing.

---

Output format

## AI Trust Diagnosis

**Product:** [Name]
**Conversion step underperforming:** [Discovery→trial / Trial→active / Active→paid / Paid→enterprise]
**Trust type blocking conversion:** [Capability / Reliability / Safety]
**ICP:** [Developer trialist / Business user / Enterprise buyer]

### Trust arc stage assessment
Current stage where users drop: [Stage name]
Evidence: [What signals indicate this stage?]

### Mechanisms to implement
Priority 1: [Mechanism — specific design action]
Priority 2: [Mechanism — specific design action]
Priority 3: [Mechanism — specific design action]

### Limitations content audit
Current limitation statements: [Specific / Vague / None]
Required rewrites: [List any vague disclaimers with specific replacement]

### Validation
[ ] Trust type correctly identified before mechanism selection
[ ] Limitation statements are specific (failure condition + user action)
[ ] Distrust spike is designed for, not hoped away

---

Brain reads / writes

If a companion brain repo is connected:

Before starting:

• Read knowledge/icp-map.md — ICP segment determines which trust type is typically the conversion blocker (enterprise buyers need safety trust; developer trialists need capability trust)
• Read playbooks/messaging.md — capability claims must be consistent with approved messaging

Brain not connected: proceed normally.

---

Anti-patterns

Anti-pattern	Why it fails	Fix
Applying reliability mechanisms to a capability trust problem	Users who don't believe the product works won't stay long enough to experience consistency	Diagnose the trust type first; match mechanism to the specific gap
Showing full capability range in onboarding	Users experience edge cases before they've built baseline capability trust; they leave	Show the highest-reliability use case first; expand after trust is established
Vague limitation disclaimers	"Outputs may not be accurate" tells the user nothing; they assume the worst	Replace with: "This model performs poorly on [specific case] — for those cases, [action]"
Hiding the distrust spike	Users experience doubt alone; product feels like it promised something it didn't deliver	Acknowledge skepticism explicitly in onboarding; give users language to evaluate the product
Treating "wow" as the conversion moment	Users who are impressed are not yet converted; the gap between wow and trust is where most churn happens	Design the trust-building stages as explicitly as the wow stage
Enterprise pitch without safety trust established	Enterprise buyers have safety objections that capability and reliability evidence cannot address	Build safety mechanisms before entering enterprise sales conversations

---

Validation criteria

• Conversion step identified before trust type is named
• Trust type correctly matched to ICP and conversion stage
• Mechanisms are specific to the diagnosed trust type — not generic "build trust" recommendations
• Limitation statements are specific (failure condition stated + user action given)
• Distrust spike addressed with a design response, not ignored

---

References & Sources

Tier 2 (operator source — adapted, not authoritative):

• ai-trust-design (growth-skills v1.0): three trust types, trust arc model, capability/reliability/safety mechanism taxonomy, limitations-as-growth-asset principle