Receipts, not promises.
+A TrustShell action is decided before it runs, recorded while it runs, and sealed into a receipt anyone can check offline — one that is strict about what it refuses to claim. Five steps, no single “valid” badge at the end of any of them.
+-
+
- 1 Enforce→ +
- 2 Observe→ +
- 3 Verify→ +
- 4 Earn→ +
- 5 Reuse→ +
The owner decides before the tool runs
+A policy you own lists what may run and pins each tool to one executable by path and sha256. The decision and its record come before the command starts — a command that is not listed, or whose binary was swapped, never starts.
+$ trustshell guard init # write the owner policy; every limit 0 +$ trustshell guard allow tool:git --exe "$(command -v git)" # list it AND pin it by path+sha256 +$ trustshell run --tool git -- "$(command -v git)" --version # decided+recorded, then runs +$ trustshell run --tool git -- ./not-the-pinned-git --version # REFUSED before it starts (exit 5)+
authorization and containment claims come from.What happened is recorded — and so is what no one watched
+The run records the plain facts it has: the exit code, the signal, the duration. It does not claim to have watched the work. The card says so in those words, and the record goes into a local, hash-chained log you can check offline.
+$ trustshell inspect # verify the local tool-call log — opens NO socket +INTACT .trustshell/session.jsonl # exit 0 · BROKEN (1) / UNCHAINED (3) / NO_LOG (3)+
independently observed — nothing: no outside party watched this command. “Exited 0” is recorded as an exit code, never promoted to “succeeded”, “correct”, or “verified”.One receipt, six separate claims
+There is no single “valid” badge. verify-receipt recomputes the hash and the signature locally — no network, no engine — and reports each claim on its own, with its own gaps.
-
+
- IntegrityVERIFIEDThe bytes are whole: the hash matches the contents, and a pinned Ed25519 key sealed them. +
- AuthenticityNOT_CHECKEDNo six-claim envelope was supplied, and this cannot be derived from the receipt alone. +
- ObservationNOT_CHECKEDNo outcome (e.g. a payment settling on chain) was observed and attested. +
- CorrectnessNOT_CHECKEDThe content was not verified against its source. +
- AuthorizationNOT_CHECKEDWhether the kernel permitted this action under its policy is not established here. +
- ContainmentNOT_CHECKEDThat the tool ran only under an ALLOW decision is not established here. +
Three levels of evidence, never collapsed
+A signature says who sealed a receipt — not that an action was permitted, and not that it earned a reputation. The levels do not blur together, and you can only reach the first one by yourself.
+ +Owner-self-signed you can do this now
+Sealed with your install’s own key. Integrity verifies under the key you pin, offline.
+Proves authorship and wholeness, nothing more. Not independent verification, and it earns no production RepID.
+Issuer-attested the engine’s key
+An engine key sealed the receipt and an authenticated six-claim envelope backs it, so a claim beyond Integrity reads VERIFIED.
+The engine’s key is not independent of the issuer, so this is not yet independent verification — and still not reputation. Verification and reputation are separate gates.
+RepID-eligible the engine decides
+Whether a receipt earns portable reputation is the engine’s call, against its own pinned key.
+Never an offline verdict, and never self-declared. An owner cannot promote their own receipt here.
+Carry what was earned — authority stays home
+A bundle is one Ed25519-signed file: your profile, the policy by hash, the notes you choose, and evidence pointers by sha256. Never credentials, keys, or spending authority. What travels is evidence a stranger can check; what does not travel is the power to act.
+$ trustshell bundle export carry.sig --notes released # sign a carry; the key never goes in it +$ trustshell bundle import carry.sig # verify its signature, then write it here+
What a receipt does not prove
+-
+
- An owner self-signature proves authorship and wholeness — not that the engine permitted the action, and not that it earned reputation. +
- NOT_CHECKED is never rounded up to a pass. A claim with no evidence stays not-checked; there is no single rollup “valid”. +
- Offline verification is stateless. It does not catch a verbatim replay of one receipt. Replay is prevented by the engine’s receipt-id and nullifier, not by the offline verifier. +
- A pinned root is required to accept a seal. With no key pinned, a whole-but-unaccountable receipt is NOT_CHECKED, never exit 0. +
Run the enforced path and check its log yourself — no account, no network, no container:
+$ npx @hyperdag/trustshell@latest guard init +$ npx @hyperdag/trustshell@latest guard allow tool:git --exe "$(command -v git)" +$ npx @hyperdag/trustshell@latest run --tool git -- "$(command -v git)" --version +$ npx @hyperdag/trustshell@latest inspect # INTACT — the local log holds+
And verify any receipt you are handed, offline:
+$ npx @hyperdag/trustshell@latest verify-receipt r.json --root 0x…
+