Chapter 29
Finished means ready to run again
Make maintenance, provenance, cleanup, recovery, and restart part of done.
On this page
While setting up the progressive press, I found two Zerk fittings at its pivots.
Lithium grease was already in the garage. Setup stopped. The press was lubricated before it had completed a cycle.
The pause added no production capability. No brass became a cartridge. The fittings were the manufacturer's admission that friction would arrive, and a safe path had been built for acting on it without dismantling the machine.
The press was not more functional after lubrication than before. It was more likely to remain functional.
Sustain work preserves capability rather than adding it.
The first output is the middle
A linear project picture ends at release:
input -> work -> output -> done
An operating system has to return:
ready to run
-> production
-> inspection and release
-> identified use
-> evidence returns
-> cleanup and storage
-> maintenance and repair
-> recovery or revision
-> ready to run again
The first cartridge, deployment, invoice, or customer response is not the whole experiment. The system has to identify what it produced, learn what happened when the output met the world, clear or preserve its in-flight state, maintain the mechanism, and begin again without archaeology.
Finished means operable, traceable, recoverable, and ready to run again.
Build the sustain checklist with the feature
Use the checklist before calling a slice done:
| Sustain concern | Question | Reloading-lab answer today | Status |
|---|---|---|---|
| Operability | Can an operator start, observe, stop, and understand the run? | the commissioned loop is exercised | partial |
| Provenance | Can output be traced to inputs, policy, and recipe revision? | completed BatchRecord carries load, brass, components, and count |
modeled |
| Recovery | Can partial truth be preserved and assessed safely? | held plate and read-only recovery assessment | modeled |
| Cleanup | Can residue leave the hot path without losing identity? | normal exits and quarantine are named | observed through swaging |
| Storage | Is returning tools and material cheaper than creating a side channel? | blocks, bins, pegboard, and homes are designed around use | ongoing |
| Maintenance | Is there an intentional path, owner, trigger, and record? | Zerk fittings used once before operation | initial action only |
| Restart | What proves the system is ready for the next run? | headspace loop is measured; restart gate not yet defined | partial |
| Feedback | Can use evidence find the exact decision that produced it? | notebook doctrine and batch identity define the round trip | designed |
Every "partial," "modeled," and "designed" resolves on The Lab Ledger: what is open, and what closes it.
The Status column prevents a provision from being mistaken for a habit. A
Zerk fitting is not a maintenance program. A health endpoint is not an on-call
practice. A recovery command is not evidence that anybody knows when to run
it.
For every sustain mechanism, add four fields:
- owner;
- trigger or cadence;
- evidence of completion;
- failure path when the mechanism itself does not work.
Without those, the fitting is decoration.
Calibration is a sustain obligation
Assembly did not make the Dillon a permanent 5.56 machine. Calibration produced scrap before the loop settled, and the next bounded lot earned a measured, case-by-case result; the counts live in The Lab Ledger.
That is commissioning evidence, not stored trust. Adjustment, drift, wear, or caliber change can invalidate it. The gauge remains part of operation because the configured machine must continue to earn the claim its last measurement supported.
The cost of rebuilding a configured line also changed the future design. Before commissioning 7.62 or 9mm, I plan to buy dedicated toolheads and powder systems. The XL750 chassis will remain shared while each caliber preserves more of its dies and powder setup as one module.
That choice spends more money and storage to reduce retuning and the chance of losing a known configuration. It refuses one convenient lie: preserved settings are not preserved proof. Every installed module still crosses its own measurement and release gates.
Preserve the settings. Re-earn the trust.
The cost of putting it back
Storage is an operating interface. The relevant measure is not how clean the garage looks after organization. It is how much work the intended state costs to restore after use.
If returning a tool requires moving three other things, the bench has created a side channel. The tool stays out. If updating documentation requires a special environment and a long review path, the new decision lands in Slack or memory. If registering a component is painful, callers reach for the vendor directly.
The easiest action eventually becomes the real workflow.
This is why cleanup belongs in done. A production run that leaves unidentified cases, tools blocking the next station, or state nobody owns has borrowed time from the next run and called it speed. The first output looks fast because the restart cost is hidden.
Provenance closes the range loop
A completed batch leaves with papers: load specification and revision, brass lot, primer lot, powder lot, bullet lot, and cartridge count. That identity travels to the range.
Accuracy, function, pressure signs, failures, and operator observations have value only if they can return to the exact batch and decision that produced them. "The 5.56 worked well" is memory. "Batch LC-2026-A, load 556-2026-001 v1, with these component lots, produced this result" is evidence that can revise a specification.
The loop also protects history. A new load becomes a new revision. The old record remains available beneath it. If the result matters, preserve enough context to reproduce or challenge how it was reached.
The current Ruby model creates the completion-side record and freezes its component-lot collection. It does not model the range-return message. That is an explicit boundary in the physical body plan and an open slice in code.
Recovery has to end in restart
Hold the plate stops and assesses. Sustain asks the next questions:
- Who authorizes each disposition?
- Who executes it?
- What confirms the quarantine exit received the material?
- What repairs the initiating fault?
- Which facts are rechecked after intervention?
- What event declares the machine ready to accept another input?
- What record connects the interruption, action, and restart?
An incident is not over when the alarm clears. It is over when the system is understood, capability is restored, residue is owned, and the next run no longer depends on the responder's memory.
This is where rollback procedures, repair jobs, admin tools, safe cache invalidation, credential rotation paths, and migration tooling belong. They are not product features. They are the paths that keep product features operable after first contact with time.
Design one restart loop
Choose a capability your team has already shipped. Draw its actual loop:
ready -> use -> output -> feedback -> cleanup -> maintenance -> ready
Then complete the checklist:
| Concern | Mechanism | Owner | Trigger | Completion evidence | Mechanism failure path |
|---|---|---|---|---|---|
| Observe and stop | |||||
| Preserve provenance | |||||
| Clean up residue | |||||
| Maintain dependencies | |||||
| Recover partial work | |||||
| Prove restart readiness | |||||
| Return learning |
If the loop depends on "someone remembers," name that person and the cost of their absence. If the maintenance mechanism exists but has no trigger, do not mark it complete.
What one application of grease proves
The press was greased. One case-processing configuration has produced measured work. Those are observed starts, not sustained practices. No maintenance interval has survived live-ammunition production. No complete batch has made the range round trip. No physical fault recovery has returned the press to service.
The lesson is not that every feature needs a large operations platform before release. It is that each coherent slice needs the smallest honest path back to readiness, and residue must have a due condition.
The next chapter asks where the requirements for those paths come from. Often they arrive as friction: tools left on benches, users bypassing a sanctioned workflow, capacity that fills immediately, or a workaround whose environment quietly became dangerous.