Computed, and unsigned

What this lesson is about

A quality verdict has two halves, and people run them together. There is the arithmetic, which says whether the numbers are inside the limits. And there is the decision, which is a person putting their name to what happens next. This app is unusually good at the arithmetic. On the checks that matter most it is silent about the second half. This lesson shows exactly where the line falls, because an auditor will ask.

Dilnoza finishes the final AQL on ORD-1427 at half past four. She has counted the faults in the sample and measured eight garments. What she does next takes three seconds and produces a record that will still be read in two years.

The measured half

A measurement section is a snapshot of the style's points of measure, taken when the inspection was created. It holds the point, its plus and minus tolerance, and the spec value at every size. Actual readings are recorded against that snapshot, and a reading belongs to a garment, not to a size. A garment is a colour, a size and a number within that pair, so an ecru medium and a sage medium are different garments.

Dilnoza pulls eight ecru mediums out of the cartons and measures three points on each.

Garment four reads 53.3 against an upper bound of 53.0, so it is over by 0.3. Garment seven reads 50.7 against a lower bound of 51.0, so it is under by the same amount. Body length is specified at 68.0 with a tolerance of plus 1.5 and minus 1.5, and garment five reads 69.9, which is over by 0.4. Sleeve length is inside its band on every garment.

Now the part that catches people. The engine does not count readings out of tolerance, and it does not count points out of tolerance. It counts garments. A garment that misses on any point at all is one defective garment. It is counted once, however many points it missed.

So the tally is three garments out of eight, not three readings out of twenty-four and not two points out of three.

From out of tolerance to a suggested action

With that count in hand the engine applies a short, fixed set of rules.

1. Nothing measured at all means the report is incomplete, and the suggestion is hold for review.
2. Every measured garment inside its band, but some points never measured, is also incomplete and also a hold. The app deliberately refuses to pass a report it knows is unfinished.
3. Any garment missing by more than the whole tolerance band is a severe miss, and a single severe miss rejects.
4. Otherwise, more than half the measured garments failing rejects, provided at least two of them failed.
5. Anything left over is a rework.

Dilnoza's eight garments give three failures, none severe, and three is not more than half of eight. The suggestion is rework, and the app prints the working out beside it, naming every garment, its reading, its spec and its band.

Change one reading and the answer changes in kind, not in degree. Had garment four read 54.4 instead of 53.3, it would be 1.4 past the upper bound against a tolerance of 1.0. That is a severe miss, and the suggestion would be reject on that one garment alone.

Why a measurement becomes a major defect

An inspection with only a measurement section lets the measurement decide. An inspection that also has a defect tally does something else. It is the right thing to do, but it is not the obvious one.

Each out-of-tolerance garment is folded into the tally as one major defect, and the AQL plan then decides for the whole inspection. The measurement section is still shown and still lists its findings, but it no longer holds a veto of its own. This is conventional garment practice: a measurement miss is a major, never a critical.

Watch what that does to Dilnoza's lot. Her defect tally holds 8 majors and 9 minors against a plan of accept 10 and reject 11 on majors, accept 14 and reject 15 on minors.

Three garments a few millimetres outside their tolerance turned an accepting lot into a rejecting one. Nobody typed that. The engine's own wording says so plainly: eleven major defects at or above the reject number of eleven, in a sample of 200, at major AQL 2.5.

The precedence, in one pass

Every section captured produces a signal, and the signals are combined by a fixed order of severity rather than by a score.

Any section rejecting makes the whole inspection a reject. Failing that, any section needing rework makes it a rework. Failing that, any section that is conditional or incomplete makes it conditional. Only when every section present passes does the inspection accept. And an inspection with nothing captured at all comes out conditional, never accept, because the app will not clear a lot it has no evidence about.

Read this beside the previous section, or the precedence seems to hand the measurement section its veto back. It does not. On an inspection that has a defect tally, the folded measurement section can say only two things to this ordering. Fully measured, it is informational: it sends no signal into the precedence at all, because the tally now speaks for its findings. Part-measured or untouched, it signals incomplete, which is enough to hold the whole inspection at conditional and never enough to reject it. The reject a measurement can produce on its own exists only on a measurement-only inspection, where there is no tally to fold into.

A checklist behaves the same way. Any item marked fail makes the checklist a rework, naming the items. Items left unanswered while the rest pass make it conditional. A checklist nobody touched is not counted at all.

The half that is not signed

On a measurement inspection there is a genuine gate. Once a verdict exists, Dilnoza can accept the computed suggestion or set a different outcome: passed, rework, rejected or hold for review. Choosing one opens a confirmation panel listing what will happen, and the decision can be recorded only once. The server refuses a decision with no verdict behind it. It refuses a second decision on an already-decided inspection. And it refuses anyone outside quality or the Owner.

That is a proper human gate, and it is worth saying so before the rest of this section.

Now open the final AQL, which is the inspection that decides whether goods leave the building. There is no accept and reject there. There is a button labelled Compute result, and a note under it saying the result is computed from the captured sections and never typed by hand. Press it and a verdict is stored. That verdict is what the shipping gate reads.

The pattern across the rest of the application makes the gap look stranger rather than smaller. A logged defect stores who logged it. A needle or metal-detection entry stores who recorded it and writes a line to the order's activity. A CAPA — a corrective and preventive action — writes a line naming the person when it moves to verified. Marking a supplier certificate verified writes a line to the supplier's activity. The retired AQL screen this module replaced stored a decision timestamp and wrote every step to an activity log with the actor beside it.

And the ship override, which is the act of shipping past a quality gate, writes a line to the order's activity naming every blocker it overrode.

So the act of shipping past a quality gate leaves a better trail than the gate decision itself, which leaves none at all.

Help me reconstruct a quality decision in MerchandiserOS for an audit, and be honest with me about what cannot be reconstructed at all.

I will give you: the inspection number and type; its computed result; the defect counts and measurement readings recorded on it; the decision recorded on it if it has one; the dates showing on the record; and anything in the order's activity log around that time.

Start by separating what the record proves from what it only suggests. In this application a typed inspection stores its computed result and the time it was analysed, and nothing about who pressed the button. A measurement inspection stores its decision value and a modified timestamp, and that timestamp moves whenever anybody edits the grid afterwards. Neither has an activity log or a comment thread. So do not tell me a person decided something unless a name appears somewhere I gave you.

Then tell me which corroborating records COULD carry a name for this event: the order's activity log, a defect entry, a needle or metal-detection entry, a CAPA transition, a ship override, or a comment on the order.

Then give me the account I can honestly give the auditor, in plain sentences, marking clearly which parts are evidenced and which are inference.

Finally, tell me what to start recording now so the same question is answerable next time, and where to put it given the fields that actually exist.