A prototype answers whether a proposed interaction can work in a limited setting. Procurement asks a broader question: can an organization obtain, operate and support the system under agreed conditions? Moving between those questions requires evidence, named responsibilities and a commercial scope.
The following decision gates are a suggested method for application and hardware projects. They are not a claim that a CNPS project has passed them or a fixed delivery commitment.
1. Preserve what the prototype actually proved
Write down the task, users, input material, configuration and conditions behind the demonstration. Save both successful and failed attempts. A short voice interaction in a quiet room, for example, proves only what was observed in that configuration; it does not establish performance in a busy reception area.
List the dependencies that made the demonstration possible. These can include manual preparation, a developer account, a particular network or a person correcting outputs. Making these dependencies visible allows the next stage to test or replace them deliberately.
2. Use gates with explicit decisions
Each stage should end with a decision and the evidence supporting it. Passing a gate means the agreed question was answered, not that every possible risk disappeared. If the answer is unclear, state what additional evidence is needed and who will obtain it.
| Gate | Decision | Evidence to prepare |
|---|---|---|
| Problem | Is the task valuable and sufficiently defined? | Baseline, user and business owner |
| Prototype | Can the proposed interaction work? | Recorded configuration and observed attempts |
| Pilot | Does it work in representative conditions? | Agreed tests, results and failure record |
| Procurement | Can the scope be purchased and supported? | Complete quotation, responsibilities and acceptance |
| Rollout | Can the result be repeated at the intended scale? | Site or user plan, operating capacity and change record |
Do not let a calendar date silently replace a gate. If the launch date is fixed, adjust the scope or expose the unresolved dependency rather than treating missing evidence as a pass.
3. Separate software rights from technical access
For a project based on public code, identify the exact repository, release and components you intend to use. Review their applicable terms and the terms of connected services before deciding the commercial model. Access to source code is one input; rights to distribute a product, use a brand or provide a hosted service may involve separate conditions.
Keep an inventory of application code, models, firmware, voices, datasets and third-party services as relevant. Assign an owner to check changes. This article offers a procurement process, not a conclusion about a particular license or jurisdiction.
4. Price the operating system around the product
Separate one-time engineering from recurring operation. Include hardware and accessories where needed, hosting, model or speech usage, content maintenance, monitoring, updates, training and support. Describe what happens if demand is higher or lower than the planning assumption.
Ask which party owns credentials, source changes, user administration and incident handling. Define the practical exit path: how the customer retrieves its data, how access is removed and what is required to change a service provider. These decisions affect the project’s usefulness after the demonstration team leaves.
5. Make acceptance part of the quotation
The commercial scope should describe included work, exclusions, versions, customer inputs, acceptance method and the party approving completion. Name the pilot quantity or user count separately from any future order. State which changes require a revised quotation.
For hardware, include the destination, packaging, delivery assumptions, installation responsibilities and replacement arrangements. For software, include the hosting arrangement, integrations and maintenance boundaries. Confirm applicable product testing and documentation with the responsible parties for the exact configuration and destination.
6. Leave a record the next team can use
A procurement-ready package contains the requirement, system map, evaluation results, dependency inventory, quotation and operating ownership. Keep unresolved items visible, with a next action attached. The purpose is to let another person understand the decision without reconstructing the entire conversation.
Use the AI procurement checklist or the voice prototype specification to organize the next stage. Share your project scope with CNPS: describe what already works, what remains untested, the intended users or quantity, destination and timeline. That gives both sides a sound starting point for a scoped proposal.
