What should be reviewed before scaling a hardware testing for equipment prototypes project?

The word gets used loosely, and loose definitions produce loose reviews. For an equipment prototype programme, scaling usually means several distinct changes at once, and it is worth naming each one because each asks for different evidence.

It can mean widening the breadth of the prototype: single-function boards or modules become a complete integrated unit, and the object under test changes character. It can mean increasing the count: more units built so that variation between units becomes visible instead of assumed. It can mean extending the duration of observation, from a session that demonstrates function to a long run that begins to expose drift, wear and intermittent faults. It can mean hardening the conditions, moving from a bench with a controlled supply and stable ambient temperature toward representative installation conditions. And it can mean adding repeatability: running the same test more than once so that results can be compared across units, revisions and time.

Each of those has its own trigger, cost, and failure mode. A review that treats "scaling" as one decision tends to over-commit in whichever dimension the champion engineer cares most about, and under-commit in the others.

The first review question is not whether the prototype passed. It is whether the pass is attributable. A result that cannot be traced back to a defined setup, a defined input, and a defined observation is a story, not data, and stories do not survive being generalised across several units.

For each major result the programme is relying on, the review asks for the provenance: which revision of the build produced it; which interface was used and in what mode; what the input condition actually was rather than what it was assumed to be; whether the measurement was made once or repeatedly, and if repeatedly, how the repeats compared; whether a deviation was observed and then quietly accepted without a decision being recorded. Where the setup was improvised -- a temporary supply arrangement, a hand-made fixture, a bypass that stayed in place -- the result belongs in a lower evidence class than the write-up implies.

The honest output of this section is usually a classification: results that are solid, results that are suggestive, and results that were assumed during the first build and never actually measured. That classification is the input to the scaling decision. If most of the load-bearing assumptions sit in the last category, the programme does not need more test capacity yet; it needs the first phase finished properly.

Equipment prototypes rarely fail at the level of a component. They fail at the boundaries between blocks -- where a control output meets a driver input, where a sensor signal meets an analogue input that was expected to be digital, where two subsystems assume opposite things about who is in charge of a shared line.

Before scaling, the interface set gets reviewed explicitly. For each pair of connected blocks the review wants the direction of each line, the electrical characteristics on both sides, what each side does when the other is silent or absent, and what happens on connection and disconnection. Timing assumptions are the usual source of surprises: an enable that must be asserted before a command, a status line that is only meaningful after a delay, a handshake that one side expects and the other does not implement.

Where an interface is only documented as a connector and a cable, that is a gap, not a specification. Widening a test programme across several builds with undocumented interfaces means each build can behave differently and each difference will be interpreted as a fault rather than as a definitional gap.

A practical way to run this review is to have two people independently record the same interface from the available documents and then compare notes. The mismatches are the review findings, and they are usually faster to find that way than by reading the documents once and trusting the impression.

Scaling a test programme multiplies test slots. If those slots cannot be traced back to a requirement, they cannot be defended in a review meeting, and they cannot be closed when they pass. The traceability check runs in both directions. From requirement to test: for each requirement, which test demonstrates it, and is that test representative of how the requirement is actually used. From test to requirement: for each planned test, which requirement it serves, and if none, whether it is really a diagnostic measurement rather than a verification test.

The most common finding in this review is a requirement that everyone believes is tested but nobody can point to a test for -- often a behaviour that only appears in a specific operating state, such as recovery after a supply interruption, or behaviour under a user action performed out of sequence. The second most common is a test inherited from a previous project that has no requirement behind it on this one, and still consumes slots.

At single-board level, pass criteria are usually obvious. At integrated level they are frequently missing, and the gap shows up as argument after the fact rather than decision before the test.

The review wants, for each planned test, a defined criterion, a defined observation method, and a defined authority for the judgement. Where several criteria interact, the review wants the precedence: what is the disposition when one criterion is met and another is not, and who is allowed to accept that combination.

For equipment prototypes that involve heating elements, pumps, high currents, pressurised fluid or moving parts, the review asks what is observed when a control signal is lost, when a sensor fails open or short, and what brings the process to a stop if the primary control path does not. Those observations should be planned as tests carrying criteria, not left until an incident produces them.

