Policy version pinning

Atlas

Recording which revision of a source document a module was generated from, so the two cannot quietly diverge.

What is policy version pinning?

Policy version pinning is the practice of recording which revision of a source document a module was generated from. The module carries that revision identifier for its whole life, so the two cannot quietly diverge. Once the source document is superseded, every module pinned to the previous revision is identifiable immediately.

Also called: Version pinning

Why the first policy revision after go live decides this

The question arrives the first time a policy is revised after training has already been delivered. Someone has to establish which completions were recorded against the old wording, and the answer has to come from records rather than from memory of a release schedule. Without pinning, the honest answer is that nobody can tell, which turns a routine policy update into a retraining exercise across the whole population. Pinning reduces that to a query against the completion record.

  • A pinned module makes the scope of a policy revision knowable within minutes.
  • Attestations acquire meaning only when the version attested to is named.
  • Auditors ask which revision was taught, and the record either answers or does not.
  • Retraining can then be targeted at the population the change actually affects.

How policy version pinning works

  • The controlled document repository exposes a stable revision identifier for each source.
  • Generation records that identifier against the module and against each segment derived from it.
  • The identifier is displayed to the learner and stored with every completion.
  • A change to the source raises an event against every module pinned to the earlier revision.
  • Affected modules are regenerated and the superseded version is withdrawn from assignment.
  • The superseded module is retained for as long as completions against it remain in evidence.

How policy version pinning is evaluated

Pinning is assessed on whether a policy change can be traced to the people it affects. Test the following against a revision that has already happened:

  • share of modules carrying a resolvable source revision identifier
  • time to list every learner trained on a superseded revision
  • lag from source approval to withdrawal of the stale module
  • proportion of completions stored with the revision attested
  • count of modules whose pinned revision no longer resolves

Limitations, risks and common failure modes

  • Source documents maintained in a shared drive have no revision identifier to pin to.
  • Generation pipelines record a date instead of a revision, which two edits in a day defeat.
  • A module is regenerated and the earlier version disappears along with its completions.
  • Owners revise a document in place, so the pinned revision silently describes new text.

Related terms

Completion recordThe record of who completed which module, on which version of the source, and when.Controlled documentA policy or procedure under formal version control, where the current revision is the only one that counts.Standard operating procedure (SOP)The document that states how a task is to be carried out, and the source a training module is generated from.Content freshnessHow recently training content was regenerated against its source, and how far it has drifted since.Assessment integrityThe degree to which a score reflects the learner rather than the conditions the assessment was taken under.Automatic question generationProducing assessment items from a source document rather than authoring them separately from it.

All 315 terms