Docs · Compliance
Export local SOC2 evidence.
Local-onlyLedgerful generates a signed ZIP of local evidence entirely on your machine. This is not a hosted SOC2 portal — no data leaves your device during export.
Scope of the local export
The compliance export is a local operation. It reads your .ledgerful/ directory and produces a ZIP you can share with auditors or archive for your own records.
Local only:The SOC2 evidence export is a local ZIP generated entirely from your machine's .ledgerful/ data. No data leaves your machine during export. There is no hosted SOC2 portal — continuous monitoring, auditor access controls, and live attestation are enterprise-planned and require a future hosted control plane.
No CLI export command: The export is triggered from the local dashboard, not from the command line. Follow the steps below to generate the ZIP.
How to export
The export is initiated from the dashboard. Start the daemon, open the dashboard, and navigate to the compliance route.
- Start the daemon from inside your repository root:
ledgerful web start - Open the dashboard URL printed at startup — it includes your session token:
http://127.0.0.1:52001/?token=<your-token> - Navigate to the compliance route in the dashboard. Look for the Compliance or Evidence Export section in the navigation.
- Click Download to generate and download the signed evidence ZIP to your local machine.
ZIP file layout
The evidence ZIP contains a signed manifest, ledger CSV, verification history, and any ADR files committed to the ledger.
| File | Description |
|---|---|
manifest.json | SHA-256 hashes and byte sizes for all other files, plus generatedAt (RFC3339) and entryCount. The files array is sorted by name for determinism. manifest.json itself is not listed in the files array. |
manifest.sig | Raw 64-byte Ed25519 signature over manifest.json bytes. Proves the manifest was produced by the holder of this repo's signing key. |
manifest.pub | Raw 32-byte Ed25519 verifying key (the public half of ~/.ledgerful/keys/). Used to verify manifest.sig offline without trusting a remote key server. |
chain_head.json | Signed chain head binding the latest entry hash, genesis boundary, and chain length. Present when the ledger has entries; omitted for empty-state. Used by `ledgerful verify --against-export` to detect rollback or tail-truncation against an independently retained export. |
ledger.csv | All committed ledger provenance records in RFC 4180 CSV format. Columns: tx_id, category, entity, change_type, summary, reason, committed_at, signed, signature, observed, prev_hash. Sorted by committed_at ascending, then tx_id ascending. The observed column carries gate-mode metadata (0050); prev_hash links each entry to its predecessor in the chain (0046, post-genesis only). |
verification_history.csv | CI gate pass/fail records. Columns: run_timestamp, overall_pass, command, exit_code, duration_ms. Header-only when there are no verification runs. |
adr/*.md | MADR-format Architectural Decision Records, one file per ADR ledger entry. Filenames are 0001-<slugified-summary>.md. Folder is omitted when no ADR entries exist. |
Offline tamper verification
Auditors can verify the ZIP without connecting to any Ledgerful service. All verification is performed locally against the included cryptographic artifacts.
- For each entry in
manifest.json'sfilesarray, re-compute SHA-256 over the corresponding file's bytes and compare to the stored hash. A mismatch means the file was altered after the manifest was generated. - Read
manifest.sig(64 raw bytes) andmanifest.pub(32 raw bytes). Verify the Ed25519 signature overmanifest.jsonbytes. A mismatch means the manifest was replaced. - Both checks must pass for the export to be considered unmodified.
manifest.pub trust model: The manifest.pub file contains the Ed25519 verifying key that was used to sign the manifest. However, this key originated from the same machine that generated the ZIP. A compromised machine could have replaced both the ledger data and the signing key, producing a convincing but fraudulent export.
Out-of-band verification required: To close this gap, the receiver must verify manifest.pub against a trusted out-of-band copy of your Ed25519 public key — for example, a key fingerprint you shared over a separate secure channel, or a copy stored in a location independent of the machine that generated the ZIP. Without this step, the signature proves internal consistency but not the authenticity of the signing key itself.