For general contractors
One receipt covers a whole day on site. Show one photo later without showing the rest.
Each visit's photos are sealed together in one step. Any single image can be proven part of that day's set on any future date.
What this means for you
- Photo bytes are hashed on your device rather than uploaded; the manifest sent for anchoring contains relative paths, file digests, sizes, and the root.
- One receipt covers the whole job-site visit.
- Show one photo later without showing the rest.
How it works
Each photo gets a fingerprint — a 64-character code that changes if a single byte of the file changes. The fingerprints are computed on your own machine; the files themselves are not uploaded.
The fingerprints and relative paths are combined into one fingerprint for the whole folder. The anchoring request includes the manifest metadata and root, but not the photo bytes.
The combined fingerprint is anchored to the Bitcoin chain. Anyone, on any future date, can confirm the folder existed by the moment of that block — and that a single image was part of it — without ever seeing the other photos.
For the technically curious
Show the cryptographic detail
The natural unit is one folder per job site per day, anchored at end-of-shift. A larger unit — one folder per phase or per milestone — is reasonable when assembling closeout packets. The folder contains every photograph the field crew captured during the visit, ordered by the relative path under which it was filed.
The office never sees the photographs. The desktop or browser tool computes a SHA-256 fingerprint of each file, binds the file's relative path into a leaf hash under RFC 6962 domain separation, and assembles the leaves into a Merkle tree whose root is submitted to the OpenTimestamps calendars. The bytes of the photographs themselves do not cross the wire.
The root is then anchored to a Bitcoin block, and an OpenTimestamps proof for that root is delivered back to the contractor. The proof is sufficient, on its own, to demonstrate that the anchored folder existed by the time of the recorded block.
A claim arises months after the slab pour that the rebar spacing was non-compliant on a specific date. The contractor produces the single photograph of the rebar mat under the slab, together with an inclusion proof (approximately log2 N sibling hashes) that demonstrates the image was a leaf of the anchored end-of-day folder no later than its recorded Bitcoin block. The remaining contents of the folder are not exposed by the proof. The receipt does not establish the day the photograph was taken; it establishes that the image, under its recorded relative path, existed by the time of that block.
The folder receipt records the Merkle root, per-leaf relative paths, SHA-256 digests, byte sizes, and available OpenTimestamps attestations. The root commits to each relative path and file digest; the byte sizes are recorded beside them but are not part of what the root commits to. An optional valid did:key signature can show that the corresponding private key signed the manifest. Orphograph does not establish who controls that key, or identify the person or device that took a photograph. Where path names are themselves sensitive, rename or copy the files to non-sensitive paths before anchoring.
Questions
Where do my photos go?
The photo bytes remain on your machine. The service receives the folder manifest metadata and root, including literal relative paths, so use non-sensitive filenames or renamed copies where path disclosure matters.
What does one receipt cover?
One day's photos for one job site, sealed as one set. Per-phase or per-milestone folders are also fine.
Can I show just one photo later?
Yes. You can disclose a single image and prove it belonged to that day's set, without disclosing any of the other photos.
What if a photo is altered after anchoring?
A single changed byte produces a different fingerprint, which breaks the proof. Any independent check spots the mismatch.
Orphograph anchors evidence of existence; it does not certify authorship, ownership, or legality. Each user retains responsibility for the underlying files, their consent to capture, and their handling under applicable law. The office is not a law firm, not a regulated medical-records system, not a qualified electronic trust service, and not a legal or financial advisor. No claim of compliance with any state's lien-law evidentiary standard is asserted; independent counsel review is required before any productized claim of evidentiary utility.