A prototype answers
a particular question.

A mock-up might show size and arrangement, while a working demonstrator might examine one behavior. Neither automatically represents every material, component, condition, or feature of a later product.

In a hypothetical foldable desk organizer, a cardboard model could help discuss access and layout. It would not by itself establish durability, suitability of a final material, or the behavior of the product after extended use. The model's usefulness depends on the question being asked.

Describe which parts are working, which are simulated, and which require assistance. Identify the setting used for the demonstration and any important difference from the intended use. A successful demonstration under one condition should not be described as universal readiness.

If observations are made, record the model version, relevant conditions, and what actually happened. Keep unexpected behavior in the record. Removing awkward observations can make the next development decision less reliable, even when the demonstration otherwise appears promising.

The move from a prototype to a product may involve different materials, repeatability, reliability, instructions, operating responsibilities, or other checks appropriate to the intended application. Requirements should follow the actual context rather than a generic readiness label.

A clear review distinguishes what the prototype helped explain from what it did not examine. It can support another development step without justifying a release or a performance claim. Before sharing a prototype, make its status understandable and agree how it may be handled. These notes do not describe a prototype supplied by the company.