Expand description
The committed setup proof: what the last complete observation proved.
Four records answer four different questions, and none substitutes for
another. The target configuration is the desired state, the landing
record is what landed, the host journal is what one run did on one
machine, and rk setup check is what the forge answers now. This file
is the fifth: a portable, non-secret statement that a run able to see
every step saw each one hold, against a named setup contract.
The record never becomes current truth. A reader judges whether it still describes this target’s contract, and a live check that reads the forge still decides what holds now.
Structs§
- Checkpoint
- A record’s provenance.
- Invalid
Proof - Why a file is not a readable proof.
- Proof
- The committed record.
- Proven
Step - One step’s normalized result.
- Status
Document - The
rk.setup-status/1document. - Subject
- The setup contract a proof is judged against: the answers that decide which steps run and what each one asserts.
- Subject
Step - One step’s contract.
Enums§
- Standing
- Where a committed proof stands against this target now.
Constants§
- PROOF_
PATH - Where the proof lives, relative to the target.
- SCHEMA
- The record’s schema.
Functions§
- differences
- Every field where the recorded contract and the current one differ,
by name:
target.<answer>,step <name> <part>, or a step that one side lacks. - digest
- The subject’s digest over its canonical bytes: compact JSON, whose maps are ordered by key and whose lists keep step-table order.
- judge
- Read the committed proof and judge it against
current, offline. - of
- A proof of
report, orNonewhere the report is not a complete observation. - render
- The record’s bytes: pretty JSON with one trailing newline.
- subject
- The contract this target states now.
- write
- Write the proof in one rename, so an interrupted write leaves the previous record whole.