A secret has to arrive
The lifecycle is bigger than the store.
An external credential appears before the system has a safe place for it. The route starts with a . Production needs one value, local development needs another, the build runner has to write destinations, and the application needs a stable path without plaintext entering infrastructure state.
That is already more than storage. A store gives the value a controlled place to live, decides which identities can read or write there, and records activity at that boundary. Delivery carries the unanswered questions: who introduced the value, which environment saw it, which surfaces received it, and what evidence survived after the change.
The common answer compresses the whole route into the final read: put the value in a central place, control access there, and fetch it from the application. That answer fits one backend and one consumer. It loses shape when the same logical slot has to cross runtime, build, deployment, and local development surfaces.
The smallest useful case
One logical credential slot is enough once it crosses production and non-production.
One operator receives both values at creation time. Production must stay closed to developers. The non-production value still has to arrive locally so the service can run outside prod. The build runner may need write authority for destinations, but broad read access would turn it into the secret authority. Infrastructure code needs stable paths and references instead of plaintext. Rotation later has to show which surfaces changed. Drift later has to be detectable without asking whoever pasted the value the first time.
A passive storage answer shows only where the values rest. Delivery has to record the route around them.
The omitted parts are the ones that break later:
- who introduced each value;
- where each slot was declared;
- which identity wrote each destination;
- which identity received decrypt, render, or consume rights;
- which path the application was given;
- what state recorded the apply;
- which proof is possible for each destination;
- what operation rotates a value or revokes a recipient.
Those questions are the lifecycle the store does not record.
The store has a smaller job
A store is still necessary. It gives the value somewhere controlled to live, applies read and write rules, and records activity there. That boundary is the strongest part of many designs.
The lifecycle around the store is where the undocumented work hides. In this case, a human received the credential outside the system and entered each environment value. That first moment decides who saw the value before any store policy existed.
Before a value reaches the store, someone or something already handled it. If that first handoff is not controlled, the store only protects the value after the most exposed moment has passed. A full platform can own the lifecycle when the team accepts it as the authority and that is a valid architecture. With a passive store, the handoffs still need their own record.
The store also does not model every output surface. A runtime workload reads one path. Build automation may have write authority without broad read authority. Deployment code receives a reference. Local development receives a rendered file with the non-production value. The same logical slot spans several surfaces, and each surface proves a different set of facts.
Readable destinations can support stronger comparison. Write-only or write-restricted destinations cannot prove plaintext equality after the write; they can prove the destination, operation, version, metadata, and receipt. That limit belongs in the state instead of in someone's memory.
Storage is one phase in the lifecycle. Delivery records how the value entered, who moved it, which outputs changed, and what evidence survived.
Delivery records the lifecycle
A delivery transaction starts before the API call that writes a value.
It declares the slot: owning workload, environment, key, and output surfaces. It accepts the value through a controlled entry path, wraps it before it becomes persistent plaintext, reconciles the required outputs, emits wiring, and records what happened.
That is heavier than "put it in the store" because it exposes work that already exists. The same work otherwise spreads across console clicks, scripts, notes, and build credentials nobody wants to name as the authority.
Later parts cover the authority choices, proof boundaries, and graph changes. This part only makes the missing object visible: the lifecycle around the store has to be explicit and recorded.
A delivery answer records the secret's lifecycle. It says where values live, how they enter, who moves them, which paths consumers receive, and what proof survives after apply. Otherwise the store is only the destination, while the movement into and around it remains undocumented.
The next part turns that lifecycle into a transaction: slot, value, introducer, authority, recipient, output surface, wiring, applied state, and drift.