Where lab-to-bulk handoffs go wrong
- The recipe is copied between systems. Each copy is a chance to change a digit.
- Approval is not tied to a version. A signature on paper does not say which calculation it approved.
- The person who wrote the recipe also releases it. Nobody else looked at the numbers before the machine was loaded.
- Changes overwrite the old recipe. When a shade complaint comes back, nobody can show what was actually dyed.
A controlled workflow, stage by stage
| Stage | Who acts | Control |
|---|---|---|
| Lab dip | Colorist or lab manager | Shade trials are recorded and approved before a recipe is written from them. |
| Recipe draft | Colorist | Dosages, fabric weight, liquor ratio, cotton condition and alkali system are entered once. |
| Calculation | Colorist | Stock, dispense, salt, alkali and water come from the site's approved reference pack and are recorded with a fingerprint. |
| Review | Technical approver | The exact recorded calculation is approved, and the decision is stored with the person and the snapshot it belongs to. |
| Release | Production issuer or approver | Release produces one production instruction that cannot be edited afterwards. |
| Change | Colorist | A correction starts a new version. Releasing it supersedes the old instruction; history stays. |
One person or three
A small lab is often one person, and a workflow that demands three signatures they cannot provide just gets worked around. DyeLogic runs solo by default: the same operator calculates, approves and releases, and every step is still recorded against them with the calculation it belongs to.
A dyehouse with separate staff turns independent approval on. The person who writes or submits a recipe then cannot approve it, the approver cannot release it, and those decisions additionally require a multi-factor sign-in. The workflow is the same either way; only the number of people it insists on changes.
Approve the calculation, not a description of it
An approval should point at one exact calculation. DyeLogic records every calculation as a snapshot with a SHA-256 fingerprint, and the approver decides on that snapshot. If anyone edits the recipe afterwards, the approval no longer matches and the recipe must be recalculated and reviewed again.
Release something that cannot drift
The production instruction is created at release from the approved snapshot and stored with its own fingerprint. The dispensing sheet shows whether the stored document still matches it, and a cancelled or superseded instruction prints with a clear "do not dispense" warning. Emergency cancellation always needs a written reason.
A checklist you can use with or without software
- Keep one approved set of stock, salt and alkali tables per site, with a version number.
- Record which table version every recipe was calculated from.
- Approve the calculated recipe, not the handwritten dosages, and record the decision against that calculation.
- Where you have the staff, have someone other than the author approve it, and someone else release it.
- Never edit a released recipe; issue a new version and keep the old one.
Where the numbers come from
The calculation stage is where most of the arithmetic lives. The salt and soda ash calculation guide works one recipe through stock solution, dispense volume, salt, alkali and make-up water. For access control and data isolation, see the DyeLogic security model.