How to Build an AQL 2.5 Sampling Calculator Into Your Sourcing Workflow

Every sourcing team answers the same question repeatedly: how many units get examined, and what count ends it. The answer takes about ninety seconds to find in a table and somewhere between one and three days to obtain through correspondence, and it then gets written into three different documents by three different people.

A calculator fixes this not by being clever but by being available. Put it where the decision is made, have it produce the sentence that belongs in the order, and the question stops being asked because it has stopped being open.

Why Build One Rather Than Look It Up?

Because looking it up is where the mistakes live. Band boundaries are the usual culprit — a lot described as 500 pieces and one described as 501 sit in different rows, and nothing about either number announces it. Reference tables are also revised, and versions multiply quietly.

The second reason is consistency. Three people looking up the same lot will produce the same number most of the time; the value of a calculator is being right every time, and being able to show later which version of the logic produced a plan nobody remembers agreeing.

There is a quieter benefit too. Looking something up in a table is an act of interpretation — somebody decides which column applies — and that decision is made least carefully on the occasions needing it most. Encoding it removes the interpretation step rather than merely documenting it.

Third, it moves the decision into the workflow. A number that requires opening a document gets approximated; one that appears where the booking is made gets used — and used consistently, which is the property that ultimately matters.

What Inputs Does the Calculator Need?

Three, and each needs to be defined carefully rather than collected casually. The definitions cause more trouble than the arithmetic ever does.

How Are the Code Letters Derived?

Lot size determines the band, the band and the inspection level determine the code letter, and the code letter determines the sample size. That is the entire first lookup, and it is a table rather than a formula.

Note the structure rather than memorising the rows. Sample sizes step rather than scale: doubling the lot does not double what gets examined, which is the single fact about this scheme most buyers misremember. It is why a very large lot is examined at a very small proportion — and why explaining that to somebody expecting the opposite takes longer than producing the number does.

Encourage the builder to store the table as data rather than as logic. A hard-coded ladder of comparisons is harder to check against the published source than a plain row list, and the difference shows the first time somebody needs to verify a boundary.

Where Do the Accept and Reject Numbers Come From?

From the second lookup: code letter and acceptable quality limit together select accept and reject pair from the appropriate table. The acceptable quality limit moves the pair; the code letter moves the sample size, and neither does the other's job.

There are three defects in most programmes, each with its own acceptable quality limit, so a complete calculator returns three pairs rather than one. Where it returns one, it has quietly applied one requirement to three distinct classes — usually making the plan looser than anyone intended.

The critical class is handled differently again, and this is where most implementations go wrong. Zero acceptance is not a row in the same table; it is a rule that overrides everything else whatever the counts say. Encoding it as a very small acceptable quality limit produces a plan that looks plausible and is not the one anybody agreed.

Take the reference lot this programme quotes: 500 pieces sits in the 281-500 band, giving code letter H and 50 units at Level II. Against AQL 2.5 that accepts three majors and rejects on the fourth. The same lot against AQL 1.5 accepts two, and against AQL 4.0 accepts five — which is why the level changes something and the sample size does not.

How Do You Encode the Switching Rules?

As one piece of state carried between lots, not as an attribute of each lot. The scheme is a continuing series, so what the previous lot did governs how this one is examined, and a calculator that begins from nothing each time is silently wrong in the same direction every time.

Implement it literally: store the last N results with the programme rather than assuming anybody will remember. Buyers frequently believe a programme is in tightened when it has already returned, or vice versa, because the memory of the last failure is louder than the count.

Show the state on the output. A plan that does not say whether normal, tightened or reduced applied is a plan somebody will read as normal — because that is the assumption everybody makes when nothing states otherwise.

What Does a Worked Example Look Like?

Take a lot of 500 pieces with the three classes this programme uses, and the output should be three sentences rather than one number. Each sentence is what goes into the order.

Then add the practical fields a buyer actually uses: waiting time, what happens next for each outcome, and who decides. Those are not part of the standard, but they are what turn a number into something somebody can act on.

Include a line covering what the plan does not cover, because this trips people repeatedly. Fifty units tells you about the lot; it tells you nothing about any individual unit, including the one that later fails. Saying so in the output prevents the argument that follows.

Where Does the Logic Go Wrong?

Five places account for nearly everything, and none is hard to guard against once you know them.

• Band boundaries handled with the wrong comparison — a lot size equal to the upper bound belongs in that band, not the next.
• Order quantity used when several lots were presented for inspection separately.
• Switching state forgotten, so a programme in tightened is being examined as though nothing had happened.
• One acceptable quality limit applied to all three defect classes rather than one each.
• Double and single results compared directly, which they are not — different expected sample sizes, different conclusions.

Guard them with tests rather than care. A dozen assertions comparing output against the published tables at each band boundary will outlive whoever wrote the calculator, which is precisely the point.

One more that deserves its own test: verify that a plan produced for one level is not accidentally applied at another. Inputs arriving from different documents get mixed more often than anybody expects, and the result is a coherent-looking plan built from two different requirements.

How Should the Output Be Presented?

As a sentence rather than a number. "Lot of 500 pieces, Level II, code letter H, 50 units: accept up to three majors and five minors, none critical" is something a buyer can paste into an order, and the components each remain visible so nobody can misread it.

Show the inputs used. A result presented without the level and state that produced it invites somebody to assume different ones, at which point the number becomes misleading rather than merely unhelpful.

Put a date and a version on it. Plans survive long enough for somebody to ask later which logic produced them, and the answer needs to be discoverable rather than reconstructed.

What Should the Calculator Not Do?

Decide the level. Choosing General Inspection Level II against Level I or III is a commercial decision about risk, and a tool that picks one has quietly made a decision somebody else owns. Present the alternatives and their consequences; do not choose.

Nor should it set the acceptable quality limit. That comes from the programme, per defect class, agreed in writing. The calculator takes it as given and applies it consistently, which is the whole job.

And it should not quietly round. Where inputs do not map cleanly — a lot spanning a boundary, a quantity not yet confirmed — the calculator should say so rather than producing a plausible number. Plausible wrong numbers are worse than no answer, because nobody ever thinks to check them.

How Do You Validate It?

Against the published tables rather than against itself. Run every band, at every level, for each defect class, and compare line by line. This is tedious, takes an afternoon, and is the difference between a tool and a liability.

Keep those expectations as executable assertions. Standard tables are revised occasionally and always reissued; a pinned set of expectations means a change announces itself rather than quietly altering plans nobody re-read.

Validate the boundary behaviour specifically, including the transitions between states. A calculator that handles every row correctly but never tightens will pass routine checks while quietly giving the wrong plan to exactly the programme that most needed attention.

Finally, run one manual check against the table each time the tool is changed. Not because the tests will fail — but because nobody has ever regretted reading the source table once more.

How Does It Fit Into the Wider Process?

Then let it feed the rest. The plan it produces is what goes into the enquiry, what the booking references, what the inspector applies, and what the report must state — one number, generated once, appearing correctly in four places.

That last point is the whole value. This programme quotes bulk production at 35-50 days from written sample approval, and commitments made inside that window leave no room to re-derive a plan somebody already agreed. Having the number available at the moment it is needed is worth rather more than having it correct somewhere else nobody looks.

Frequently Asked Questions

People Also Ask