30-second answer
m365-governance verify ./assessment-from-a-supplier.jsonThe digests are recomputed from the bytes in the file. Nothing about the answer depends on who produced the document or on their word for it.
Why this is a separate command
Verifying is what a recipient does. A check that needed the producer would only
ever be telling them what the producer already believes, which is why verify
does not ask the engine that made the document anything.
What it prints when the document holds
<assessment id>
tenant contoso.sharepoint.com
identity application: Sites.Read.All
acquired collected
created 2026-08-16T09:14:02Z
resources 53
evidence 53 documentsRead acquired before anything else. A document assembled from example
fixtures verifies exactly as well as one collected from a tenant, because
verification establishes that the bytes did not move and not where they came
from. Integrity is not provenance, and a green result that you carry into a
meeting as a tenant reading is the one mistake this surface can lead to.
What it prints when it does not
Every problem, then:
./assessment-from-a-supplier.json does not verify.Something in the document differs from what was signed. Do not act on its findings.
When it is the wrong document
not an assessment. `verify` checks the document `assess` writes; to re-render
a report use `report`.A report cannot be verified because it does not carry what it was decided from. Ask the sender for the assessment.
Where to go deeper
verify: exit codes and the full output.- Canonical JSON and digests: how the same document hashes identically on two machines.
- Fixture versus observation: what stops an example being presented as a reading.