Two different questions hide inside "can I trust this result?", and collapsing them into one answer is how verification systems quietly lie.
Question one: did the work meet its contract? That is the receipt's decision axis: Verified when an objective gate ran and every hard criterion passed, Accepted when the artifact is a plan or design that cannot have an execution gate. This is the exam grade.
Question two: who controlled the machine that produced the evidence? A run executed on your laptop or in your CI happened inside your trust boundary; a run in a managed sandbox happened inside ours. This is who proctored the exam.
The analogy that stuck in our design docs:
Verified or accepted is the exam grade. Customer-attested or Fusion-attested is who proctored the exam. You can score an A on a take-home exam; the grade and the proctoring are independent facts.
Why they must stay separate fields
The tempting shortcut is one status field with values like "verified", "customer-verified", "accepted", and so on. That enum cannot express the single most common paid case: a run that is fully verified and ran in customer-controlled CI. Mash the axes together and you either downgrade honest work or overclaim environmental control you did not have.
So the receipt carries them separately: the verification decision on one axis, and execution attestation metadata on the other, alongside a record of which tier the run executed in. A public badge can then say something precise like "Verified in customer-controlled CI", which is both a strong claim and a true one.
The rule underneath
Never weaken a strong word to cover a new case. "Verified" keeps its strict meaning everywhere; new trust dimensions get new fields instead of new adjectives bolted onto old ones. Vocabulary discipline is cheap the day you adopt it and ruinously expensive to retrofit.