Most operators treat training material the way they treat a Word file. There is a current one, and the previous ones are somewhere: an inbox, a shared drive, a folder called old, a site office cupboard. That holds until somebody asks a question with a date in it.
The question is always some form of the same thing. Which version of the procedure was this person actually trained on, in March, at this address. And in a network of more than a handful of sites, the honest answer is usually that nobody can say.
This applies well beyond franchise networks. Contractors with crews on client sites, production groups with several plants, facility companies, retail chains, agencies placing people across dozens of users: any operation where the same instruction has to exist in more than one building has this problem, and certified ones have it in a form that gets audited.
The completion record that cannot answer the follow-up question
A completion record is a claim: this person completed this instruction on this date. On its own it looks like proof, and it survives the first question at an audit or an inspection without difficulty.
It rarely survives the second one. If the procedure was revised in February and the record says someone completed "the safety instruction" in January, the record tells you they were instructed on something. It does not tell you they were instructed on what is currently on the wall. If a colleague at another site completed the same named instruction in April, the two records look identical and describe two different pieces of content.
That is the whole argument for version control, and it has nothing to do with software hygiene. Without a version attached, a completion record proves that an event happened. With a version attached, it proves what the event contained. Those are different claims, and only the second one is worth anything when something has gone wrong.
What the signed document actually has to point at
Belgian law makes this concrete in a way that is unusually useful.
Codex art. I.2-11, second paragraph, 9° requires the employer to organise the onthaal (structured reception and introduction) of every starting worker, to designate an ervaren werknemer charged with guiding them, and to have the designated member of the hierarchical line sign a document under his own name showing that the necessary information and instructions on welzijn op het werk were provided.
Read that as an evidence requirement rather than a formality. A named person is signing a statement about content. If the content behind that statement is untracked, the signature is attached to something nobody can reconstruct: the instructions as they happened to exist on the day, in whichever version that site was holding. Two workers who started six weeks apart may hold identical signed documents describing materially different instruction, and nothing in the file will say so.
Codex art. I.2-21 adds the reason this keeps happening. Training must be repeated and adapted as risks evolve, and is triggered again by a change of function, new work equipment or new technology. In other words, the content is supposed to change. A system that assumes it does not is guaranteed to drift.
In the Netherlands there is no prescribed form of proof at all. The Arbowet does not require a signature and anyone claiming otherwise has invented it. But Arbowet art. 8 lid 4 requires the employer to supervise compliance with the instructions given, and supervising compliance with an instruction you cannot identify precisely is an assertion, not a practice.
VCA question 4.1 assumes the content behind the list stands still
For certified companies the same weakness appears in the audit file.
Question 4.1 is a must question. It requires toolboxmeetings spread across the year covering relevant VGM topics, changes to rules and procedures, and findings from incident investigation. The evidence the scheme asks for is literal: the list of dates and topics discussed, and the attendance lists.
Notice what the topic list is. It is a set of labels. "Working at height", "the revised loading procedure", "findings from the incident at site two". A label is a pointer, and the scheme quietly assumes it points at one thing. When four sites all record the revised loading procedure and two of them presented the version withdrawn a month earlier, the file is complete, the attendance lists are signed, and the record is wrong in a way that no auditor can see and no manager can correct afterwards.
Question 4.1 also names changes to rules and procedures as required content, which means the scheme is explicitly asking you to teach the delta. You cannot teach a delta without knowing which version each site is coming from.
Drift is a deployment failure, not a preference
In practice sites do not decide to run old content. Drift arrives quietly.
A site was mid-rollout when the update landed and finished the old one. A supervisor kept a printed copy because the tablet in that room is unreliable. A manager who left had a local variant nobody knew about. An update was published on the Friday of a week that site spent short-staffed.
Each of those has a different fix, and none of them is a reminder email. What they have in common is that they are only fixable if somebody can see them. A per-site view of which version is currently active, next to which version each person completed, turns four invisible situations into four small operational tasks.
The number to watch is not completion percentage. It is the spread of active versions across the network. One version everywhere means the last change landed. Three versions in fifty sites means the last change is still in progress, whatever the completion figure says.
When a published version turns out to be wrong
This is the case everyone thinks of first, and it is genuinely just one application of the discipline above.
An update goes out on Monday. On Wednesday someone notices step four is ambiguous, or that a value was carried over from the old process, or that a control got dropped in the edit. From that moment every additional completion adds a person who has been correctly recorded as trained on the wrong thing.
Three things have to happen, in this order. Stop the bad version being served, so the number of affected people stops growing. Identify exactly who completed it, which is only possible if completions carry versions. Re-instruct that group specifically, rather than re-blasting the network, which teaches everyone else that your updates are unreliable.
Then write down what happened. Not for its own sake: the note explaining what changed, when it was caught and who was affected is precisely the document that makes the corrected record legible to an auditor a year later. A completion history with a gap and no explanation looks worse than the original error.
Who publishes, and who edits the source
Most bad versions are not authoring mistakes. They are approval gaps: someone with edit rights fixed something reasonable and it went live without a second reader.
Split the two rights. Anyone close to the work can propose a change to the source procedure, because they are the people who notice that reality has moved. Publishing to the network is a separate permission, held by few people, with a second approver required on the content where an error is expensive: safety instruction, hygiene and allergen procedures, anything a client rulebook governs.
Handling a bad version in Aristotl
Find the version that went wrong. Every published version carries a timestamp and a change note. A sudden drop in knowledge check scores on one module is usually the fastest way to spot which release introduced the problem, before anyone reports it in words.
Restore the last good one. Restoring makes the previous version the active one across every location at once. People part-way through see the restored content on the next module; nobody has to be told to stop.
Re-assign the people who completed the bad one. Filter completions by version, select that group, and reassign with a short deadline. Those workers stay flagged until they complete the corrected version, so the export reflects the corrected state rather than the original claim.
Keep the trail. Prior versions stay accessible rather than being overwritten, every completion is tagged with the version completed, and the dashboard shows the active version per location. The export that comes out of it answers the dated question directly: this person, this version, this date, this site.
Pull one completion record from last year
Take any training record from twelve months ago and try to establish which version of the procedure it refers to. Bring the result to a demo, and we will show you the same record with a version on it, which is the difference between a file and evidence.