Inspection and Checklist Result Data Model

Key takeaways

• An inspection result is three levels, not one: the template (what to check), the round (one dated run of it on one asset by one person) and the result line (one answer to one check).
• A check is not always pass or fail. Five result types cover a plant: boolean, numeric reading, value inside limits, a choice from a fixed list, and free text.
• A failed check does not raise a work order by itself. A person decides, and the link has to be stored in both directions or the audit trail is half missing.
• Skipped, not applicable and missed are three states. Worked below: one round of 14 checks scores 100.0%, 71.4% or 91.7% depending only on which of the three you recognise.
• Worked below: one month of rounds is 78.9% compliant counted by round and 83.5% counted by check line, a gap of 4.6 points carried by exactly 58 answered lines.

Three levels, not one

Every plant produces thousands of these records a month, and almost nobody specifies them. That is why they end up as free text nobody can query.

An inspection, an operator round and a preventive maintenance checklist are the same shape of record. They differ in who runs them and how often, not in how they should be modelled.

The template lives for years and changes rarely. The round lives for one shift, and the result lines it carries must never change again.

Most bad implementations collapse two of these into one. Each collapse destroys something specific.

The third collapse is the common one. A round stores a status and a free text note, and the fourteen individual answers exist only inside a sentence.

The fourth is the expensive one. If the tolerance lives on the answer rather than on the check, two operators can disagree about the limit and both records look valid.

What this page covers that the plan page does not

Our preventive maintenance plan data model owns the rule that decides when work falls due, the task list behind it and the four trigger types. It stops at the point where a job is raised.

This page owns the record produced when somebody actually walks the route: the round header, the typed answer to each individual check, and the arithmetic that turns those rows into a compliance number.

The repair side belongs elsewhere again. How a breakdown is coded after the fact is in our equipment failure record data model, and the surrounding tables are in the CMMS data model.

The checklist template

The template is the instruction set. One template serves every asset of the same class, which is why its checks name components rather than tags.

Two fields carry more weight than they look. version and version_valid_from are what let you answer the only question an auditor actually asks.

That question is what the instruction said on the day, not what it says now. Stamp the version onto every round at the moment it starts, and never edit a published version in place.

asset_state is the field plants add after their first argument. A vibration check on a running machine and a guard check on a stopped one cannot sit in the same round unless the template says which state it assumes.

The check definition

This is one line of the template, and it is where a checklist stops being paper. Every field here exists so that the answer does not have to carry it.

allows_na and allows_skip are separate on purpose. A check that can legitimately not apply is a different thing from a check somebody could not reach today.

Set both to No on a statutory check and the round cannot be closed without a real answer. That is the only reliable way to stop a safety line being quietly waved through.

Typing the answer

A check is not always pass or fail. Forcing every question into two buttons is the single biggest loss of value in inspection data.

Boolean is right for a state that genuinely has two values: guard fitted, light on, leak present. Choice is right when the answer is a condition grade rather than a verdict.

A three point grade (Good, Worn, Replace) tells a planner something a pass never will. It is the cheapest upgrade available to an existing checklist.

Why a number stored as text is lost

Take bearing temperature on the main drive of FIL‑01, with a target of 55 °C and limits of 40 and 70 °C. The operator measures 66.0 °C.

Stored as In limits, that reading is inside tolerance and the check passes. It is also 11.0 °C above target and only 4.0 °C below the upper limit.

Stored as text, the row reads "OK" and both of those facts are gone forever. Nothing can recover them later, because the number was never written down.

Now put six identical fillers side by side on the same day. Five read between 54 and 57 °C and this one reads 66.0 °C, which is 9.0 °C above the highest of the other five.

All six pass. Only the typed version makes the outlier visible, and only the typed version can still be charted twelve months later.

The same reading is what a condition based maintenance rule needs as its input. A checklist that answers in words cannot feed one at all.

Keep a free text note field beside every typed answer, because people see things no field anticipated. Just never let the note be the only place a value lives.

What typing actually costs

The cost is real and worth stating plainly. A boolean check needs one column on the result line, and a numeric check judged against limits needs six.

