A status page called encrypted evidence replayable without ever asking for the key

Flow

Capture workflow with the key-custody gate first

Capture ends at storage. Replay is a separate read-only command I run by hand afterwards.

1. 1Validate configuration⌄

   Flags, store context, and key shape are checked.

2. 2Key-backup confirmation⌄

   Flag and environment value must both be present or the run stops here.

3. 3Refusal path⌄

   Its own outcome and error code, zero attempts, no body read, not replayable.

4. 4Fetch upstream input⌄

   Only reached with confirmed custody. This is the step that can't be repeated.

5. 5Hash, compress, encrypt, store⌄

   The manifest records the hash and the key's name, never the key. Capture stops here.

The status report said the saved evidence could be replayed. It never checked whether the key to read it was around.

The evidence is the raw inventory response the ordering system pulls from the stores' sales system. I keep the exact bytes so I can run a new parser against the real original, not a guess.

How it gets stored

The bytes get hashed first, then squeezed and locked with a cipher that also catches tampering. Hashing first means replay can prove it got back the exact same bytes. Code that wants the file gets a handle, not a path. A small manifest next to the file lists the hash, the sizes, and the name of the key that locked it. Never the key itself. And the write won't run at all without a key.

So writing needed the key. So did reading. Only the write side knew.

The status that was always yes

The status page said "replayable" if the database row had a handle, a hash and a size. That is true the second the write works, and it stays true forever. A deleted file or a missing key still looked fine.

The key was in the service's config

The commits put that gap right beside the replay check, a read-only command run by hand. It unlocks the bytes, checks the hash, rebuilds the counts, and compares them to what was stored. It needs the key. For the first saved file, the key had to be dug out of the running service's own config, without printing it. With it, the replay passed.

It worked by accident. Capture only cared that some key was loaded. A key made in a throwaway shell would have worked that day and been gone the next.

What I'd copy into a similar system

• Report "kept" and "readable" as two separate answers.
• Check in order, cheap things first, and stop at the first problem: handle, storage, manifest, file, then the key. Is one loaded, does its name match, is it well formed?
• Show the key's name. Never show the key.
• Don't fix a red status by swapping keys, renaming the key in the manifest, or editing the evidence.
• Before capture fetches anything, require a confirmation that the key is backed up, as both a command flag and an environment setting. Test it by passing a fake fetch and checking it was never called.

The order on that last one is what matters. The upstream answer can't be fetched again and come back the same. The key check is cheap. So mine refuses first.

The status check doesn't unlock anything, so a key with the right name but wrong contents still passes it. Only an actual replay catches that.

The runbook now says it outright for my setup: a key that lives only in a temporary shell doesn't count. If I need a new one, it goes into the secret store first, and the capture waits.