The Certification That Ends on an Event
A forklift certification in the United States has no expiry date. Nothing in the rule says twelve months, or three years, or renew by the anniversary. What it says is that the operator must be competent, that the employer must certify they were trained and evaluated, and that five specific things oblige you to retrain them — of which four are events rather than dates. Every system built to watch a certificate is built to watch a date arrive. This one asks you to watch for a near-miss.
Competence, certified by you
Paragraph (l) of 29 CFR 1910.178 is unusual among the compliance obligations we have looked at, because the artefact it requires is not issued by anybody outside your organization. There is no authority to apply to and no document to receive. The employer certifies, and the certification is a record you create about your own employee. What is being asserted is competence — demonstrated, in the rule's words, by the successful completion of the training and evaluation the paragraph goes on to specify.
The training itself is three parts: formal instruction, practical training, and an evaluation of the operator's performance <em>in the workplace</em>. That last clause matters for anybody buying a course. A classroom certificate satisfies one of three components, and the third has to happen on your floor, in your aisles, with your loads. And whoever does it — trainer and evaluator alike — must have the knowledge, training and experience to train operators and to judge competence, which is a requirement about a person you may or may not employ.
Five things that end a certification
Paragraph (l)(4)(ii) lists them, and reading the list as a data problem is instructive. One of them is a periodic evaluation you can schedule. The other four are things that happen, and the system that would need to notice them is not a calendar.
Each refresher trigger, against what this product could see
| What obliges retraining | A record exists for it | Attributable to an operator | Could fire automatically |
|---|---|---|---|
| Observed operating the vehicle unsafely | No | No | No |
| Involved in an accident or a near-miss | Partly — configurable by you | Partly — configurable by you | No |
| An evaluation revealing unsafe operation | No | No | No |
| Assigned to a different type of truck | Yes | Yes | No |
| A workplace condition changed materially | No | No | No |
| The three-yearly performance evaluation falling due | Partly — configurable by you | Partly — configurable by you | Partly — configurable by you |
Built and maintained Configurable by you, not maintained by us Not built
The fourth row is the one worth pausing on. A check-out records which asset went to which custodian and when, so an assignment to a different class of equipment is already a fact this product holds — the asset carries an indexed category and the movement carries the person. It is the only one of the five that is sitting in the database waiting to be asked. The second row is a partial because an asset can be marked damaged with a reason and a photograph, which is sometimes the same event seen from the equipment's side.
Nothing here is a criticism of a date-watching design. A date-watching design is correct for the vast majority of compliance artefacts, which is why this product has several of them and why they work. The observation is narrower: an obligation whose triggers are mostly events cannot be met by a mechanism whose only input is a date, however well that mechanism is built. It needs a different input, and the input it needs is a record of something happening to a person.
Four fields, and the fourth is the interesting one
Paragraph (l)(6) is one sentence long and it is a schema. The certification shall include the name of the operator, the date of the training, the date of the evaluation, and the identity of the person or persons performing the training or evaluation. Two dates, not one — training and evaluation are separate events and the rule wants both. And the fourth field is not a signature. It is an identity: who judged this person competent.
The certification, field by field, against records we hold
All four required fields can be recorded today, on the employee, on the custodian record or as a document with an expiry date, and each of those is reportable and exportable. What none of them does is bound the authorisation to a class of equipment, or stop a check-out.
The reminder machinery is aimed correctly here, for once
We wrote in <a href="/blog/the-reminder-that-only-knows-about-people">Extending Expiry Reminders Beyond Employees</a> that this product has a working document-expiry reminder — it reads a date, respects your notification settings and warns thirty days out — and that it is filtered to employee and employment-contract attachments, so an equipment insurance certificate gets silence. This certificate is about a person, which makes it the one case where that filter is pointing at exactly the right records. Put the operator certification in the vault against the employee with an expiry date on it and the reminder works today. What the reminder cannot do is know which trucks it covers, or fire on a near-miss.
Every certificate this product can watch has a date on it. This one has a name, two dates, an assessor and a scope — and the thing that ends it is usually something that happened on a Tuesday afternoon.
Two axes of permission, and this rule needs three
Whether a particular asset can be checked out to a particular person is decided in one place in this product, and it is worth being precise about what that decision consults. There are two inputs. The first is the acting user's role permission — <code>checkout_assets</code> for a check-out, <code>transfer_assets</code> for a transfer, and so on across all eight movement actions. The second is the asset's own state: retired assets cannot move, a quantity pool has to use the pool actions, an asset that is already out cannot be checked out again, and a damaged one is refused with its status named in the message. The custodian is consulted once, and only for presence — whether there is anybody to check the thing in from.
So the model is: <strong>who you are in the organization</strong>, and <strong>what state the thing is in</strong>. Paragraph (l)(1)(ii) asks for a third axis — <strong>what this person is authorised to operate</strong> — and it asks for it as a precondition, prior to permitting the employee to operate the truck at all. A role permission is close but is the wrong shape: <code>checkout_assets</code> is held by a job function and applies to every asset in the register, where the rule wants a fact about one person and one class of equipment.
A person who can hold equipment, as a record in their own right
A custodian carries a code, an employee number, a job title, a department, a location and a link to an employee and a login.
A movement that records who took what, when, and in what condition
Eight movement actions, each permissioned, with a custody signature and a condition note at hand-off.
A class of equipment as a filterable property
Assets carry an asset type and a category, both indexed per organization, so a fleet can be grouped by kind.
A dated document against a person, with a reminder before it expires
The vault holds an expiry date and a daily command warns thirty days out, gated by your own notification settings.
A certification bounded to a class of equipment
A qualification held by a person and scoped to the asset categories it authorises, rather than a date on a document.
A competency consulted when custody changes
The check-out gate reads the actor's role permission and the asset's status, so a third axis for the receiving custodian would be an addition to that decision.
A qualification ended by an event rather than a date
A near-miss, an unsatisfactory evaluation or a change of equipment class marking a certification as requiring refresher training.
The assessor recorded as a person
The rule asks for the identity of whoever trained or evaluated, which is a relation to a person — including an outside assessor — rather than a name in a field.
One more thing belongs on that list and has been written up already, so it gets a sentence rather than a section: the three-yearly evaluation is expressible as a recurring task at a monthly interval of thirty-six, and the recurrence in this product spawns its successor when the current occurrence is completed. <a href="/blog/the-date-the-examiner-writes-down">The Date the Examiner Writes Down</a> works through what that means for a statutory interval, and the answer is the same here.
A qualification is a small table and one line in a gate
The order below is deliberate: the first item is useful on its own, the second is what makes it a control rather than a register, and the third is what makes it survive the way this rule actually works.
A qualification held by a person
With the four fields the rule names — the operator, the training date, the evaluation date, the assessor — and a scope: which asset categories it authorises.
The gate reading it
A third input to the check-out decision beside the role permission and the asset status, refusing a hand-off of equipment the receiving custodian is not certified on, with the reason named the way the other refusals already are.
An event that invalidates it
So marking a qualification as needing refresher training is something an incident does, rather than something a date does. Four of the five triggers in this rule are events.
The assessor as a relation
A person rather than a string, including one who is not on your payroll, so the question "who signed this person off" has an answer you can follow.
The first two are a table and a condition, and together they turn a register into a refusal. The third is the one that decides whether this is a compliance feature or a filing cabinet, and it wants the automation side of the product to be able to fire on an asset event — which today it cannot, so this is a build rather than a configuration. The fourth is small and we would take it with the first.
Tell us what your operation needsWhat AWRA OpsHub does today
- A custodian as a first-class record, with a code, an employee number, a job title, a department, a location and links to an employee and a login account.
- Eight movement actions, each behind its own permission, with a single shared source deciding which of them an asset can accept and why it cannot accept the others.
- A refusal that names its reason, so a blocked hand-off tells the person what state the asset is in rather than failing silently.
- A custody signature and a condition record at hand-off, so who took the equipment and what state it was in is a record rather than a recollection.
- An equipment class as an indexed, filterable property, on every asset, per organization.
- A document with an expiry date against a person, plus a daily reminder thirty days out, gated by your own notification settings.
- Custom fields on employees, custodians and assets, so every field this rule names can be recorded, reported and exported today.
More we can add to your workspace
- A qualification held by a person and scoped to a class of equipment, so an authorisation says what it authorises rather than only when it was granted.
- A competency read by the check-out gate, as a third input beside the actor's permission and the asset's status.
- A qualification invalidated by an event, so an incident or a change of equipment class marks a certification as needing refresher training.
- The assessor recorded as a person rather than a name, including an assessor who is not on your payroll.
- A separate date for training and for evaluation, as two facts about one certification rather than one date standing for both.
- An incident record attributable to an operator, which is what three of the five refresher triggers would be raised from.
- A trigger on an asset event in the automation builder, which is what would let the third item above be a rule you configure rather than code we write.
Where we point you to a specialist
- We will not decide which of the twenty-three enumerated topics apply to your workplace. The rule lets you omit a topic where you can demonstrate it is not applicable to safe operation of the truck in your workplace, and that demonstration is yours to make and to defend. A safety professional who has walked your floor owns it, and it is the difference between a syllabus and a defensible syllabus.
- We will not certify anybody as competent, and we would not build a screen that reads as though we had. The rule puts the judgement on a person with the knowledge, training and experience to make it, watching the operator work in your aisles. What software can hold is the record of who made that judgement, when, about whom, and for which equipment — and it should make the assessor prominent rather than incidental, because the assessor is the part a regulator asks about.
- We hold a position on where the refusal belongs, and it is at the hand-off rather than in a report. A register that shows an operator uncertified while the check-out proceeds is a record of a problem, not a control against it. A quotation from us for this work puts the check in the same place the eight movement refusals already live, and we would argue against a specification that made it a dashboard.
The first two items are one table and one condition, and they are the whole of what turns this from a filing exercise into a control — we would scope them together and they are small. The fourth and fifth go alongside them at almost no extra cost. The third and sixth are the interesting half of the conversation, because they need a decision about what counts as an incident in your operation and who is allowed to raise one. The seventh is ours to do regardless, and it is the reason the third would otherwise be code rather than configuration.
Our take
If you run powered industrial trucks in the United States, the record you need is not a certificate with a renewal date. It is a qualification with four fields, a scope naming the equipment classes it covers, and five ways of ending — one of which is a calendar and four of which are things that happen. Store the four fields today: on the employee, in the vault, with an expiry date, and you get the thirty-day reminder for free and it is aimed at the right records for once. What you will not get from us yet is the refusal at the hand-off, which is the part that matters, or an incident that invalidates a certification without anybody remembering to go and edit it. Both are small, both are on the list above, and the second of them needs an asset event in our automation builder that does not exist yet.
Tell us what your operators are certified on
If your compliance artefacts are about people and classes of equipment rather than about dates, the useful question is where the refusal lives. We have written about the register-versus-control distinction for purchase orders in <a href="/blog/an-expiry-that-stops-an-order">An Expiry That Stops an Order</a>, and about equipment that is present, working and not lawfully permitted to run in <a href="/blog/statutory-inspection-certificates-southern-africa">Present, Working, and Not Allowed to Run</a>. This is the same distinction, one axis over.
Talk to us about your workspace