Customer Trust Portals and External Assurance Packages

As quantum platforms mature into services, customers will ask for evidence: what changed, which controls are active, what data is retained, which providers are used, how results are reproduced, and how incidents are handled. A trust portal is the governed interface for those answers. It should not be a marketing page. It should be an evidence-backed product surface.

Diagram loads as you read

Customer Trust Portals and External Assurance Packages · Figure 1

View diagram source

flowchart LR
    Customer[Customer or auditor] --> Portal[Trust portal]
    Portal --> Controls[Control status]
    Portal --> Incidents[Incident summaries]
    Portal --> Providers[Provider and backend status]
    Portal --> Data[Data and retention policy]
    Portal --> Evidence[Evidence package samples]

Trust portal contents

Section	Purpose
control status	show recent control-probe results and coverage
runtime contracts	publish supported APIs, modes, and deprecation windows
provider matrix	disclose enabled providers, regions, device classes, and restrictions
data handling	explain classification, retention, residency, and deletion behavior
evidence model	show what artifacts are produced for customer workloads
incident summaries	communicate relevant events without exposing sensitive details
security posture	explain secure development, vulnerability handling, and access model
quantum claims	state what the service does and does not guarantee

Diagram loads as you read

Trust portal contents · Figure 2

View diagram source

mindmap
  root((Trust portal))
    Controls
      probe freshness
      exceptions
    Runtime
      versions
      deprecations
    Providers
      devices
      reservations
      quotas
    Data
      retention
      residency
    Evidence
      schema
      sample package
    Incidents
      summaries
      remediations

Continuous monitoring guidance emphasizes providing information needed to respond to risk in a timely manner when observations show controls are inadequate [R242]. A trust portal should expose the customer-safe subset of that same monitoring posture.

Assurance package

An external assurance package should be generated from internal evidence, not written separately by hand.

Diagram loads as you read

Assurance package · Figure 3

View diagram source

flowchart TB
    Internal[Internal evidence graph] --> Filter[Customer-safe filter]
    Filter --> Redact[Redaction and aggregation]
    Redact --> Sign[Sign package]
    Sign --> Portal[Publish to portal]
    Portal --> Customer[Customer download]

Redaction boundary

Not all evidence can be published. Provider contracts, vulnerability details, customer identifiers, and sensitive telemetry may need redaction. The goal is to preserve decision-useful assurance without leaking operationally dangerous detail.

Diagram loads as you read

Redaction boundary · Figure 4

View diagram source

flowchart LR
    Evidence[Evidence] --> Classify[Classify]
    Classify --> Public[Public]
    Classify --> Customer[Customer-specific]
    Classify --> Internal[Internal only]
    Classify --> Restricted[Restricted security]
    Public --> Portal[Trust portal]
    Customer --> Portal
    Internal --> Archive[Internal archive]
    Restricted --> Vault[Restricted vault]

Customer-facing SLO evidence

A customer-facing SLO needs a corresponding evidence path.

Diagram loads as you read

Customer-facing SLO evidence · Figure 5

View diagram source

flowchart LR
    Promise[Published promise] --> Indicator[Service-level indicator]
    Indicator --> Measurement[Measurement query]
    Measurement --> Evidence[Evidence source]
    Evidence --> Review[Review cadence]
    Review --> Portal[Customer report]

Claims discipline

Trust portals should avoid unsupported claims such as “quantum advantage,” “secure by quantum,” or “fault tolerant” unless the evidence package can sustain the claim. The portal should make boundaries visible.

Claim type	Required evidence
availability	SLO measurement and outage definitions
reproducibility	replay packet, dependency lock, backend context
privacy	retention controls and data-flow map
security	secure development process and vulnerability response
performance	benchmark definition and comparison baseline
quantum utility	workload-specific validation and confidence interval

Diagram loads as you read

Claims discipline · Figure 6

View diagram source

quadrantChart
    title External claim posture
    x-axis Weak evidence --> Strong evidence
    y-axis Low claim ambition --> High claim ambition
    quadrant-1 Publish carefully
    quadrant-2 Reduce claim
    quadrant-3 Do not publish
    quadrant-4 Safe factual claim
    Benchmark result: [0.8, 0.6]
    Marketing slogan: [0.2, 0.9]
    Availability SLO: [0.7, 0.4]
    Research hypothesis: [0.4, 0.5]

Operating rule

A trust portal should be generated by the same control system that operates the platform. If the portal and the platform disagree, customers will eventually discover that the portal is fiction.