1. What this stage is for
Verify answers one question: can the people and teams do the required work to the required standard, and how do we know? It comes after Apply because the best evidence of competence is real work, done in bounded conditions. It comes before Adopt because the organization shouldn't make a new way of working normal until it's sure the way works and the people can do it. #28 · #49
Verification is easy to confuse with paperwork. A signed acknowledgment that someone read a procedure, a training completion record, a certificate from a course provider, a status report marked green: each of these is a claim that capability exists. None of them shows it. Verification means observing the work, or its results, against a standard agreed in advance, and being honest about how strong the evidence is. SOP-TRN-01 · SOP-TRN-06 · SOP-GOV-05
The stage covers four things that need verifying, in increasing order of how often they're forgotten: individuals, teams, systems and processes, and the checks themselves. That last one sounds abstract until you read accident investigations, where a check that passed for the wrong reason appears again and again. DGN-GAP-02 · QMS-AUD-02
2. Verify people
Verify competency before project assignment. Before someone works alone on anything consequential, watch them do a representative task to the organization's standard and confirm they can interpret the result. For model-based work, that includes whether they understand what the model is telling them and who is accountable for it, not only whether they can operate the software. The principle is "show me, don't tell me". #28 · SOP-TRN-06 · BM-ROL-04
A judgment scale, not measured data. Each step up adds something the one below lacks: a real task, no help, a standard, and time. LSC-MSR-01 · LSC-MSR-03 · LSC-MSR-04 · LSC-CPD-01
A few rules keep people-verification honest:
- Test on new, job-like tasks without aids. A site engineer should complete an inspection plan for a pour they haven't seen; a technician should isolate an unfamiliar pump. Recognizing the right answer on a quiz is a different skill. LSC-MSR-03 · #45
- Re-test later. Immediate tests mostly capture what people can do while the training is fresh. Re-test at 30 to 90 days, and refresh skills according to how fast they decay. LSC-MSR-04 · SOP-TRN-04
- Check with the AI switched off. If people learned or work with an AI assistant, check periodically that they can still do the core task without it, and that they can catch its errors. PRM-LRN-01 · PRM-LRN-05 · IDE-AI-02
- Read credentials for what they are. Certifications are a competence signal, not proof of practice; licensure hours are a compliance floor, not a measure of competence. Treat both as a reason to verify, not a substitute for it. CM-STD-04 · BM-MAT-04 · LSC-CPD-01
- Nobody operates a control untrained. In finance, safety and plant operations, a control run by someone who hasn't been verified on it isn't a control. FIN-TAL-02 · TAR-SAF-01
Watch for overconfidence. People who have just finished a satisfying training session or game often overestimate what they learned. Debrief from objective records rather than memory, and check performance separately from confidence. GL-13 · GL-02 · GL-14
3. Verify teams and systems
Individual competence doesn't guarantee team performance. Hand-offs, communication and shared understanding fail in ways no individual test will find. Rehearse as a team: tabletop exercises for decisions, technical drills for systems, dress rehearsals for cutovers. Add unscripted events, because a smooth, satisfying exercise is not the same as readiness, and practise the short, structured call-outs that move information under pressure. GL-16 · CS-05 · CS-07 · CYBER-13
Test and commission every system before people depend on it. In events, that means every safety and communication system before the public arrives. In plants and buildings, it means handing over and accepting systems one at a time, with operations accepting each. In digital services, it means checking that service-level objectives still reflect what users care about. SEM-11 · TAR-SU-02 · SWD-SLO-03
Rehearse the manual fallback for critical tasks that a new system or AI now supports, and test full restores rather than backup jobs. The time to discover that nobody remembers the paper process is during a rehearsal, not during an outage. #46 · CYBER-10 · HO-13
Verify procedures before release, too. Test the procedure with the people who will use it, in conditions like the real ones, before it's issued. A procedure that's followed exactly and still fails needs redesign, not retraining. SOP-DES-06 · SOP-GOV-11 · SOP-DES-01
4. Verify the checks
The most dangerous verification failures are checks that pass when they shouldn't. Test the test: for every check the organization relies on, walk through how it's physically performed and ask whether anything other than the target could make it pass. At Lac-Mégantic, the hand-brake test was done with the locomotive's air brakes still applied, so it looked as if the hand brakes alone would hold the train. DGN-GAP-02 · DGN-AST-01
Independent review is only as good as its reach. Scope independent design review to the hazard: the reviewer must be qualified for the work, and the scope and budget must cover the critical elements and the construction stages. At the FIU pedestrian bridge, the peer reviewer wasn't qualified by the state for that category of work and lacked the budget to check the connection nodes or the construction stages, and calculation errors went through. An unqualified reviewer isn't a second set of eyes. DQ-UP-05 · SOP-GOV-02
| Level | Who checks | Example | Blind spot |
|---|---|---|---|
| Self-check | The person who did the work | A modeller runs the agreed rules before sharing | Their own assumptions |
| Independent check | A qualified person outside the task | A peer reviewer checks the connection design | Whatever is outside their scope or budget |
| Independent assurance | Someone reporting to the decision-makers, not the project | An owner's reviewer reports unedited to the board | Whatever they aren't told |
Each level needs the one below it. For high-consequence work, the scope of each level should be written down and checked against the hazards. BM-QA-02 · DQ-UP-05 · OGV-ASR-01 · OGV-GATE-03
Paperwork can be checked and still be wrong. A ticked box isn't a verified outcome. A clean audit isn't proof that there are no nonconformities. And a management system can exist on paper while the work happens some other way, a pattern quality researchers call decoupling. Audit the work, not the binder: trace one feature from requirement to as-built and see whether each step really happened. SOP-CHK-04 · QMS-AUD-02 · QMS-RWK-05 · SOP-GOV-05 · SOP-GOV-09
Verify materials and data that can't be checked later. For safety-critical materials, don't rely on the manufacturer's own test or certificate alone; the Grenfell Inquiry found manipulated tests and certification bodies that were vulnerable to manipulation. Check that a certificate is accredited and covers your use, not just that it exists. DQ-UP-12 · AIG-02 · AIG-03
Finally, verify that corrective actions worked. Don't close an action on the evidence that it was implemented; define the effectiveness check before closing it, and have management review ask whether closed actions actually fixed anything. QMS-CAP-03 · QMS-CAP-02 · QMS-ARC-05
5. Models, schedules and AI
Information products need verification as much as people do, and they're easier to check automatically. On BIM projects, write the data requirements in a machine-checkable form from the start, use rule-based checkers for what those can't cover, and check against the owner's asset information requirements at every stage gate, not only at handover. Expect the common data environment to fall short of the standard and design checks for the gap. BM-QA-01 · BM-QA-03 · BM-QA-04 · BM-CDE-04
Check a schedule's health before you trust its dates. Run the standard checks for missing logic, hard constraints and high float, and read high float as missing logic rather than spare time. A critical path built on gaps looks fine until the gaps close. PCF-SCH-02 · PCF-SCH-03 · PCF-SCH-01
Simulations and digital twins need a budget for verification, validation and stated uncertainty. A model that has never been compared with the real asset is a picture, not evidence. DM-TWN-05 · FAM-TWN-06
AI output needs its own verification discipline:
- Verify every citation in AI-assisted work, and ground AI-generated content in approved sources with an expert's sign-off. AIG-09 · IDE-AI-01
- Test on your own cases before rollout: 30 to 50 real examples from your work will tell you more than any vendor benchmark. PRM-VER-05 · DQ-AI-04
- Show the spread. Run important questions through several models or prompts and look at how far apart they land, rather than trusting one answer. DQ-AI-01 · DQ-AI-02
- Keep a person accountable, and audit AI-assisted work later, blind, to see whether the checks are really happening. DQ-AI-03 · PRM-VER-07
6. Safety-critical starts
Some verification is non-negotiable. In process plants, the pre-start-up safety review must be complete before hazardous materials are introduced, and a unit should never be started with known faults in its safety instruments. At Texas City in 2005, a tower was started up with a level indicator, a level alarm and a control valve known to be malfunctioning; it overfilled, and the explosion killed 15 people. Start-ups and shutdowns are among the most hazardous hours in any plant. TAR-SAF-02 · TAR-SAF-03 · TAR-SAF-01
The same logic applies wherever a mistake can't be undone: a lift, a pour, an energization, a go-live that replaces a system with no way back. Define the verification required before the irreversible step, make it a hold point, and track every time the hold point is bypassed. A bypass is information about the system, not just about the person. QMS-ITP-02 · QMS-ITP-04 · DQ-UP-01
Give gates teeth. A verification gate that has never stopped anything is decoration. Write its criteria in advance, separate the people who decide from the people who advocate, and make "not yet" a respectable answer. When the gate does say no, record the decision and its reasons; when someone overrides it, record that too, with their name. OGV-GATE-01 · OGV-GATE-02 · OGV-GATE-03 · DGN-BIAS-04
Get a second look where the stakes justify it. In one study, about 1 in 5 referral diagnoses ended distinctly different after an independent review. Engineering, finance and safety decisions are not medicine, but the lesson transfers: an independent look, at the evidence rather than the conclusion, changes more than people expect. DGN-BIAS-02 · OGV-ASR-01
7. By team: what verification looks like
Every team verifies people, systems and checks, but the evidence that counts differs. #28 · SOP-GOV-05
Technology and software teams
For software, verification is automated where it can be: tests that gate every merge, staged rollouts with health checks, and service-level objectives reviewed regularly so they still reflect what users care about. For people, verify that new engineers can deploy, roll back and run an incident with the real tools, in a rehearsal, before they're on call. For AI coding tools, pair the rollout with review capacity and tests, because more code without more checking is more risk. SWD-REL-06 · SWD-REL-03 · SWD-SLO-03 · SWD-AI-04
Design, engineering and BIM teams
For engineering work, verification has a professional dimension: the licence holder stays responsible, and reviewers must be qualified for the work they review. Review engineering work throughout the project rather than once before issue, and check information against the agreed requirements at every stage gate. For new staff, verify that they can interpret what a model or analysis is telling them, not just operate the software. PRM-ENG-01 · SOP-GOV-08 · BM-QA-04 · BM-ROL-04
Construction and field teams
On site, verification lives at the hold points. Put hold points at irreversible stages, define hold, witness and review points in the contract, release them with the inspector rather than by phone, and track every bypass. Supervisors verify in the field, and a ticked box isn't a verified outcome. Audit one feature from requirement to as-built now and then; it finds what document audits miss. QMS-ITP-02 · QMS-ITP-03 · QMS-ITP-04 · SOP-USE-04 · SOP-GOV-09
Plants and operations
In plants, verification gates start-ups and changes. Complete the pre-start-up safety review before hazards are introduced, never start up past known instrument faults, and hand over system by system with operations accepting each. For digital twins and analytics, budget for verification and validation, and demand measured, not projected, savings. TAR-SAF-02 · TAR-SAF-03 · TAR-SU-02 · DM-TWN-05 · FAM-NRG-03
Finance and controls
In finance, verify that controls operate, not that they're documented: check the report before you trust it, set thresholds for reviews so they're more than a glance, and watch late, manual and senior entries. Where duties can't be segregated in a small team, supervise instead. FIN-CTL-02 · FIN-CTL-01 · FIN-CTL-05 · FIN-CTL-06
An illustrative example
A design-build contractor preparing to move a 50-metre bridge span in one weekend found that its independent design review covered only the finished structure. The connection nodes and the construction stages, where the span would see its largest loads on the transporters, were outside the reviewer's scope and fee. Nobody had done anything wrong; the scope had simply been set by someone who didn't ask where the hazard was. Extending the review, with budget, to the nodes and every move stage cost a small fraction of the contract. It's the kind of gap that only appears when someone asks what each check actually covers, which is the core habit of this stage. DQ-UP-05 · DGN-GAP-02 · SOP-GOV-02
Common mistakes
- Accepting completion as competence. SOP-TRN-01 · LSC-MSR-01
- Testing only once, straight after training. LSC-MSR-04
- Reviews that stop where the hazard starts. DQ-UP-05
- Closing actions on implementation, not effect. QMS-CAP-03
- A gate that has never said no. OGV-GATE-01
8. Handing it on
Verify hands Adopt a short, honest record: who has been verified on what, by what kind of evidence, and what isn't verified yet. Include the systems that passed commissioning, the procedures that passed field testing, the checks that were themselves checked, and the gaps. A record that says "seven of nine coordinators verified unaided; two need another supervised job" is far more useful than one that says "training complete". #28 · DGN-CNS-01
Define "done" for verification with a rubric rather than a date. If the rubric isn't met, the honest options are more practice, a narrower scope, or a delay. Moving to Adopt anyway is a decision, and like every override, it should have an owner and a record. IDE-DES-04 · OGV-GATE-01
For small organizations, verification is mostly about two habits: watching the first real job before letting someone work alone, and periodically picking one finished piece of work and checking it against the standard from start to end. Both cost little, and together they catch most of what matters. SOP-USE-06 · SOP-GOV-09
The checklist. Show me, don't tell me. Test unaided, on job-like tasks, and again at 30 to 90 days. Check with AI off. Treat certificates and hours as signals. Rehearse as a team, with surprises. Commission systems and test restores. Test the test; scope review to the hazard; audit the work, not the binder. Verify models, schedules and AI on your own cases. Never start up past an open safety review. Record what isn't verified. Then go to Adopt.