How the evidence is actually protected

Everything uses SHA-256. It is a standard cryptographic digest, it is not ours, and you can compute it yourself with any tool you already have.

• Every photo is hashed on our server when it is stored. The digest is saved with the photo, and the API returns it, so you can download the file and verify the hash independently.
• The finished report is hashed at the moment it is locked — specifically, the hash is taken over the bytes of the generated PDF. That digest becomes the report's content hash.
• The tenant's signature is bound to that content hash, so a signature cannot be moved onto a report it was not given for.
• One-time codes — the sign-in and signing codes we email — are stored hashed, not in plain text, and expire after ten minutes.

Each photo's hash and the bound content hash are printed inside the finalised PDF, so the document carries its own evidence rather than pointing at a database you cannot see. The published sample report shows this, and verifies it in your browser.

Photos and PDFs live in S3-compatible object storage, not in the application database and not on the web server's disk. In production that is a dedicated object store; in local development it falls back to the filesystem.

Clients never receive storage credentials. Uploads use presigned, short-lived URLs signed with AWS Signature Version 4, scoped to one object key. Downloads work the same way. A presigned URL is a bearer token: while it is valid, anyone holding it can fetch that one object, which is why the links are short-lived and why we tell you not to paste them around.

In transit: everything is served over HTTPS. TLS redirect is on by default, session and CSRF cookies are marked secure, and we send HSTS for one year including subdomains, with preload. Every response from the frontend carries a Content-Security-Policy, frame-ancestors 'none', X-Content-Type-Options: nosniff, and a strict referrer policy.

At rest: the object store we use is configured at the infrastructure level, and whether it applies server-side encryption is a property of that deployment rather than something we set per object. We are not going to claim encryption at rest we cannot point at. If your situation requires it — and for some landlords it does — ask us and we will tell you what the current deployment does before you rely on it.

Account and inspection data is retained while your account is active, and for as long as we need it to provide the service and meet legal obligations. Share links stay reachable until you revoke them or the underlying data is deleted. Locked reports are never rewritten during their lifetime — that is the point of locking them — so retention means keeping them as they were, not editing them down.

Every finalised report is available as a PDF that carries the photo hashes, the bound content hash and the signature block inside it. The underlying report data — items, conditions, notes, photo digests and timestamps — is exportable too. Nothing about your data requires our application to read: the PDF stands on its own, which is deliberate, because a record you can only open in our app is not much of a record.

Email [email protected] from the address on the account with the subject "Account deletion request". We verify ownership against that address first — that is the whole reason the request has to come from it.

We acknowledge within two working days and complete the deletion within 30 days, including object storage. Backups may retain a copy for a short period after that before they age out, and we will say so rather than implying instant erasure. Anything you have already exported is yours and is unaffected.

We keep this list short, and we will update this page before adding to it.

• Object storage — an S3-compatible store for photos, signatures and generated PDFs.
• Email delivery — an SMTP provider that sends sign-in codes, signing codes and report notifications. Configured per deployment, so we will name the exact provider if you ask.
• Edge network and analytics — Cloudflare, for content delivery and aggregate page analytics. The analytics beacon is privacy-preserving and sets no advertising cookies.
• Hosting — the application runs on a single region chosen at deployment.

We do not sell personal data, and we do not pass inspection photos to advertising or model-training services. There is no third party that receives your evidence in order to make money from it.

This section exists because a security page that only lists strengths is marketing.

• We do not make a record legally admissible. Whether a report is admitted and what weight it carries is decided by your jurisdiction and your facts, not by us. We are a documentation tool, not legal advice.
• A hash proves integrity, not truth. It proves the file has not changed since it was hashed. It does not prove the room really looked like that, or that the photo was taken where the device claimed.
• Device-reported location and time are not verified. They come from the handset, and a handset can lie. That is exactly why the server-side timestamp and the hash matter more than the watermark.
• We cannot protect an account you do not protect. Anyone who can read your email can request a sign-in code. Use an email account with a strong, unique password and second-factor authentication. We do not yet offer two-factor sign-in ourselves, and that is on the roadmap.
• We cannot protect a compromised device. If a phone is unlocked, lost or infected, anything already signed in on it is exposed.
• We do not store anything offline. A photo captured without signal is not held anywhere. There is no queued upload yet.

If you think you have found a vulnerability, email [email protected] with enough detail to reproduce it. We will confirm receipt, tell you what we found, and credit you if you want to be credited. Please do not test against another customer's data, and please give us a reasonable window before disclosing publicly.