Key Takeaways
- When a work instruction changes mid-shift, the question of who acknowledged the old version is a data query, and the system can answer it only if the SOP software stores attestation records at the version level, not at the document level.
- A document-level acknowledgment record collapses all version events into a single entry per person, and it cannot distinguish who confirmed version 3.1 before the shift change from who had not yet seen it at all.
- KC Docs stores acknowledgment as a timestamped, per-person attestation linked to a specific version identifier and publishes new versions without overwriting prior ones, so the record of who confirmed the old version survives the publication of the new one as an immutable, queryable entry.
- When a new version publishes in KC Docs, it automatically re-triggers the acknowledgment workflow for everyone in scope, so the system does not rely on a supervisor to manually track who still needs to confirm the updated work instruction.
- Policy management software built on an immutable version history can produce a per-version, per-person acknowledgment export on demand, generating the answer from stored schema data, with no paper record to reconstruct.
A non-conformance report on cell 4 arrives on Tuesday morning. The work instruction for that cell changed at 14:37 the previous afternoon, and the investigator wants to know who had confirmed the old version. Your policy system shows one acknowledgment per person, with no version attached.
That missing version is a schema decision, and your team made it when the system was implemented. A flat document record, the commonest of those decisions, keeps one confirmation per person and overwrites it the moment a new revision publishes. A version-indexed record keeps each confirmation as its own timestamped entry, tied to the version identifier it belongs to. Only a version-indexed record can still answer your investigator a year later.
The Data Gap a Mid-Shift Work Instruction Change Exposes
Version 3.1 is live at shift start, confirmed by every operator on the line. At 14:37 a quality hold forces a revision, and version 3.2 publishes while people are still at their stations with the old sheet in front of them. For the next 40 minutes your plant holds 2 states at once, with some operators confirmed on 3.2 and the rest still working to 3.1.
What a Flat Acknowledgment Record Discards
A flat record cannot represent those 2 states together. It stores one confirmation timestamp per person per document, so publishing 3.2 overwrites the 3.1 entry. That overwrite matters, because ISO 9001:2015 clause 7.5.3 asks you to keep documented information available, suitable for use, and protected from loss of integrity. A record that overwrites its own history fails all 3 of those conditions for the version your investigator needs.
Check what your own record stores before the next revision publishes:
- Version pointer: Open a single acknowledgment row and confirm that it names a version identifier.
- Publication behavior: Publish a test revision, then check whether the earlier confirmations are still readable.
- Export granularity: Ask for an acknowledgment export filtered to one version and one timestamp, and read what comes back.
- Scope rule: Confirm who the system counts as in scope at the moment of publication, by team, role, location, or hire date.
A supervisor who hand-delivered the revision may remember who was standing there. Your policy management software covers more ground than that supervisor, across several roles, several shifts and several sites, and it has only what its schema stored. Memory and a sign-in sheet leave you with an approximation, which someone then has to attest to in writing.
How Policy Management Software Stores a Version-Indexed Attestation
Software built for this question stores 2 separate entities. The first of those entities is the version, an immutable snapshot taken at one publication timestamp. The attestation is one person's confirmation of one version, holding the person identifier, the version pointer and the moment of confirmation. Publishing 3.2 creates a new version entity and leaves every 3.1 attestation untouched.
The Query Your Investigator Runs
Because the attestation points at a version, the query becomes a filter. You ask for every attestation where the version matches 3.1 and the timestamp is at or before 14:37, and the system returns the confirmed set. Ask the inverse and you get the pending set, everyone in scope minus everyone confirmed. The best compliance management software returns the confirmed set and the pending set from stored data.
Auditors ask for that filter in writing too. 21 CFR 11.10 requires computer-generated, time-stamped audit trails, along with accurate retrieval of those records throughout the whole retention period your quality system defines. NIST SP 800-53 Revision 5 control AU-9 requires those audit records to be protected from modification and deletion. Both describe a record your administrators cannot quietly edit after the event.
Moment | Version state | Acknowledgment status | What the record holds |
|---|---|---|---|
06:00, shift start | 3.1 live, earlier versions archived | Every in-scope operator prompted for 3.1 | Timestamped attestation per person against the 3.1 identifier |
14:37, revision publishes | 3.1 archived, 3.2 live | Re-acknowledgment triggered for everyone in scope | 3.1 attestations preserved, pending rows opened for 3.2 |
15:02, the part goes through | Both versions immutable | Split state, some confirmed on 3.2 and some pending | Confirmed 3.2 rows and open 3.1 rows both queryable |
Tuesday, investigation opens | Nothing overwritten | Historical status read back per person | Self-service export, per person and per version |
Find Out What Your Acknowledgment Record Stores
See how KC Docs ties every confirmation to a version identifier, so a mid-shift revision never costs you the record of who confirmed what.
What the Record Holds at the Moment of Publication
Publication is the moment that decides everything downstream. KC Docs writes each version as an immutable entity, with its own identifier, its own publication timestamp and its own set of attestation rows underneath it. An administrator who publishes 3.2 has no route to edit or delete the attestation rows behind 3.1.
Re-Acknowledgment Fires Without a Supervisor
Once a new version publishes, the acknowledgment workflow re-triggers for everyone in scope. That re-trigger means nobody has to compose a notice, work out which operators are affected, assemble a distribution list or chase the responses that come back late. Audience targeting handles that work. Pending rows open against 3.2 while the closed rows against 3.1 keep their original timestamps.
Those closed rows are what makes the export useful. An investigator can pull a per-person, per-version log showing who confirmed 3.1 at what time and who still had 3.2 open at 14:37. The export runs as a query against stored attestations, so your team needs no IT ticket, no spreadsheet merge and no cross-reference against a separate distribution log.
- Before the next revision: Run the version-filtered export once and keep the output, so you know today what your system can produce.
- At implementation: Require the vendor to demonstrate a pending set for a named version at a named timestamp.
- After an incident: Pull the two version states first, then scope the corrective action record to the operators who were working to the old revision.
What KC Docs Gives Your Quality Team
Work instructions change for equipment conditions, material substitutions, safety observations and quality holds, and some of those changes happen mid-shift. When the investigation opens, your SOP and policy management system either holds the version state or it does not. ISO 45001:2018 clause 10.2 expects a review of whether the corrective action worked, and a blanket re-training says little about that.
KC Docs gives your quality team the narrower answer. Each confirmation is written against a version identifier at the moment it happens, every earlier version stays readable, and the export comes back per person and per version. Your corrective action can then name the operators who were working to 3.1 at 15:02, which is the population the evidence supports.
Frequently Asked Questions
1. What does a "version-indexed attestation" mean in practice for a work instruction?
A version-indexed attestation is an acknowledgment record stored with a reference to the specific version of the document the person confirmed, not just the document as a whole. In practice, it means the system records who acknowledged version 3.1 as a distinct entry from who acknowledged version 3.2, so both records persist after version 3.2 publishes, and the system can return either one in response to a version-state query. KC Docs implements this by assigning each published version a unique identifier that the attestation record references at the moment of confirmation.
2. Does KC Docs automatically notify employees when a work instruction changes mid-shift?
Yes. When a new version publishes in KC Docs, the system automatically re-triggers the acknowledgment workflow for everyone in scope, determined by the document's audience configuration, which can target by team, role, location, or hire date. The notification does not require an administrator to manually identify recipients or send a separate communication. The publication event itself initiates the re-acknowledgment cycle, and the system creates new pending acknowledgment records for the updated version while preserving the closed records for the prior version.
3. Can KC Docs produce a list of who had not yet acknowledged a specific version at a given point in time?
Yes. Because KC Docs stores acknowledgment records at the version level with timestamps, it can determine, for any point in the record history, which in-scope employees had confirmed a specific version and which had not yet done so. The self-service export generates this query result on demand without IT involvement. This is the capability that distinguishes a version-indexed attestation schema from a flat document acknowledgment record, which can only return the current acknowledgment status against the current version.
4. How does KC Docs handle acknowledgment for employees hired after a version was published?
KC Docs applies audience targeting based on current attributes including hire date, so employees who join after a version publishes can be automatically included in the acknowledgment scope for the current version. Their attestation record is linked to the version they confirmed, which may differ from the version a longer-tenured colleague confirmed before the most recent update. Both records are stored as distinct entries linked to their respective version identifiers, and both are retrievable in the version-state export.
References
- International Organization for Standardization. ISO 9001:2015, Quality Management Systems, clause 7.5.3 Control of Documented Information.
- Legal Information Institute. 21 CFR 11.10, Controls for Closed Systems.
- National Institute of Standards and Technology. SP 800-53 Revision 5, control AU-9 Protection of Audit Information.
- International Organization for Standardization. ISO 45001:2018, Occupational Health and Safety Management Systems, clause 10.2.
- Legal Information Institute. 29 CFR 1910.147(c)(4), Control of Hazardous Energy, energy control procedures.