Architecture
One substrate, four products.
The four product lines are not four codebases that happen to share a logo. They sit on one verification substrate: the same sealing, the same custody chain, the same anchoring, the same independent re-verification path. This page describes that substrate and where each product line attaches to it.
Layer model
Where each product attaches.
Fig. 08 — platform layer model
Custody pipeline
Five operations, in this order, every time.
The order matters more than any individual step. Sealing before encryption means the digest describes the artefact, not the ciphertext. Anchoring after chaining means the external witness covers the sequence, not just the contents.
-
Ingest
Material arrives with whatever digest the acquiring device computed. The server independently recomputes and compares. A divergence is written into the custody trail as a divergence — it is never silently accepted, and it is never silently rejected either.
-
Hash and seal
Four digests are computed at intake: SHA-256 and SHA3-256 carry the integrity claim, MD5 and SHA-1 are retained because existing case records, published hash sets and third-party tooling still use them. The original is sealed; work proceeds on derived copies whose digests provably relate back to it.
-
Encrypt
Each artefact is sealed under AES-256-GCM with a unique data key wrapped by the key-management service. Plaintext keys are zeroed after use. Ciphertext is written to two independent backends — a content-addressed store and a region-routed encrypted object store — so a single storage failure is a redundancy event, not an evidence event.
-
Anchor
Every custody event joins an append-only SHA-256 hash chain. The chain is offline-capable: it continues to extend and self-verify with no network at all. Batches are Merkle-committed to a permissioned ledger, and each record retains its inclusion proof against the committed root.
-
Verify
On demand and continuously, stored bytes are pulled back from both backends, re-hashed from scratch, and compared against the sealed digest and the anchored record. Anything that fails is quarantined rather than served. This is the step that turns the previous four from a design into a claim.
Independent verification
The check has to work without us.
A verification system that only verifies when its vendor is cooperating has not solved the problem it claims to solve; it has moved the trust from the storage layer to the vendor. So the verification path is designed to survive our absence.
- Published primitives. The digest, canonicalisation and signature schemes are named and standard, so a third party can implement a verifier without reverse-engineering anything.
- Deterministic canonicalisation. Records serialise the same way every time, which is what makes an independent implementation able to reproduce a digest byte-for-byte.
- Detached signatures. Court packages verify offline using standard open-source tooling — no product installed, no service reachable.
- Account-free public verification. Anyone holding an evidence reference can confirm its digest and custody timeline without credentials, and without being shown case-internal content.
- Retained inclusion proofs. Each record keeps its Merkle path, so its membership in an anchored batch can be checked against the ledger directly.
If the only way to check our work is to ask us, it is not verification. It is a reference.
Fig. 09 — verification without the vendor
Deployment
Where it can run.
Evidence work happens in places with real constraints — jurisdictional, physical and political. The architecture assumes those rather than treating them as exceptions.
Sovereign / on-premises
Full stack inside the customer’s own estate, including the permissioned ledger. Nothing leaves the boundary. The public verification surface can be published selectively or kept internal.
Air-gapped
The custody chain extends and self-verifies with no connectivity. Anchoring batches queue and commit when a connection becomes available, so a disconnected period is a delay in external witnessing rather than a hole in the record.
Multi-organisation
Distinct organisations, roles and channels are first-class. Evidence crosses an organisational boundary through a scoped, revocable grant — and the grant itself becomes a custody event on the chain.
Default-deny surfaces
Every route and resolver is authenticated unless explicitly declared public. The public verifier is the one deliberate exception, and it is rate-limited and returns integrity status without case-internal content.
Federated identity
Integration with existing identity providers over standard federation protocols, with signature verification on assertions rather than trust-on-presentation.
Region-routed storage
The encrypted object backend routes by region, so data-residency obligations are met by placement rather than by policy assertion.
Specifications
Standards, implemented.
Listed because the work is written against them. Where something is aligned rather than certified, we say aligned.
Want the architecture in more detail?
We will happily go through the record formats, the canonicalisation rules and the failure modes — including the ones we have not solved.