Evidence and deployment
Know what the
record proves.
A signed record proves specific facts. What it covers, how the person was identified, where its time came from and where it ran matter as much as the signature.
Read the evidence at its stated level.
| What to check | What it proves |
|---|---|
| Record integrity | The signed bytes have not changed. Check the signature, and know why you trust the key. |
| Human identity | A declared name is a declaration. Presence at signing is a separate proof. An organisation’s identity needs the enrolment and key binding that deployment set up. |
| Authority | The record names the authority it checked. The deployment shows who could grant it, how far it reached, and how a change got to the action. |
| Human review | A standing grant is not a review of this output. Where review is required, record the reviewer’s decision and bind it to the output before release. |
| Time | A self-asserted time comes from the device clock. Independently witnessed time comes with its own timestamp evidence. Check that too. |
| Completeness | A closed packet shows a missing or reordered record inside its span. It cannot show activity that was never connected. Look for the boundary, the closing record and any gap. |
Verification does not say the work was right, that a policy pays, or that a court will admit it.
Keep the work private. Say what the record carries.
The record can carry a fingerprint of the document, the prompt or the output instead of the content. It still carries names, actions, times, review declarations and amounts, depending on the profile.
The deployment sets which fields are recorded, who reads them and what is shared. Leaving content out does not by itself make a record anonymous, privileged or unclassified.
State the deployment profile.
Customer-controlled enforcement
Checking and sealing need no cloud service of ours. The connection sets the action and the environment.
Optional witnessed time
A timestamp service receives a digest, never the work. Different from a deployment with no outbound requests at all.
Shared evidence and views
Share a record or grant a view, and that person sees what you chose to share. Who sees which fields, and for how long, is set at deployment.
Make the evaluation concrete.
Ask for the evidence behind the release you will deploy: which actions it covers, how it resists bypass, who holds the keys, how fast a withdrawal takes hold, what happens when it cannot run, what it depends on, and the measured latency. Keep samples, our own measurements and outside assessments apart.
The public demonstrations and the published mathematics are evidence. They are not an audit or a certification of your deployment. The Cleanroom Standard is the published classification; conformance is shown by the stated tests.
Verifying in ten years needs the records, the keys, the format, the verifier code and any timestamp evidence kept, and a plan for the day the cryptography changes.