The bundle is the competitor
The pieces are real. The graph change is the test.
Instead of a purpose-built delivery system, most teams wire general-purpose tools together around the store: an encrypted declaration in source control, store-native writes, infrastructure code, runtime delivery, a local render, and scripts to sequence them. That assembly is the bundle. It delivers secrets. Part two left one question open — whether it delivers them as a single transaction or as evidence scattered across its parts.
Every piece emits its own proof
Each primitive covers a real job, up to the point where a guarantee begins. An encrypted declaration makes a change reviewable, and can even bind a value to its key name — but nothing in the file binds it to its owner and authority, or turns a decryption key into an authenticated, revocable read. Store-native writes get the value to rest, though the store's guard only starts after the write lands. Infrastructure code takes a path rather than plaintext, and that path is copied by hand — free to drift from what was written. Runtime delivery and a local render handle consumption, and a script sequences the rest, with none of them able to say how the value entered or what else changed. The visible job is what each primitive does on its own; the guarantee behind it has to be built on purpose, and a bundle that leaves it to convention has not built it at all.
Even the proof each piece does emit is split. The encrypted file proves one value was reviewable, the store's log proves a write at its boundary, the infrastructure plan proves a path, and the runtime surface proves only the final read. Each artefact is true about its own seam and silent about the rest, and the map that connects them is a README or a JSON file kept by convention.
A split like that holds only while whoever assembled the route is still there. People change roles and leave, and the design shows itself the first time the route has to change under someone who did not assemble it.
Rotation and revocation reveal the design
Rotation and revocation are the test the bundle has to pass. Each one changes the graph, then has to prove the change finished — and that proof is where scattered evidence gives out.
A new store write is not . A new value at the store counts as rotation only when every required output moved to it and the previous receipt was marked superseded. A bundle that updates the store but leaves a build secret, a mounted copy, or a rendered file on the old value has produced two live values and no record of which one is current.
Revocation is the sharper test. Removing a recipient from a list is access-list cleanup; it becomes revocation only when the shared material is re-keyed so the old key stops working, because anyone who cached the value or the key still reads it otherwise. And revocation is forward-only. It cannot un-read what a recipient already decrypted, so the honest operation stops future access and records that earlier exposure is out of its scope.
Different material revokes through different authorities. Static shared material stops when it is re-keyed. A leased or dynamic credential stops at expiry or at its broker. A third-party credential stops only when it is invalidated at the source that issued it. Revoking a recipient inside the delivery graph is a separate act from invalidating the credential at its origin, and a receipt that does not name which side changed leaves the other side quietly live.
What the receipt is for
The split gets worse against one specific reader: someone who can write to the repository but cannot decrypt a value. That reader can edit a declaration, a manifest, an encrypted blob, or a receipt. Scattered evidence cannot separate an edit the authority applied from one the reader forged, because each piece is independently writable and independently believable. A receipt signed by the authority can separate them: the signature covers the state, so a forged edit cannot pass as applied state. That boundary, between applied and forged state, is what the receipt buys.
The same record has to be honest about what it cannot establish. A write-only destination proves the write happened, not that the stored value still matches what was sent. Recording that limit per destination is the honest move; implying the same certainty everywhere is a drift of its own, caught the next time someone leans on a check that was never that strong.
Storage gives a value somewhere to rest. Delivery is the route around it, and the receipt records that route as one object — slot, owner, authority, outputs, wiring, and the proof limits each destination carries. A bundle can hold every one of those pieces and still fail the test, because they are held together by convention, and convention is not evidence.
The comparison was never against bad tools; it is against scattered proof. A bundle becomes a delivery system when it stops emitting a separate artefact per seam and emits one record instead: what changed, what moved with it, what could not be verified, and which earlier record it supersedes. Until it emits that object, the next rotation and the next revocation start from someone's memory, and the route lasts only as long as the memory does.