Preview · in development

A defensible record of what the system actually examined.

The Evidence Packet is a reproducible record tying a forensic verdict to the exact object received at intake — designed so an opposing expert can verify it independently, without trusting Plica. This page describes the design. It is being built, not yet shipped end-to-end, and we are honest about exactly where each piece stands.

The problem it answers

"Show me what you examined — and prove it."

When a regulator or an opposing expert questions a decision months later, an approval log is not enough. The serious question is: what object did the system rely on, and can you reproduce it independently? Most workflows have an approval trail. Almost none have a true evidence trail for the object itself. The Evidence Packet is designed to be that trail.

Honest build status

Where each piece actually stands.

We mark every component honestly — shipped, partial, or design. This is the same status language we share with the forensic experts reviewing the approach. No overstated certainty.

Shipped
Intake hashing & detector witness
A SHA-256 of the file and a record of what the detectors found are produced today, with explicit reason codes.
Partial
Dedicated intake seal
A distinct sealed record — raw-bytes hash + metadata snapshot + provenance tier, separated from cache logic — is being formalised.
Design
Hash-linked transform log
An append-only, continuous data-hash chain — each operation's input hash equals the prior output hash — so no unlogged transform can hide.
Design
Independent timestamp (RFC 3161)
A trusted timestamp committing to a root over the whole record — verifiable against the authority, not Plica's word. Until shipped, time is labelled unverified.
Design
Public verifier
An open schema and verifier any expert runs on their own machine with standard tools — checking the data-continuity chain, not just log links.
Wireframe

What the packet looks like.

Illustrative structure — not a live export. Fields marked partial or design match the build status above.

Evidence Packet · ANL-20260611-a3f7c291
time_anchor: server_unverified
sha256_intake
a3f7c291e84b… · shipped
verdict_tier
suspicious · GAN_EMBEDDED
policy_action
route_to_hitl
reason_codes
LAYER_CONFLICT_EMBEDDED · METADATA_STERILE
intake_seal
partial — formalising dedicated seal
transform_log
design — hash-linked chain
rfc3161_timestamp
design — not yet anchored

An opposing expert should be able to verify intake bytes and detector witness today. Seal, transform chain, and timestamp are on the roadmap.

Scope, stated first

What the packet will prove — and what it won't.

Stating the boundary up front is what makes the rest credible. A forensic expert probes the limits first — so we name them.

It can establish
  • The analysed bytes are identical to what was received at intake
  • Which transforms Plica applied, as a verifiable chain
  • That the record can be reproduced without trusting Plica
It cannot establish
  • That the file was authentic before it reached intake
  • Who the uploader is, or what happened on their device
  • That no AI ever touched the original capture
Why we publish this now

Honest before finished.

We'd rather show you the design and its gaps than demo something that falls apart under scrutiny. The Evidence Packet is being pressure-tested with working forensic examiners before it ships — because a sealed record you can't independently verify is worse than none.

If evidence-grade reproducibility is on your roadmap and you want to shape it — or stress-test it — early access is open. You'll see exactly what works today and what is still design.

Want to shape the evidence layer?

Early access · honest status · forensic-reviewer input welcome

Request early access →