Skip to main content

Trust Explainability Guide

PTI-compatible implementations MUST expose explainability so institutions can review outcomes without treating intelligence as a black-box score.

What consumers receive​

Trust lookups SHOULD include:

  • Confidence bands and context-scoped score outcomes
  • Drivers — ranked factors with human-readable labels
  • Provenance — partner, community, and verification sources
  • Coverage gaps — explicit thin-data flags (never implied clearance)

Explain contract (explain_score.v1)​

Trust reports and API payloads include explainability suitable for committee review, adverse-action workflows (consumer responsibility), and audit sampling.

Typical structure:

{
  "confidence": {
    "score_pct": 72,
    "band": "good",
    "drivers": [
      {"id": "lending_repayment", "label": "Repayment signals", "weight": 0.32},
      {"id": "community_endorsement", "label": "Community validation", "weight": 0.18}
    ]
  },
  "coverage_gaps": ["thin_insurance_history"]
}

Normative detail: RFC-012 Trust Evidence

Signals → drivers → outcome​

Why two subjects differ​

FactorEffect
Contextlending vs rental activate different signal sets
CoverageThin partner linkage → explicit gaps, not silent defaults
RecencyRecent verified events weigh more than stale silence
Source weightsContract-bound producer types per consumer workflow

Consumer interfaces​

Implementations MAY expose explainability through APIs, structured reports, and operator consoles. UI product names are deployment-specific; the JSON contract above is what conformance tests validate.

Reference implementation​

TumiTrust provides institution-facing explainability panels and API exports aligned with this guide. See Trust platform overview and Trust platform API.