HushSpec/Docs
HUSHED · MMXXVI
Documentation v1.0
v1.0.0guidestable

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#

QuestionEvidence to inspectRemaining assumption
Authenticity: who signed these bytes?Signature, authorized key and verifier trust configurationKey custody and signer honesty
Continuity: do supplied records link in order?Hash links, sequence and policy events across rotationsA trusted head/start when the run is only a prefix
Completeness: is the declared interval present?Independently retained stream identities and expected boundariesThe independence and coverage of that collection process
Runtime truth: what effects actually happened?Trusted mediation and independently observed effectsHost, 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:

Terminal
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-signatures

Read 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.

Loading documentation index…

↑↓ navigate↵ openesc close