> ## Documentation Index
> Fetch the complete documentation index at: https://docs.signsealship.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Evidence model: SEALED, RECORDED, and verification

> The vocabulary behind every SignSealShip evidence claim: what SEALED, RECORDED, and no-evidence-yet cryptographically mean, and how to verify without trust.

Every evidence claim on SignSealShip — on a room card, in a Closing Passport, on a verify page — uses exactly three words. The vocabulary is locked on purpose: evidence language that stretches is trust theater, and trust theater is the thing this platform exists to replace.

| Badge               | Meaning                                                   | Verifiable without us? |
| ------------------- | --------------------------------------------------------- | ---------------------- |
| **SEALED**          | A cryptographically verifiable artifact hash is on record | Yes                    |
| **RECORDED**        | Platform attestation only — we say it happened            | No                     |
| **No evidence yet** | Nothing to show, said explicitly                          | —                      |

The rule behind all three: **never imply evidence that is not held.**

## SEALED

SEALED means a cryptographically verifiable artifact exists and its hash is on record. When a document card shows SEALED, it links to the seal's public verification page at `/v/{verifyCode}`. What stands behind that badge:

<AccordionGroup>
  <Accordion title="Google Cloud KMS signature">
    The document is sealed with an asymmetric signature whose private key never leaves Google Cloud KMS. It is a CMS/PKCS#7 signature visible in a standard PDF signature panel, with byte-range tamper evidence: change one byte after sealing and every verifier can tell.
  </Accordion>

  <Accordion title="RFC 3161 trusted timestamp">
    An independent time-stamping authority attests, over the sealed document's SHA-256, that those bytes existed at that moment. The token is archivable and independently verifiable — it is the authority's word, not ours.
  </Accordion>

  <Accordion title="OpenTimestamps anchor (pending, then anchored)">
    The sealed hash is submitted to public OpenTimestamps calendars, producing a detached `.ots` proof anyone can verify or upgrade with standard tooling. We describe it exactly as it is: pending until a Bitcoin block confirms it, anchored after. We never claim "anchored" before the chain does.
  </Accordion>

  <Accordion title="Custody record and verify code">
    Every sealed document gets a 128-bit random verification code and a custody record: the pre-seal document hash, the post-seal hash, and when the seal happened. Possession of the code (or of the sealed file itself) is the authorization to see the record.
  </Accordion>
</AccordionGroup>

<Note>
  A freshly sealed document can briefly show SEALED without a verify link while its verification code is being generated. The badge is still earned — the artifact hash is on record — and the card points at the verification drop portal at [signsealship.com/verify](https://signsealship.com/verify), where uploading the sealed file resolves its record.
</Note>

## RECORDED

RECORDED means our systems logged that a milestone happened — a document finished signing, a package shipped — but no independent cryptographic artifact backs that specific claim. It is honest attestation, clearly labeled as attestation.

This distinction runs through everything:

* A room card shows RECORDED for a signed-but-not-yet-sealed document.
* A Closing Passport labels every `statusAtSnapshot` as attestation, distinct from the hash fields beside it.
* A RECORDED item never renders a verify link, because there is nothing independent to verify.

If you need a claim to survive scrutiny that does not extend to trusting SignSealShip, get it SEALED.

## No evidence yet

Pending items say "no evidence yet" in those words. Not a spinner, not a softened euphemism, not an empty space that invites assumption — an explicit statement that nothing is on record.

Two related fail-safe rules:

* **Unknown statuses read as open.** If a room encounters an order status it does not recognize, the document renders as *open* — never as complete. New states fail toward "less claimed", not more.
* **Absence is stated, not padded.** In a Closing Passport manifest, hash fields exist only when the artifact exists. A missing `sealedSha256` key is the record that no seal exists.

## Verifying without trusting us

Every SEALED claim is checkable through channels SignSealShip does not control:

<Steps>
  <Step title="Open the sealed PDF in a signature viewer">
    The KMS signature and byte-range tamper evidence validate in a standard PDF signature panel, offline, with no SignSealShip involvement.
  </Step>

  <Step title="Check the public verify URL">
    `/v/{verifyCode}` (or `/v/room/{verifyCode}` for a [Closing Passport](/closing-passport)) shows the custody record — hashes and seal time — with no account and no login.
  </Step>

  <Step title="Recompute the hashes yourself">
    SHA-256 the sealed file you hold and compare it to the recorded `sealedSha256`. For passports, re-canonicalize the manifest and re-hash it; the chain must recompute cleanly.
  </Step>

  <Step title="Verify the timestamps independently">
    The RFC 3161 token validates against the issuing authority; the OpenTimestamps proof validates against the Bitcoin blockchain with standard open-source tooling.
  </Step>
</Steps>

<Check>
  If SignSealShip disappeared tomorrow, every SEALED artifact would still verify. That is the bar the vocabulary is built around.
</Check>

## Where the vocabulary appears

* **Room cards** — each attached document carries exactly one badge. See [Closing Rooms](/closing-rooms).
* **Closing Passports** — hashes are evidence; statuses are labeled attestation; coverage is enumerated. See [Closing Passport](/closing-passport).
* **Verify pages** — `/v/{code}` and `/v/room/{code}` show only what the record holds.
* **Webhook events** — deliveries carry verify codes and hashes, never inflated claims. See the [webhooks guide](/webhooks-guide).