The chain of custody

Every operation that crosses a trust boundary produces a receipt: a signed, timestamped record linking an action to a verified identity and to the exact content involved. Receipts are cryptographically linked, so the chain is tamper-evident.

• What — a content hash. For a commit, the commit SHA. For a clone, the remote URL plus resolved HEAD.
• Who — a verified identity, not a git author field. Git author is self-asserted and trivially forged.
• When — a timestamp from the signing daemon, not from the local machine.
• Which operation — clone, push, merge, blame, scan, and so on.

The signing key never touches SecureGit

ShippedSecureGit composes an envelope and posts it to a daemon. It cannot leak a key it never holds.

The cost, stated up front: you need the daemon reachable to produce first-class receipts. That is why the chain is Layer 3 and not Layer 1. Offline mode — receipts written to a local store and synchronized when the daemon is next reachable — is DESIGNED.

Two tiers of evidence

Tier A is forward-attested: the daemon witnessed the operation as it happened. Tier B is retro-attested: the receipt was added after the fact. Real, useful, and weaker. The system records which tier you have and never conflates them.

A system that lets retroactive evidence masquerade as witnessed evidence is worse than no system. It produces confident wrong answers precisely when being wrong is expensive.

Commit receipts live in two places: a trailer in the commit message (X-ContextOS-Receipt) that travels with the repository, and the daemon’s receipt store indexed by content hash. Neither is the single source of truth. They cross-validate. Disagreement is signal.