Public summary · Canonical detail lives with the product evidence system

Claims discipline

Every CopperCloud receipt is a pair of trust tier (how it was signed) and canonical status (what policy authority applied). Verification must expose both. Neither collapses into a single “valid = approved” stamp.

Trust tiers (summary)

  • local_unsigned — local structural checks only; not portable proof
  • developer_signed — developer-held key; not institutional authority
  • sandbox_signed — sandbox orchestrator evidence; demo/PoC only
  • software_attested — software-identity attestation under an authorised canonical pack
  • hardware_attested — requires a verified hardware attestation document

A receipt may never claim a trust tier higher than its canonical status authorises.

Canonical status (summary)

  • canonical — authorised policy pack suitable for institutional interpretation
  • tenant_canonical — authoritative only inside that tenant’s governance boundary
  • sandbox / developer_local — never institutional evidence
  • deprecated / revoked — historical interpretation rules apply; not new authority

Universal anti-claims

  • A receipt does not prove the workload was correct.
  • A receipt does not prove absence of a property the submitter merely declared absent.
  • Region labels alone do not prove Zambia residency.
  • CPU-side attestation does not prove GPU-side confidential compute.
  • A receipt does not prove regulatory compliance; it is evidence input to an institutional process.
  • Receipt age or continuity does not increase per-receipt trust strength.

Full operational detail is maintained with the CopperCloud evidence system. Public visitors should start with verification boundaries.