Verification asks whether the action was done. Effectiveness asks whether it worked against the cause that was named. Neither asks whether the right cause was named, which is why a corrective action can pass every box on the form and leave the problem where it was. What the location of a repeat tells you, and why a finding written at the program level still tends to close on one instance inside it.

A verified fix tells you the instance is handled. It tells you much less about whether the same cause is sitting in the process next door, and in a lot of systems nothing at the moment of closure asks. Why a narrow closure is often compliant rather than careless, and where the boundary on somewhere else comes from.

A criterion anybody can answer without going and looking at the work will not produce a deep analysis. Neither will forty narrow ones, for a different reason. Where a usable question actually comes from, and the two passes that will tell you whether yours are still worth asking.

A completed root cause record cannot tell you the difference between a question that was asked and dismissed and a question nobody asked. I built a process that tried to close that gap with more structure than the organization would carry, took most of it back out, and kept the one line that actually does the work.

Most audit programs already compare past results on an element against each other, and usually read the comparison as a count. There is more in it. Trigger audits and calendar audits on the same element do different work, so a finding that appears in both is not simply a finding that appeared twice, and a repeat finding is read by the context the auditor wrote next to it rather than by its recurrence. Here is how the two audits differ, when a repeat is actually a problem, what makes two findings the same finding, and what the trend of results on one element can tell you about how the system handles what it finds.

Management systems add structure on an occasion and remove it on no occasion at all. A bad escape puts a column in the register that week; nothing ever arrives to say the register has grown larger than the work requires, so it stays another year by default. I audit management systems I helped design and implement years ago, and sometimes what those visits produce is a decision to take some structure back out. Here is what an over-built register looks like on a return visit, the four moves that take structure out of one, what has to stay no matter what it costs to maintain, and the question to ask a consultant so you are not handed a system you cannot prune.

Most audit procedures already state the criteria for changing audit frequency and depth. Far fewer programs can produce a decision that used them. The criteria are not wrong — they are boilerplate, and boilerplate is not a property of the writing. A criterion is boilerplate when nobody expects it to produce hard evidence. Something has to carry it into execution: the form people work from, the training they received, or a professional expectation. Any one is enough, and none of them is a guarantee. Here is where the criteria actually belong, who holds the decision, what the record buys you, and how to check your own program this week.

Most audit element lists arrived from somewhere else: a consultant, a template, a course model, or the organization's own process map. All of them cover the system, which is a real requirement met. What does not travel with the list is the choice underneath it. Work divides differently depending on what you divide it against, and no cut is the true one, so someone picked a filter and the choice usually goes unrecorded. Which leaves nobody able to adjust the list when the boundaries fail.

Your audit schedule is not your audit program — it is the half of it that runs on a clock. Most programs also dispatch audits on triggers, which means the calendar audit is the residual coverage instrument rather than the primary one. That has a consequence worth taking: when a triggered audit covers the whole element against criteria you set, and comes back clean, the calendar pass on top of it is redundancy. Here is the test that decides it, the four outcomes it produces, and the two things that never count.

Most audit schedules are built by picking an interval and justifying it afterward. The sequence works better in the other direction: define your audit elements, assess what risk is left on each after the monitoring already covering it, and let the interval follow. Elements at identical criticality can correctly land on different frequencies — and an element moving to a longer interval because its monitoring improved is the system getting better, not the program relaxing.

You do not need an auditor to find out whether your management review is working. The records already exist, and they answer the question better than the meeting does. A short retrieval you can run this week — what changed outside the review, what keeps repeating, and what the conclusion was measured against — plus why a light review is sometimes exactly right and sometimes the whole problem.

A completed evaluation record shows you the answer. It does not show you how wide the question was. An evaluation that considered one area and one that considered five produce records that look identical — which is why widening a review is rarely a matter of collecting more information, and usually a matter of who wrote the criteria and when.

Most management reviews spend their first hour rebuilding the data they were supposed to be evaluating. One contract manufacturer’s quarterly review does not — the analysis arrives with its conclusions already attached, and the room spends its time somewhere only it can go. What that looks like in the record, and the two limits worth naming honestly.

The work before a management review is usually called preparation. The word puts it in the wrong place — as overhead the review costs the organization, rather than as something the organization should already have. Where owners maintain their registers on a rhythm, review-ready inputs turn up as a by-product. Where they do not, two checks will tell you which situation you are in.

Almost nobody postpones a management review because the data is weak — the meeting is scheduled, so it happens on whatever arrives. What happens instead is quieter: the room works around the input it cannot use, reports the portion it covered, and leaves the deficiency out of the record. A stale risk register, a fifth of the register covered, and the three-part specification that session should have produced.

A forty-minute management review can be a sign the system is working, and a three-hour one can be a sign it is not. The analytical depth a review requires is roughly fixed — what varies is whether it gets spent upstream or inside the meeting. Here are the five moves a review has to run, and the one-minute check on your own review pack.

A management review that convenes on schedule, covers its agenda, and produces minutes with assigned actions can still be evaluating nothing. A working review and a hollow one produce identical evidence — the difference lives outside the room, in whether anything changed. Which is why these meetings degrade for years without anyone in them being wrong about anything.

A contract manufacturer can run a mature work instruction system for every step of production and administer its training program out of three people’s heads — same building, same maturity claim. The undesigned half still produces acceptable results, because leadership intuition and commercial pressure both correct work toward effective. What neither can do is tell you whether the result came from the design or from the person. That is the ceiling, and it is why undesigned work gets more expensive every time it changes hands.

Most organizations carry at least one role where the work stops if one specific person is out. That dependency is usually managed the way capable people manage everything — in memory, competently, and for years at a time. It works until it doesn’t, and the reason it fails is not carelessness. Attention has a ceiling, and the part of the risk landscape sitting above it is invisible from inside the head that’s missing it. What assessment, functional redundancy, and a working risk program actually add.

A management routine copied from another organization can work — routines transfer. What does not transfer is the judgment that made the routine worth doing, and without it the routine still runs. It runs cleanly, produces nothing anyone can name, and looks like a discipline problem when it is a resourcing decision nobody made. The diagnostic, and the repair.