Building a proof-of-concept lab: a test that can be believed

01 / FIELD NOTE

Keep the decision tied to the operating context.

A proof of concept is frequently run as a demonstration, and demonstrations are designed to succeed. Goods are tagged carefully, the reader is positioned where it works, the operator knows what to do, and the system behaves. What that establishes is that the technology functions under favourable conditions — which was never in doubt. It does not establish anything about the operation the business actually runs.

The difference is the question. A proof of concept is worth running when there is a specific decision waiting on the answer, and the answer has to be measurable. Whether a tag can be read through the packaging the supplier uses; whether a full pallet can be counted in the time a forklift pause allows; whether the count is accurate enough to replace the manual process. Each of those is a question that can be answered, and each of them would change what the business does next.

Stating the question first is what makes the rest of the design follow. The objective determines which items are tested, which environment is reproduced, which tag and reader are appropriate, and — most importantly — what result would count as a failure. A trial with no stated failure condition cannot fail, and a trial that cannot fail produces no information.

The scope has to be small enough to control and representative enough to mean something. Small enough that each variable can be changed deliberately and its effect observed; representative enough that the packaging, the material, the stacking and the handling resemble the real case. A test on clean cardboard boxes in an empty room answers a question about clean cardboard boxes in an empty room.

Tag selection is where the physical reality arrives. A tag chosen for a good read on a plain surface may behave differently on metal, near liquid, in a freezer or against the contents of a full pallet. The proof of concept is the right place to test several candidate tags against the actual items rather than to select one from a datasheet and then discover its limitations in production.

Reader and antenna configuration is the second physical decision. Whether the count will be taken by a handheld in a person’s hand or by a fixed reader at a point determines what is being tested. Antenna position, angle and power change the result more than most people expect, and a laboratory test that adjusts them until the read is good has measured the adjustment rather than the system. The configuration should be chosen for the intended installation and then held.

Encoding belongs in the test because it is a failure mode that hides. A tag written with the wrong identifier, or associated with the wrong item in the database, produces a record that is internally consistent and externally wrong, and it will survive every reconciliation until someone tries to use a specific item. Encoding a sample and verifying that each tag resolves to the right item is a step worth doing before the measurement rather than after.

The measurement itself should record more than whether it worked. Read rate is the obvious figure; the time the operation took is frequently the more important one, because a method that reads everything but takes longer than the process allows has not solved the problem. Accuracy, duration, and the conditions under which each was achieved belong together, because a figure without its conditions cannot be compared with anything.

The exceptions are the most valuable output and the easiest to lose. Which tags were missed and where they were in the stack; which reads appeared that should not have; what happened at the edge of the read zone. A test that reports success and discards its failures has thrown away the information that would have shaped the deployment. The negative results are what the next design iteration is built on.

Iteration is part of the method rather than a sign that the first attempt failed. A tag that does not read well in one position may read well in another; a read zone that overreaches may be corrected with power or a shielding arrangement. Recording what was changed and what effect it had is what turns a series of attempts into evidence, and it is what allows the final configuration to be explained rather than merely asserted.

The result should be stated as a boundary rather than a verdict. Not that the technology works, but that it works for these items, in this configuration, under these conditions, at this accuracy and this duration, and with these known exceptions. A boundary is what a deployment plan can be built on, because it says where the method is known to hold and where something else will be needed.

The output of a good proof of concept is therefore a decision, a measured configuration and a list of conditions under which the measurement holds. It is not a demonstration for an audience, and treating it as one is how a project proceeds on confidence rather than evidence and discovers the boundary in production — which is the outcome the exercise existed to prevent.