Start from the acceleration brief, not from the prototype
The first quality check is documentary. An accelerator engagement is meant to answer four questions before large research and development cost is committed: whether the product idea can be implemented and is worth investing in; how the mechanical, electrical, control and functional modules will be implemented; the initial cost, cycle, prototype route and key risks; and the path from principle prototype through engineering prototype to small-scale trial production. Those four lines are the acceptance frame for the whole project. If the written brief does not carry them, later checks have nothing to be measured against, and a commissioning review turns into an argument about scope.
A useful habit is to number the brief's statements and keep that numbering alive through every later document. The feature list, the feasibility assessment, the prototype route and the risk checklist then all refer back to the same items, and the commissioning review can ask "which brief line does this satisfy" instead of "do we like this result".
Check that the requirement set was actually sorted
Requirement definition and product sorting is the first service module on the product R&D accelerator for cleaning equipment page, and it is the deliverable most often skipped at the review stage. The check is not "is there a requirements document" but whether the document separates core functions, auxiliary functions and optional functions, whether usage scenario and target customer analysis is recorded, whether cost objective and price range were discussed rather than assumed, and whether project priority was ranked. A project that reaches commissioning with optional features still in the core column will argue about them at the worst possible moment, because they are the items the cost estimate never covered.
Sorting also exposes the items nobody claimed. Where a requirement was deferred, it should appear in the record with an owner and a decision date. An empty deferral column at commissioning usually means the conversation never happened.
Check the boundaries between systems
Technical feasibility work on the same page covers the mechanical structure, the electrical control, the steam, water and vacuum systems, the mobile platform and its load path, the choice of core components, and how the machine will be machined and assembled. Commissioning is where the seams between those blocks fail, not the blocks themselves. The practical check is to write down each boundary and ask who verified it: where the electrical control hands over to the mechanical assembly, where a water or steam circuit enters a structural frame, where a mobile platform's load path meets the enclosure, where a purchased component's specification meets the design assumption. Each boundary needs a named verification, a date and a person.
Out-of-scope items belong in the same table. A commissioning record that lists only what was built invites the assumption that everything around it was also covered. Stating what was excluded is what makes the covered items trustworthy.
Check that acceptance clauses are written in test language
The accelerator's output list includes a requirements analysis document, a product feature list, a technical feasibility assessment, a product module architecture, a preliminary technical solution, a prototype development route, core component suggestions, a preliminary cost assessment, a risk assessment checklist, a development cycle suggestion, a next-stage development plan and a product development quotation basis. None of those are pass or fail statements on their own. For commissioning, each one needs a matching acceptance clause written in the language of a test that can be run.
This is where steam cleaning equipment testing practice is worth borrowing even when the project is not a cleaning machine. The hardware testing service defines its own blocks: functional testing covering the control panel and human machine interface, execution mechanism action and alarm and protection functions; performance testing covering pressure, temperature and flow together with suction, energy consumption and the cleaning result itself; stability testing through continuous running, repeated start and stop, and fault reproduction; safety testing across electrical safety, leakage and emergency stop, and sealing and high temperature protection; life and reliability testing on key components, switches and wear; and a factory testing plan with test items, a record form and qualified or unqualified standards. Those categories give an engineering team ready-made shapes for acceptance clauses, and the "qualified/unqualified standards" item is the part most briefs omit.
Two cautions apply to the numbers in that list. Figures published on product pages belong to existing machines; they are not an acceptance basis for a new build. And a clause such as "works reliably" cannot be commissioned; it has to be restated as an operating condition, an observation and a threshold agreed before the trial starts.
Check the prototype route was the one actually followed
Prototype route design plans the principle prototype, the engineering prototype and preparation for small-scale trial production, with a manufacturing cycle estimate, planned test items and iteration suggestions. At commissioning, compare the route as delivered against the route as planned. If the principle prototype was skipped, which assumption lost its verification? If iterations ran past the plan, which risk item did they close and which remained open? Where a test item in the plan has no result attached, the route is incomplete even if a working unit exists.
A related check is the boundary the accelerator itself draws. The accelerator settles how a project starts: direction, technical route, cost and prototype plan. The carrying of that decision through structure, electrical control, prototype build, bill of materials and production import sits with product development. If the project was run as an acceleration engagement only, the commissioning record should say so plainly, because a buyer who reads "prototype completed" as "production ready" is reading a claim the documents do not support.
Check the risk register has owners and closures
The risk module on the accelerator page inventories technical risk, cost risk, mass production risk, supply chain risk and safety and reliability warnings, together with suggestions for subsequent development. A commissioning check on that register asks three narrow questions of each row: does it name an owner, does it record what was done, and does it state what remains open? A register that still reads as a list of concerns at handover is a document that was written once and never used.
The accelerator page also answers the question of what happens when the evaluation concludes the project is not suitable for further development: that outcome is treated as part of the value of the work, because it identifies the problem before large scale investment. Commissioning should be able to record that conclusion as a legitimate result. A project closed on evidence and a written risk analysis is a completed engagement, not a failure to be papered over.
Check each document has a named reader
Acceleration deliverables are consumed by different people, and a check that nobody reads is a check nobody performs. The requirements analysis document and feature list serve procurement and the quotation basis. The module architecture and preliminary technical solution serve the engineering team that continues the work. The prototype route and test item plan serve whoever runs the next trial. The risk checklist and mass production risk notes serve supply chain and the factory inspection standard. Where the same page is integrated engineering team services is configured as a phased team, the roles taking delivery of each document should be listed against it, because the handover is otherwise a shared inbox.
A one-page coverage table is usually enough: deliverable, reader, format, where it is stored, and the date it was last reviewed. Most commissioning disputes are settled by that table existing.
Check the next stage is priced and gated
The accelerator's stated purpose is to support decisions before the next stage fee is committed. So the final check is a decision gate: does the pack support a quotation basis for the next stage, does the development cycle suggestion match what the project actually consumed, and does the next-stage plan name what will be verified in that stage rather than what will be built in it? If the next stage is small-scale trial production, the check extends to whether the bill of materials direction, process documents and inspection standards were started at all, or were left as a promise.
Write the gate as three outcomes, not two: proceed, proceed with named conditions, or stop. A commissioning review with only pass or fail pushes marginal projects into "pass".
A short commissioning agenda for the review meeting
One page, eight lines, each answered in writing before the meeting closes. First, the brief: are the four acceleration questions each answered by a numbered document? Second, functions: is the core, auxiliary and optional split signed, with deferred items named? Third, boundaries: does each system seam have a verification, an owner and a date? Fourth, acceptance clauses: does every deliverable have a matching clause in test language, with a qualified or unqualified standard? Fifth, route: does the prototype route as run match the route as planned, with each deviation explained? Sixth, risks: does every row have an owner and a status? Seventh, readers: does every document have a named receiver? Eighth, gate: is the next stage quoted, and is its verification content written down? Any line unanswered is a condition on the handover, not a reason to postpone the review.
What commissioning does not prove
Commissioning an acceleration pack proves that the early judgement work is complete, traceable and usable by the people who continue the project. It does not certify performance of a machine that has not yet been built to production drawings, and it does not transfer published specifications from an existing product page onto a new design. It does not replace the test plan for the next prototype, and it does not establish factory inspection standards, which are a separate output. Stating these limits in the handover record is itself one of the quality checks; the teams that skip it are the ones whose next stage starts with a disagreement about what was promised.
