Remote inspections that produce court-enforceable evidence

The problem: evidence that does not survive being challenged

Inspections, audits and compliance checks were being done the way they had always been done — by sending a qualified person to a physical location. That is slow and expensive, and the travel is only the visible cost.

The real problem surfaced later. What the visit produced was a set of photographs and a report, and both are trivially easy to contest. A photograph has no inherent proof of when it was taken, where it was taken, or whether it has been altered since. A PDF report can be edited and re-saved without trace. When a file is challenged — in a dispute, an audit, or a court — the organisation that produced it has to fall back on the credibility of the inspector rather than on the evidence itself.

So the brief was not "build video calling". It was: make a remote inspection produce evidence that is harder to dispute than an in-person visit, not easier.

What we built

Four things had to be true at once, and each one constrained the others.

1. No install, on any device, including the other party’s

An inspection involves someone who does not work for the client — a tenant, a contractor, a site manager. Any flow that begins with "download our app" loses a significant share of those people, and the ones it loses are exactly the ones you need on the call. The capture side is therefore browser-based WebRTC: the participant opens a link and the camera is live, with no account, no install and no app-store round trip.

That decision is what makes the rest hard. A browser is an untrusted capture environment, so none of the evidentiary guarantees can depend on client-side software behaving honestly.

2. Capture bound by the server, not asserted by the browser

Evidence is only as strong as the weakest claim it rests on, so the platform is built to separate what it can prove from what it merely records.

Recordings never pass through the browser. An operator starts a recording; the media server’s own egress process writes the file to object storage; a webhook then has the backend stream that stored object down and compute its SHA‑256 itself. The capture time comes from the media server’s record of the session, not from anything a client reported. No participant device is trusted anywhere in that path, and the resulting record is created under legal hold.

Who, when, and in what order are server-held facts. Field participants carry an HMAC‑SHA256 token scoped to exactly one session with a four-hour lifetime, and invite redemption is pinned to the redeeming IP and user agent. Every audit entry is stamped from the server clock, takes a per-session advisory lock so the sequence cannot interleave, and chains into the previous entry’s hash over canonicalised JSON. The audit table is append-only at the database level — triggers reject UPDATE, DELETE and TRUNCATE outright — so there is no privileged path, ours included, that quietly rewrites history.

Location is treated as a claim, not as proof. A GPS fix comes from the browser and cannot be trusted on its own. So the server reverse-geocodes the reported fix, forward-geocodes the address the session says it is inspecting, and flags any divergence beyond 150 m on the report itself. The reader is shown the discrepancy rather than the system silently accepting it — or silently rejecting a legitimate inspection because of a bad fix.

3. Qualified timestamps from a real trust service provider

Under eIDAS a qualified electronic timestamp carries a legal presumption that its date and time are accurate and that the data has not changed since. That presumption is the asset: it moves the burden of proof onto whoever wants to dispute the record. It is also not something a platform can grant itself — it requires a qualified trust service provider.

NexBasira uses DataSure, an ANSSI-qualified QTSP, over RFC 3161, with the nonce echo-checked on every response. What happens to that response afterwards is the part that matters most: the raw timestamp token is stored verbatim, so an external verifier can validate it with nothing from NexBasira and nothing from us. The proof is not an assertion in a database that a timestamp was once obtained — it is the token itself.

Documents are sealed as PAdES (ETSI EN 319 142), with the document timestamp signature attached under the QTSP’s own certificate. Not XAdES, not CAdES: nothing in the product signs XML or produces detached signatures, and supporting formats nobody uses would have meant carrying verification code nobody exercises.

The reports are also explicit about where the authority actually comes from. The chain hash and the anchors are the load-bearing proof; the PAdES level is a property of the PDF container. Conflating the two is how evidence platforms lose arguments they should win.

4. A blockchain witness — deliberately not the qualified layer

The QTSP already satisfies the regulation. Anchoring to a public chain buys the properties a trust service provider structurally cannot offer:

• An independent witness, outside both NexBasira’s control and the QTSP’s. Two parties with different incentives now attest the same record.
• Nobody can withhold an anchor. The relay runs as a user-owned instance rather than a vendor service.
• Verification outlives everyone involved. The anchor lands in a smart contract and is checkable from any public block explorer, so a record stays verifiable even if the relay, the platform and we all disappear.
• Latency is affordable here. Finality takes roughly 15–20 minutes, which is acceptable precisely because this is not the real-time proof — the qualified timestamp already landed instantly. Fees are flat and predictable.

Running two independent backends is the point: an outage in one cannot break the chain of proof. We are equally careful about the claim — the blockchain leg is a witness, and the eIDAS articles are deliberately not claimed for it.

Merkle batching, and why a shared anchor is still private

Anchoring each session on its own would mean one transaction and one fee per session. Instead, a periodic job collects the sealed final hash of every anchor-ready session and builds a binary Merkle tree:

leaf(h) = SHA-256(0x00 || h)
node(l, r) = SHA-256(0x01 || l || r)

The two domain-separation tags are not decoration. Without them an interior node can be presented as a leaf, which is a real forgery path. Odd nodes are promoted rather than duplicated, which avoids the malleability bug behind CVE‑2012‑2459 in Bitcoin, where two different sets of leaves could produce the same root.

Only the root goes on chain — one transaction regardless of how many sessions it covers. Each session keeps its own inclusion path, so verification runs session hash → proof → root → transaction while every other session in the batch appears only as an opaque hash. That is what makes it safe to batch sessions from different organisations into one anchor: a customer verifying their own record learns nothing about anyone else’s, not even how many there were.

Verification is deliberately offline-first. The inclusion proof and the batch’s own confirmed state are what gate a report; a live query to the relay is advisory only. Treating that liveness check as authoritative produced a class of false negatives, and demoting it was the fix.

Operating inside GDPR, not around it

Inspection footage is personal data, frequently showing people’s homes and sometimes the people themselves. The platform runs on EU-resident infrastructure, and the anchoring design carries its weight here too: because only hashes are published, nothing personal is ever written to an immutable public ledger — which would otherwise sit in direct conflict with the right to erasure.

Retention is configured per organisation rather than globally, and defaults to indefinite. That default is deliberate: an evidence platform’s customers are usually under a contractual or statutory obligation to keep records for a defined period, and a platform-wide default would quietly break it for somebody. Changing the policy is a permissioned, MFA-gated action, and a legal hold on any single artefact stops removal for the whole session it belongs to.

Erasure requests are handled without destroying evidence. Personal identifiers on the subject are tombstoned, while the evidence, recordings and audit trail are preserved under the Article 17(3)(e) carve-out for the establishment and defence of legal claims. An evidence platform that could be emptied by a well-timed erasure request would not be much of an evidence platform.