Limits of the signed record
What the signatures on orders, status, verdicts and gate decisions still do not establish, each limit stated as a limit.
Every limit below is true of this release. They are collected here so that the statement on what a third party can check is never quoted without them. The wider limits are on what this does not prove.
Gate decisions: item 4 holds only above the epoch
Until the owner declares the person epoch for gates, gate rows are signed by the workspace key. That shows a machine of the workspace wrote the row. It does not show which person decided.
The declaration is the owner's own act, made once, with the owner's touch (saphan trust gate-epoch propose, then saphan trust gate-epoch declare). Rows at or below its boundary stay as they were: saphan gates names their regime workspace-mac (or pre-identity for rows older than signing), and nothing re-signs them or deletes them. So for any gate in your trail, first establish which side of the epoch it is on. Only above it does the person's own key decide the row — person-v2 for an owner-class gate, seat-v2 for a gate a seat decided.
Two roads that sign an owner-class gate have no person form and refuse once the epoch is declared: a batch file of decisions, and the console's pull-request merge button. Each refuses by name and says where to decide instead.
Orders: approved by a person, chained to the root only if you require it
Every order a run receives carries a person's passkey approval. The approval binds the exact order text, is single-use, and expires — four hours by default, 24 hours at most — and the door that places an order refuses one that is unapproved, expired or already spent. Checking the order's signature chain back to your root is a separate setting, trust.enforce, which is off by default; read it on the deployment in scope. See identity and PKI.
"As of checkpoint X"
A verdict is "verified as of checkpoint X". A revocation recorded after X is not covered by it, and a newer checkpoint covers it. The checkpoint is chosen by whoever exported the folder.
What the bundle itself does not sign
The list of documents, their roles and the change id in a bundle are the bundle's own and are not signed. The answer cannot show that no required document was left out, and a fork is visible only if the bundle carries it. Agree with the owner, in advance, which documents a change must have.
One signer per act
Each act is signed by a single key. There is no quorum and no second-person requirement for any act. If your framework requires dual control, it is not provided here and is named, not hidden.
Machine certificates
A machine certificate is carried in the bundle and is not judged by the offline check. A seat's validity window is likewise enforced when the seat acts, not by the offline check.
What this page does not cover
This page is about signatures. Run records, retention, egress and confinement are covered on what this does not prove, and nothing here changes what that page says about them.
The word to be careful with
"Non-repudiable" is earned for a change only when the five items on what a third party can check verify offline with the public tool, within the limits above. Used without that condition, it overstates.