How SiteSealed turns a construction record into checkable evidence
SiteSealed follows a five-step path from capture to a portable proof bundle. The design is deliberately explicit about which parts already operate in the web application and which parts remain targets of the founding whitepaper.
1. Capture: preserve the distinction between live and imported material
The first step establishes the record class before any proof is created. A live web capture is produced through the camera interface, linked to a fresh server challenge, a verified SiteSealed account session and browser-reported context. An imported photograph, PDF or other pre-existing file remains a separate class. It is never silently presented as a live capture, because an upload cannot prove when or where the source file was originally made.
The current web client still lacks hardware-backed camera, device, GNSS and clock attestation. Browser geolocation is a claim bound into the manifest, not authenticated satellite positioning. A hostile client can simulate camera input or submit false context outside the official interface. The Evidence Report therefore separates cryptographically proven file identity from server-bound claims and from facts that remain unproved. That boundary is part of the evidence, not a footnote.
2. Hash and encrypt on the client
The browser computes SHA-256 digests for the exact original and the canonical manifest before upload. A digest is a fixed-length fingerprint: changing even one byte produces a different value. The original and manifest are encrypted with AES-256-GCM in the browser, and the decryption material stays in the private Recovery Kit. The server receives ciphertext and the values needed to bind it to one exact grant; it does not receive the plaintext original or the AES key.
Hashing proves identity and later integrity, but it does not establish truth, authorship or capture time on its own. This is why SiteSealed binds the digest to an explicit record class and a manifest instead of treating a file hash as a complete evidentiary claim. The canonical Evidence Report contains the visible exact original and the exported proof sources so a recipient can perform the same calculations without relying on a screenshot or portal summary.
3. Request an external time token without overstating it
In the founding design, the digest is submitted to a qualified trust service provider and receives a qualified electronic timestamp. The deployed alpha does not yet meet that condition. It calls Evidency's sandbox and independently checks the returned RFC 3161 token, CMS signature, signer binding and certificate path to a release-pinned sandbox root. The token is test-only, is not qualified and carries no qualified eIDAS legal presumption.
Keeping the qualification boundary visible prevents a technically valid sandbox response from becoming a false legal statement. Moving to production would require a production service agreement, an appropriate trust policy, qualification status verified through the relevant EU Trusted List, certificate revocation handling and a formal security review. Until those gates are met, the interface and reports retain their sandbox and ALPHA wording.
4. Batch records with a Merkle tree
Evidence digests are grouped into a Merkle tree. Pairwise hashing produces intermediate nodes until one Merkle root commits to the complete batch. Each record keeps its leaf hash, leaf index, batch size and inclusion path. The path contains only the sibling hashes and their left or right position, so a verifier can reconstruct the root without learning the contents or identities of the other records in the batch.
Batching is an efficiency mechanism, not a change to the evidence. One root can commit to many records while every individual record remains independently checkable. The proof bundle records the Merkle protocol and exact path rather than asking a reader to trust a green status label. A mismatch at any step produces a different root and fails verification.
5. Anchor the root and export one canonical Evidence Report
The hourly rail worker commits the Merkle root to Ethereum mainnet in domain-marked transaction calldata. After the required confirmations and finality checks, the record exposes the full transaction hash, anchor address, chain and block, Merkle root, leaf and inclusion path. Those fields let a reader fetch the transaction from an independent Ethereum node and compare the public commitment with the locally recomputed root.
The final human artefact is one SiteSealed Evidence Report. It contains the visible exact original, attaches the original byte-for-byte, identifies both external rails and states what is proven, attested or not claimed. A finalized chain anchor does not make the content factually true, and a sandbox time token does not become qualified merely because its signature is valid. The report is designed to survive scrutiny by making those limits inseparable from the proof.