A scaling review that turns up no standard test record -- no agreed way of capturing what was set, what was observed, who judged it and when -- should conclude that the programme is not yet ready to widen. Widening an unrecorded programme only generates a larger volume of claims nobody can verify.

Most prototype programmes carry a small set of unresolved contradictions: the schematic says one thing and the layout another; the enclosure drawing and the mechanical assembly disagree about a mounting detail; a component datasheet and the supplier's delivered part do not match; a test result contradicts a simulation. These are not emergencies individually, which is exactly why they persist.

Before scaling, the review asks what open contradictions exist, which of them touch the tests now being added, and what decision was taken on each. Contradictions that touch the new test scope are closed first, because running more tests on top of a contradiction produces data that cannot be interpreted consistently. Contradictions that do not touch the new scope can be logged with an owner and a review date.

This step is uncomfortable to run honestly. It surfaces the fact that a favourite subsystem has a known inconsistency nobody has resolved. It is also the step that most reliably prevents a programme from spending its second phase explaining results that were caused by an issue everyone already half knew about.

A sensible way to frame scaling is a staged route -- working prototype, then engineering prototype, then a small trial run -- with scaling meaning the programme crosses a gate onto the next stage rather than simply getting bigger in place. Framed that way, each gate has to answer what the previous stage established, what it left unestablished, and what must be resolved before the next stage is funded.

A finished prototype demonstrates that a concept can be constructed and made to do the thing. It does not demonstrate that the product is ready for delivery or volume output. Closing that gap is the job of the engineering prototype stage: repeatable construction, access for servicing, availability and substitution of parts, and a design that survives ordinary build variation. A small trial run then stresses process and paperwork, since by that stage the design ought to be stable enough that what is left are process issues.

Accordingly the gate review must be able to end in one of three ways -- continue, continue subject to named conditions, or halt -- with the reasoning recorded. A gate that can only ever say continue is not a gate. When a candid review shows the present stage has not yet delivered what it was meant to deliver, the defensible decision is to lengthen the present stage, not to layer the following stage's costs on top of an unfinished one.

For programmes that will go on to production import, this is also the point at which the manufacturing-facing work is scheduled rather than improvised: the parts list, the revision discipline, the assembly sequence, and the test coverage handed to production all become easier to define when they are done as part of a gate rather than as a recovery after a schedule slip.

The final item is the least technical and frequently the most consequential. A test programme both run and interpreted by the people who designed the prototype will be biased -- not dishonestly, but predictably -- toward readings in which the design is sound and the test was simply awkward.

The scaling review therefore asks who is qualified to challenge results, who signs a pass, and who has the standing to record a fail against the schedule pressure of an important programme. Where there is no independent reviewer, the review should at least require a second reader for criteria and setups before slots are booked, and should keep failures visible rather than resolving them privately.

Teams carrying the wider programme -- engineering, manufacturing, quality and service -- should also have had a hand in setting those criteria. Where they did not, expect friction downstream, because people resist most strongly the criteria they were never consulted about.

Structured, the review produces a short set of artefacts: a definition of what is being scaled and why; an evidence classification showing what is solid, suggestive, or assumed; an interface map with gaps marked; a two-way traceability table; pass and fail criteria with named judges for the added slots; a closed-contradiction list with owners; and gate criteria with three permitted outcomes.

A team that can produce those artefacts on request is ready to widen its test programme. A team that cannot is not behind schedule for that reason -- it is telling you where its next work actually is. This is also the point where an external engineering view tends to pay for itself: the product R&D accelerator for cleaning equipment work is structured around feasibility assessment, scheme planning, prototype route design and risk review, with a written set of conclusions at the end of each stage, and an evaluation that concludes a project should be stopped or restructured is treated there as a valid outcome rather than a failure.

Where the review shows that the next stage calls for design and build work rather than additional test slots, that is an entirely different scope, and product development runs from mechanical structure and electrical design through control, functional module integration, prototype manufacturing, testing and validation into parts lists and production import -- with testing and validation inside the same scope as the design instead of as a phase that starts after it.

Read that way, the review before scaling is not a hurdle put in front of the programme. It is the cheapest moment at which a programme can still change direction -- and after the slots are booked, it is the last cheap moment.