Turn receipts into a bounded report#
Start by deciding what question you need to answer. Counting decisions, authenticating evidence and establishing completeness are different jobs.
Four questions, four kinds of evidence#
| Question | Evidence to inspect | Remaining assumption |
|---|---|---|
| Authenticity: who signed these bytes? | Signature, authorized key and verifier trust configuration | Key custody and signer honesty |
| Continuity: do supplied records link in order? | Hash links, sequence and policy events across rotations | A trusted head/start when the run is only a prefix |
| Completeness: is the declared interval present? | Independently retained stream identities and expected boundaries | The independence and coverage of that collection process |
| Runtime truth: what effects actually happened? | Trusted mediation and independently observed effects | Host, engine, transport and operating-system assumptions |
An ordinary receipt log covers no more than the records supplied. A signature cannot establish that a denied handler never ran or that an unrecorded action did not happen.
Explore ordinary receipts#
For existing local receipts or logs, these read-only commands summarize the supplied inputs. Choose your own file paths:
h2h report receipts.jsonl
h2h report receipts.jsonl --format json --out report.json
h2h receipts verify receipts.jsonl --policy policy.yaml
h2h log verify receipts.jsonl --keyring keyring.json --require-signaturesRead policy decisions and enforcement outcomes separately. deny plus
would_block is a monitoring observation, not prevented execution. warn
plus confirmed means the host reported confirmation, not that the eventual
side effect completed successfully.
Ordinary h2h report --require-signatures checks log-entry signatures, not
standalone signed-receipt envelopes. A report is an aggregate view, not a new
signature over its source inputs or an independent assessment.
Verify before publishing evidence#
When you need authenticated inputs, authorized stream signers and declared boundaries, use the separately versioned experimental strict evidence profile. It refuses invalid inputs before publishing the report/completion sidecar, verifies records before time filtering, and keeps independent streams separate.
Without a trusted boundary inventory, completeness remains not-established.
An empty time window is no observations, not automatic satisfaction. The
verification sidecar binds the report's bytes but is not itself an independent
trust root; a recipient must trust its producer or reverify source evidence.
Export observations to OSCAL#
The experimental OSCAL path requires an explicit validated assessment context:
assessment plan, its system security plan and an already-resolved catalog.
It emits observations, not findings, risks or objective satisfaction. Use the
signed monitor walkthrough
to see would_block preserved in the result.
Keep source evidence, report bytes, profile, independently provisioned trust inputs and collection boundaries together in your retention process. Document which parts are authenticated, independently bounded, runtime-observed or merely supplied by the producer.