Apodix
Open specification · profile of IETF SCITT

Evidence that outlasts software

Verifiable provenance for context a machine acts on. Three signed objects and one verification procedure, so that an output can be traced to the exact content behind it by someone with no access to your systems, no network, and no reason to trust you.

0.1 draft. The specification, reference implementation and test vectors publish shortly. This page runs the verification today, so the mechanism can be examined before the document exists.

Not a claim, a check

This page is running the verification, in your browser

Below is a real source record and a real Apodix receipt citing one passage of it. Your browser recomputes every digest with Web Crypto, rebuilds the Merkle tree, and checks the inclusion proof against the published root. Nothing is fetched and nothing is trusted.

Source record · CAL-2026-03 @ v3
Verification·
·segment 2 of 4

Change a single character in the record, for example the figure 0.0412, and watch the content digest and the Merkle root diverge from what the witness signed. Restore it and the proof passes again. That is the whole mechanism, with nothing hidden behind it. If you can make it report success when it should not, see below.

What this demonstration does not prove, stated before you have to ask.

The values checked above are constants written into this page. Whoever serves a page controls its constants, so what you just watched is the mechanism working correctly, not evidence that anyone deserves your trust. A demonstration and a proof are different things, and a provenance project that blurs them has already lost the argument.

It is the same gap tier 1 has. An attestation is worth exactly the word of whoever produced it until something the operator cannot alter is involved. Real verification uses a receipt you were sent rather than one we wrote, signing keys from your own trust configuration rather than ours, and a log root held by someone with no stake in the answer.

The claim, with its limits

A trust layer that overstates itself is worse than none

Apodix proves

  • Content left a named system unaltered, at a stated time, under a specific witness key.
  • A single passage belongs to that signed record, provable alone, without revealing the rest.
  • An output was produced over exactly this set of attested passages and no others.
  • What was withheld from the producer, and why.
  • That a statement existed before a given point, so nothing was back-dated.

Apodix does not prove

  • That the content is true.
  • That the output is correct.
  • That the producer reasoned well over what it was given.
  • That the right sources were selected.

Provenance does not imply accuracy. That sentence is normative in the specification, not a disclaimer beneath it. An implementation claiming otherwise is non-conformant.

Mechanism

A witness at the boundary, not an agent inside your systems

Nothing is installed in the source system and nothing about it changes. The source file comes back byte for byte identical: Apodix adds nothing to the object it certifies. It signs a digest and files a statement in a log.

01

Witness

Reads at the point content leaves. Hashes it, signs a source assertion, never writes back.

02

Log

Append-only transparency log. Its value is negative evidence: a quiet reissue becomes visible.

03

Gateway

Verifies every item, drops the unattested, labels what passes with its tier, records what it withheld.

04

Receipt

Binds one output to the exact context behind it. A stranger checks it offline, years later.

The hard part

Provenance that survives re-chunking

Segment boundaries depend on window size, overlap and tokenizer version, all of which change constantly. Signing passages would bind authenticity to an implementation detail, so every re-chunk would invalidate every signature although nothing about the source changed.

Apodix anchors provenance to content and treats a segmentation as a separately signed view of it. Re-chunking issues a new segmentation. The source statement is never reissued, and old receipts keep verifying.

SegmentationMethodSegmentsMerkle root
Afixed-window-256-overlap-324zjGHjqxtA_nN1B4ho-B40aVQPVwmoAByuhwOV_RkNY8
Bfixed-window-192-overlap-05AQw5ea5d2xWmGz_vt0418atpXS1kTXIwrpTKUVqHNPk
One unchanged source statement covers bothPtIv8rWNxEMNMMaFh0hSgUvJvJuI5pfkcNsoLyb3Ghk

Commit to what is stable, prove what is derived. A record of a million passages still needs about twenty digests to prove any one of them.

Trust tiers

Computed by the verifier, never asserted by content

TIER 0

Unattested

No valid statement. May pass by policy, but is labelled as what it is.

TIER 1

Witnessed

The operator's own witness. Worth the operator's word. Documentation.

TIER 2

Independently witnessed

A log the operator does not control. Survives "but you run this yourself". Evidence.

TIER 3

Source-signed

The source signs for itself, or a qualified seal applies. Legal weight, rare.

A document cannot state its own tier. The channel that carries trust is not one content can write to, which is why a crafted source arrives labelled tier 0 rather than arguing its way past the boundary.

Open by construction

The standard is the asset

No patents asserted

None filed over anything published here, and publication permanently forecloses European patenting of it. Deliberate, and recorded in the governance document so it cannot be quietly reversed.

Held for transfer

Lodvy Labs holds the name as a mark to hand to a neutral foundation, not to license. Governance moves once two independent implementations exist.

The log outlives us

Tree heads mirror to an independent log from day one. If operation ever ceases, the full log is published as a static archive so every receipt stays verifiable.

Specification text CC BY 4.0, code Apache 2.0. The most useful contribution is an attack on the threat model: if a claimed defence does not hold, that is worth more than agreement about the rest.

What would help most

Try to make it pass when it should not

The verifier above is the entire mechanism, running in your browser with nothing behind it. If you can make it report success over a record the witness never signed, or construct a case where an inclusion proof verifies for a passage that is not in the signed record, that is the most useful thing anyone could send.

The same goes for the design rather than the code. The threat model names eight attacks it defends against and seven it does not. If a claimed defence does not hold, saying so is worth more than agreement about everything else.

spec@apodix.org No list to join, nothing to sign up for.