Independent Verification

Independent log attestation

A signed, recurring report on the cryptographic properties of a transparency log, issued by a party independent of the log's operator. The operator hands it to an auditor, a customer, or a regulator. Anyone holding it can re-verify the findings against the log's public data.

Coverage

What the report covers

Signed head

The log's checkpoint signature is recomputed against its published key. A wrong key cannot produce a valid verification, so a pass is evidence, not the operator's word.

Append-only history

Consistency between two signed heads is recomputed — from the log's proof endpoint where one exists, or re-derived from raw tile hashes where one does not. A pass means no earlier entry was altered or removed beneath the current head.

Witness quorum

Each cosignature on the checkpoint is verified against keys taken from published sources. Cosigners whose keys are not published are reported, and are not counted.

External anchor

Where the log commits its history into an outside system such as Bitcoin, that commitment is checked against the outside record.

Every finding is marked recomputed — established from the log's published artifacts — or subject-reported — taken from the operator and awaiting independent recomputation. The two are never mixed, and a property the log does not publish is reported as absent rather than as a failure.

Limits

What an attestation does not establish

That the records are true. A faithfully logged false record is still false. The attestation covers the integrity of the record, and does not judge its content.
That any actor was authorized. Authority, permission, and liability are a separate layer above this evidence.
Completeness, except where the record structure makes an omission detectable.

These limits are stated in every issued report.

Method

How a report is produced

Verification uses public artifacts only: checkpoints, proofs, tiles, and published keys. No access to the subject's systems is needed, and none is requested. Hashes and signatures are recomputed with self-tested tooling; negative controls confirm that a corrupted input fails.

Each report is issued in two forms: a human-readable document, and a machine-readable signed record — canonical JSON under an Ed25519 attestation key held separately from any log key. Verifying the record requires the attestation key and the log's public data, and nothing else.

Track record

Runs to date

The machinery has issued signed attestations over logs Markovian does not operate: Go's module checksum database (sum.golang.org), Sigstore's rekor, a Google Certificate Transparency log, and a peer company's ledger. For each, the head signature and the append-only property were recomputed from published data. A sample report is available on request.

Contact

Who it is for

Operators of transparency logs whose auditors, customers, or regulators ask how the records are known to be intact. Under the EU AI Act, Article 12 requires providers of high-risk AI systems to keep event logs across the system's lifetime; an attestation is one way to show, later, that those logs were not rewritten.

Write to [email protected].