Module audit 

Checking a plane’s history without trusting the plane.

Why this is a deliverable and not a property

Every mechanism underneath — the hash chain, per-record signatures, the Merkle log — is only checkable. Somebody has to actually check it, and if the only code that can is inside the runtime being audited, the claim collapses: the party under examination is also the party running the examination.

So this module is deliberately shaped to run against a store it did not write, with inputs an auditor holds rather than inputs the plane supplies:

• a prior checkpoint they were given earlier — the one artifact that has to have left the operator’s control;
• a public key, if they were told which workload should have signed.

Neither is required, and what can be concluded shrinks accordingly. That shrinkage is reported rather than hidden, because an audit that says “fine” when it checked three things out of five is worse than one that checked nothing.

What each input buys

Given	Answers
nothing	Is each run’s chain internally consistent?
a public key	Who wrote each record?
a prior checkpoint	Has anything been removed since it was issued?

Only the third detects deletion, and only because the checkpoint came from outside. That is the whole architecture of the thing in one row.

Structs

AuditReport

What an audit concluded, and what it could not look at.

Evidence

What an auditor brought with them.

ReleaseRecord

One journaled decision to improve a label.

Warrant

What authorized one run.

Enums

Finding

One thing wrong with a plane’s history.

Functions

audit

Check a plane’s history.