An audit log is only useful if an auditor can trust it. A CSV a developer could have edited is not evidence. sapctl's answer is a hash-chained, ed25519-signed audit log that verifies entirely offline: no phone-home, no certificate authority, no network dependency.
The chain
Every audit event is a JSONL line. Each line carries the SHA-256 of the previous line, so the whole log forms a chain. The genesis block is 64 zero bytes. Alter any line, and every subsequent hash breaks.
sapctl audit init
sapctl --audit s4 catalog discover --cred sandbox --top 5
sapctl audit verifyaudit verify walks the chain, recomputes every hash, and checks the ed25519 signature. It returns a yes/no on whether any record was altered after the fact.
Why offline matters
Regulated SAP shops run in air-gapped networks: a German bank's production, a defense prime's classified enclave. A verification path that needs a network, a CA, or a hosted service is a non-starter. sapctl's chain verifies with local CPU and a public key embedded in the binary.
Air-gap bundles
For the most restricted environments, sapctl packages the evidence into an in-toto v1 bundle: rows, chain, public key, and manifest in one signed archive. The same binary that runs in a connected bank also runs on a USB stick into a classified network.
What this buys you
Tamper-evidence is a property of the data, not the network. A hash chain you can verify on a cold, disconnected host is the only audit log that survives the environments where audits actually matter.