Version drift occurs when different people rely on different states of the same project. The drawing may be current while the access report describes an earlier layout. The ledger may show a requirement as checked even though its evidence was replaced yesterday. Revision control makes those relationships visible; it is not simply a habit of adding dates to filenames.
Start by distinguishing document identity, revision and issue purpose. The identity stays stable as the document evolves. The revision identifies a particular state. The issue purpose explains why that state was shared, such as coordination, review or submission. Do not let a revision label imply authority acceptance unless there is a separate, genuine decision record supporting that status.
Record change as a connected event
Each revision entry should identify what changed, why, who prepared it, who checked it and which earlier state it replaces. Link the entry to the originating issue or instruction. A brief description such as “layout updated” is rarely enough to guide impact review; name the affected spaces, interfaces or schedules where practical.
A useful conceptual reference is the World Wide Web Consortium’s PROV family of specifications, which describes provenance through entities, activities and agents. You do not need to implement a formal provenance system to benefit from the distinction. A file is an entity, a review is an activity and a responsible person or organisation is an agent. Keeping those records separate helps explain how a decision was reached.
- R01 / Initial coordination issueRegister the evidence set and record which requirements have been reviewed.
- R02 / Design changeDescribe the change, identify dependencies and reopen affected findings.
- R03 / Reviewed replacementRecord checks against the replacement, then confirm the intended issue purpose.
- Submission snapshotFreeze an indexed bundle and preserve the receiving system’s receipt.
Reopen checks by impact, not habit
When a document changes, inspect its requirement links and references from other documents. An altered entrance arrangement may affect an access narrative, a fire strategy drawing or a form response. A revised address might require an administrative correction without reopening unrelated technical calculations. Use the nature of the change to define the review scope, and record that reasoning.
AI comparison tools can highlight changed text and summarise differences, but they may overlook graphical changes or misunderstand moved content. A longer paragraph is not necessarily a substantive change; a small dimension edit may be important. Treat the automated difference report as an aid to review, not as the definitive account of design impact.
Keep superseded files available but separate
Do not erase an earlier issue merely because a newer one exists. Retain it according to the project’s records policy and contractual obligations, while preventing it from being mistaken for current evidence. A read-only archive, clear status labels and controlled access are more dependable than relying on everyone to remember which email attachment is obsolete.
Backups protect against loss, but they do not establish which issue was authorised for use. The UK National Cyber Security Centre’s small-business guidance and Germany’s Federal Office for Information Security, known as BSI, provide useful security starting points. Apply access controls, recovery planning and proportionate protection to the project environment; a document register alone cannot provide them.
Freeze the submission bundle
Before issuing, generate an index from the actual selected files. List each identifier, title, revision, date and file format. Confirm that references inside reports point to documents included in the bundle or clearly identified external sources. Check the authority’s current upload instructions directly, including any signature, naming, size and page-format rules.
Where useful, compute a file checksum to help detect later changes to the frozen bundle. A checksum can support integrity checking; it does not prove authorship, technical accuracy or approval. Preserve the method used and the resulting manifest with the issue record. Do not confuse this administrative safeguard with an electronic signature or a legal certification.
| Handover item | Record to retain | Limit |
|---|---|---|
| Submission index | Exact document and revision list | Does not establish technical adequacy |
| Issue authorisation | Responsible person, date and scope | Internal authorisation is not authority approval |
| Portal receipt | Reference, timestamp and uploaded file list | Receipt may not mean validation or acceptance |
Continue the trail after upload
Save acknowledgement messages, requests for further information and subsequent responses as linked records. A portal receipt, administrative validation and substantive determination can be different milestones. Use the terminology actually used by the receiving body rather than upgrading “received” to “approved” in your own tracker.
If further information is requested, record the request as a new source, map it to response documents and identify which previously submitted files are replaced. Maintain a clear record of each issue rather than silently rebuilding the original bundle. The resulting trail should let a new coordinator reconstruct what was requested, what was supplied and which revision supported each response.