The fourth row is the one that bites eighteen months in. If limits are read live from the template, tightening a tolerance retroactively turns yesterday's passes into failures.

Copy lower_limit, upper_limit and uom onto the result line at the moment of answering. A result must be judgeable on its own, without joining back to a table that has moved on.

The round

The round is one dated execution: one template version, one asset, one person, one window of time. It is the row that proves the work happened.

Keep sched­uled_for separate from started_at. Without it, a round due on the night shift and walked at ten the next morning looks perfectly on time.

A round that was never started still needs a row. A missing row is indistinguishable from a round nobody ever scheduled, which is how a whole shift disappears from a compliance report.

Performed and recorded are two different times

This is the field pair almost every home grown checklist misses, and it is the one that decides whether the data means anything.

Store one timestamp and you have given up the ability to tell the two apart. A whole round can then be filled in at the end of the shift from memory, and nothing in the data objects.

The gap between them is worth deriving and keeping: entry_lag_minutes. Small lags are normal, and a pattern of large ones is a finding about the process, not about one person.

The shape of the evidence is simple. A round of 14 checks whose result lines were all written inside 95 seconds averages 6.8 seconds per check, which is 95 divided by 14.

The same round genuinely walked in the estimated 22 minutes gives 1,320 seconds across 14 checks, or 94.3 seconds per check. Those two numbers describe very different mornings.

Neither number proves anything on its own, and that matters. It is a question to ask, not a verdict to issue, and the answer is often a broken route rather than a dishonest operator.

The result line

One row per check per round. This is the table that grows to millions of rows, and the one worth getting exactly right.

in_limit must be derived from the value and the copied limits, never entered. A typed in_limit flag is an override that survives every later correction of the reading.

Result lines are evidence, so they are append only. A correction is a new row with a link to the one it supersedes, not an update in place.

Skipped, not applicable and missed

These are three different things and they are almost always stored as one. Each does something different to a compliance percentage, which is exactly why they get merged.

The rule that follows from the table is short. Not applicable leaves the denominator, skipped stays in it as a closed line, and missed stays in it and counts against you.

Not applicable needs guarding, because it is the easiest outcome to abuse. Require a reason_code, allow it only where the check definition permits it, and report its rate per check every month.

One round, three scores

Take round RND‑2026‑0912‑C on line PKG‑2, a 14 check operator round. One line was genuinely forgotten.

The rows add up: 9 plus 1 plus 2 plus 1 plus 1 equals 14. Now score the same round three ways.

The third line is the honest one: the two not applicable lines leave the denominator, and the skipped line counts as closed because it carries a reason. That leaves 11 of 12.

The spread is 28.6 points on a single round, which is 100.0 minus 71.4. Nothing about the plant changed between those three numbers.

The first rule is the dangerous one, because it reports 100.0% on a round with a forgotten check in it. If your inspection compliance never drops below the high nineties, check what the denominator is doing.

The out of limit rule

Every check definition needs a field that says what a failure sets off. Without it, a failed check is a row nobody is obliged to look at.

Be honest about the limit of this field. A failed check does not turn into a work order on its own, and any model that pretends otherwise is selling you something.

A person looks at the reading, decides whether it is a fault or a bad measurement, and raises the job. The system's part is to make that decision unavoidable and to record who made it.

There is a good reason for the human step, beyond caution. A single out of limit reading is often a sensor, a thermometer held against the wrong surface, or a machine that has been running for four minutes instead of forty.

The link has to run both ways

One failed reading can end up producing more than one job, weeks apart. One job can be raised from three failed checks in the same round.

Store only the forward direction and you can ask which readings were acted on, but a technician opening the job cannot see the number that caused it. Store only the reverse and the opposite happens.

The direction you left out is always the one somebody needs. Because the relationship is many to many, the clean answer is a small link table holding both keys plus linked_by and linked_at.

That last pair is the audit trail. It records that a human being looked at an out of limit reading and made a call, which is the fact an auditor will ask you to evidence.

What happens to the job after that is a different model again, covered in the CMMS data model and, for the repair itself, the equipment failure record.

Worked example: one month of operator rounds

