Lessons · Lesson 5 of 8
- 01 · The six questions a record has to answer
- 02 · The prefix everybody stopped typing
- 03 · Two owners, and therefore none
- 04 · A permission with more verbs than the reason
- 05 · What a version is for, and what it has to keep
- 06 · Both edits were right; one of them is gone
- 07 · Six people, one record, and who pays for the tidying
- 08 · What a rule costs to keep
What a version is for, and what it has to keep
Tell a save-history apart from a revision, add the one field that makes either of them evidence, and price the discipline against the claims it settles.
Lesson 5 of 8 · 15 min
The question a claim asks
In August, Halverton raised a claim on WB-2519, a style shipped the season before. The pocket bags in the bulk were shallower than the sealed sample. 3,180 pieces at 12.60 FOB. Halverton proposed a 22% markdown allowance: USD 8,814.96.
Tanvara's answer was simple. The bulk was made to the tech pack. The pre-production sample was approved on 14 March. So the whole claim comes down to one question, and it is the question this lesson exists for:
What did the tech pack say on 14 March?
Nobody at Tanvara could answer it. The file had been edited in place twenty-three times between January and June. There was a current version. There were no older ones. And the current one said what the bulk was made to — which is no help at all when the claim is about a change.
A mailbox saved them
Aziza Okasha found it. Revision C had been emailed to the sampling room's shared mailbox on 6 March. The mailbox still had it, because nobody had ever cleaned it out. Revision C showed the pocket bag at the depth the bulk was made to. The claim was settled at nothing.
The search took thirty-one days and eighteen hours of work: USD 255.60.
Now be honest about what happened, because the easy conclusion is the wrong one. Tanvara's record of what it had promised survived by accident, in one mailbox's retention settings. They did not have an archive. They had luck. Luck is not a control. It is a thing that has not failed yet.
It failed three weeks later, on a second claim on the same style: fabric weight, 268 gsm against a specification that at some point had said 275. That figure had only ever lived in the system. It was edited in place and never issued to anybody. There was no mailbox to rescue it.
| Claim | Exposure, USD | Outcome |
|---|---|---|
| Pocket bag depth, 3,180 pieces at 12.60 | 8,814.96 | Settled at nothing, from an email attachment |
| Fabric weight, 2,640 pieces at 13.50 | 3,920.40 | Conceded in full |
History is not a revision, and neither one is evidence
Three different things get called "versioning". They answer three different questions. Only the third one settles a claim.
A save-history is every keystroke the system happened to record. It is nearly free to keep, and nearly useless here. Twenty-three saves do not tell you which one anybody looked at. A history answers what changed. It cannot answer what did we agree to.
A revision is a state you froze on purpose, named, and sent out: Revision C, released 6 March, sent to the mill and to the sampling room. It answers what did we commit to. It is the thing Tanvara did not have and recovered by accident.
The decision-to-revision link is the field almost nobody keeps. On the approval itself, write down which revision it was approved against. Without it, even a full revision archive cannot answer the claim. You have six frozen states and no way to say which one the 14 March signature sat on top of. A revision list without that link is a filing cabinet, not evidence.
| What it is | The question it answers | Kept at Tanvara before this |
|---|---|---|
| Save-history | What changed, and when | Partly, by accident |
| Revision | What did we commit to and issue | No |
| Decision-to-revision link | Which state was this approval made over | No |
What the discipline costs, and what the link costs
A revision is not free, and the cost is not storage. It is the routine: freeze the file, write down in words what changed, tell the people holding the old one, and record who now has which. At Tanvara that takes about eighteen minutes.
Thirty-four styles, six revisions a season, two seasons. That is 204 revisions a season, 408 a year, 61.2 hours a season, USD 1,738.08 a year.
Against that: 12,735.36 of claim exposure in a single quarter, and a quarter of that exposure was survived by luck. 7.3 times a full year of the discipline, in three months.
Then the field. Adding approved against revision to the approval record takes about eight seconds. There are about 140 approvals a year. USD 4.42 a year.
That pair of numbers is the lesson. The 1,738.08 buys nothing without the 4.42. The 4.42 is impossible without the 1,738.08. A revision archive nobody can point a decision at settles no claims. A link that points at revisions which do not exist points nowhere. Factories buy the expensive half, because it looks like the serious half. Then a claim arrives, and they find it answers a question nobody asked.
What a revision has to carry to be usable
Four things, and the last one is the one that gets left out.
- A name people can say out loud. Revision C, not a timestamp. If people cannot say it, they cannot tell you which one they used.
- A date of issue — the day it went out, not the day it was edited.
- What changed, in words. A file-to-file difference is not a change note. It shows you that a number moved, and never why. "Pocket bag depth reduced 2 cm at the buyer's fit comment of 4 March" is a change note.
- Who was told. The mill, the trim supplier, the sampling room, the buyer's technologist. This is what turns a revision into a shared fact. And as the pocket-bag claim showed, the copy that settles an argument is usually the one held by somebody outside your company. Knowing who holds which revision is how you find it on purpose instead of by luck.
Check yourselfYour system keeps every change automatically. Are you covered?Show the answer
For "what changed" yes; for "what did we commit to" no, and it is the second one a buyer asks. Automatic history has no concept of issue: it cannot distinguish a typo corrected at 09:14 from the state that was sent to the mill and cut from. Add two things and the automatic history becomes useful — a way to mark a state as issued, and a field on every approval naming the state it was made over. Both are cheap. Neither appears by itself, because a system that records everything has no reason to think one state matters more than another.