One packaging line, PKG‑2, September 2026. Template CHK‑07 has 14 checks and runs once per shift, three shifts a day, thirty days.

Scheduled rounds are 3 × 30 = 90. Scheduled check lines are 90 × 14 = 1,260.

1. What happened to the rounds

The rows reconcile: 71 plus 9 plus 10 equals 90. The ten that never started are 11.1% of the month, which is 10 divided by 90.

2. What happened to the check lines

The 71 completed rounds carry 71 × 14 = 994 answered lines. The 9 partial rounds carry 126 lines between them, of which 58 were answered and 68 were not.

The 10 rounds that never started contribute 10 × 14 = 140 unanswered lines. Total answered is 994 plus 58 = 1,052.

Those reconcile too: 1,052 plus 68 plus 140 equals 1,260. Now split the answered lines by outcome.

Again the rows add up: 961 plus 27 plus 44 plus 20 equals 1,052. The failure rate on answered lines is 27 ÷ 1,052 = 2.6%.

Of those 27 failures, the team raised 11 work orders and closed 16 on the spot with an adjustment or a top up. 11 plus 16 equals 27, and every one of the 11 carries the result line that caused it.

3. Compliance, two defensible ways

Both definitions below are honest and both are used in real plants. They are computed from exactly the same rows.

The gap is 4.6 percentage points, which is 83.5 minus 78.9. In counts it is exactly the 58 lines answered inside the nine partial rounds.

You can prove that the gap is those 58 lines and nothing else. Score the partial rounds as if they had answered nothing, and the line based number becomes 994 ÷ 1,260 = 78.9%, identical to the round based one.

So 58 ÷ 1,260 = 4.6% of the month's check lines is the entire difference between the two headline figures. The definition moved the number, not the team.

Neither definition is wrong, and a plant needs both. Round completion tells you whether the route is being walked, and line completion tells you whether it is being walked properly.

Publish the numerator and the denominator beside every percentage, always. A compliance figure with no counts next to it cannot be checked, which is the same discipline our OEE calculation guide applies to availability.

Where these rounds sit against shifts, and how a due date maps onto a night shift that crosses midnight, is covered in the shift calendar data model. A round that changes hands mid task belongs on the shift handover checklist.

Five questions to ask a vendor about inspection data

Ask for a demonstration in their system rather than a yes. Each of these takes under five minutes to show.

1. Show me one check answered as a number with limits. Then export twelve months of that one check as rows, not as a screenshot or a PDF.
2. Edit a template that has history. Change a tolerance, then open a round from three months ago and tell me which limits it shows.
3. What are your outcome codes? Show me not applicable, skipped and missed as three distinct values, and then show me the compliance formula that uses them.
4. Do you store performed and recorded separately? Answer one check now, save it in ten minutes, and show me both timestamps on the row.
5. Take me from an out of limit reading to a job and back. I want the job to show the number, and the reading to show the job, with who linked them and when.

Before a shortlist, read what is a CMMS and equipment maintenance software. For the assets these rounds are walked on, see the asset hierarchy data model.

How Fabrico helps

Fabrico is an OEE platform with a full CMMS built in, and part of this model is in the product today.

Preventive work runs from recurring templates with conditional tasks, on an annual plan view, with approval workflows, work shifts and allocation. Your team works from the iOS, Android or web app and scans a QR code on the machine or the part to open the right card.

Push, in-app and email notifications with smart rules carry the alert when something is due or late, and the audit log keeps the record of who did what. Analytics export to Excel, and the AI assistant answers questions about one machine's history in plain language.

Here is the honest boundary. Fabrico supports recurring templates and conditional tasks, and it does not advertise a typed inspection result with units, tolerances and a derived in-limit flag, so treat everything in this article about result typing, outcome codes and both-way links as a specification to test against your shortlist rather than a feature list.

Two more things Fabrico does not do: a failed check never opens a job on its own, because your team raises and confirms every work order, and failure forecasting is not a standard feature.

Want your inspection rounds stored as data instead of as sentences? Book a 30 minute demo with a Fabrico consultant, no commitment, or contact us with your questions.