If you send three integrators the same vague sentence — "we need an inspection robot for the plant" — you will get three proposals you cannot compare, because each one quietly assumed a different problem. A specification is not bureaucracy; it is the document that makes three bids mean the same thing. Write it before you talk to vendors, not after.
The eight sections of a bid-able spec
1. Environment and hazards
What actually surrounds the robot. For oil & gas this means the Zone classification and gas groups; for nuclear it means radiation tolerance and decontamination requirements; for mining it means unsupported GPS and rough terrain. State the worst credible condition, not the average one.
2. Tasks and acceptance criteria
"Inspection" is not a task. A task is "read this meter to ±1 °C and flag values outside 60–90 °C," or "detect hot spots above 80 °C on these 40 joints." Define the defects the robot must catch and the false-positive tolerance you will accept. This section is the single biggest predictor of whether the project succeeds.
3. Uptime and autonomy target
How many runs per day, how many manual interventions are acceptable, and who supervises. "Fully autonomous" is a wish; "completes the 2 km route with no more than one human intervention per 10 runs" is a spec.
4. Data deliverable
What the report looks like and where it lands. A PDF? A feed into your SCADA or CMMS? With photos, thermal overlays, and trend lines? The data deliverable is the actual product — specify it like one.
5. Safety envelope
Who is liable when the robot stops in a live area, and what it is allowed to do without a human. Stop behavior, return behavior, and — for hazardous sites — the certificate scope it must operate under.
6. Connectivity and infrastructure
What you provide (network, docking location, power) versus what the integrator assumes. Unspecified connectivity is the most common source of "it worked in the demo, not on site."
7. Acceptance test protocol
Defined before signing: the exact run, in the real environment, with the real data deliverable, judged against the criteria in section 2. If the acceptance test is vague, the project ends in argument.
8. Support and handover
Training, documentation, spares, and the update path. A system you cannot maintain is a system with a short life.
Common mistakes
- Writing the spec around a brand. "We want a Spot" pre-judges the platform; write the requirement, let the integrator pick the hardware.
- Skipping acceptance criteria. Without them, "done" is negotiable.
- Assuming the site is robot-ready. Connectivity, docking, and access are your responsibilities until stated otherwise.
- Confusing a demo with a deployment. A 10-minute show in a cleared aisle proves little about a 2 km route in a live plant.
Why acceptance criteria matter most
Everything else in the spec is context. The acceptance test is the only clause with teeth: it is what you measure the delivered system against, and what turns a polite disagreement into a pass/fail. Spend disproportionate effort here. If you cannot write the acceptance test, you do not yet understand the problem well enough to buy — and that is the moment to bring in an integrator for a feasibility assessment rather than a purchase.
What to ask an integrator before signing
- Will you bid against my spec, section by section, or propose your own scope?
- What is your standard acceptance test for a site like mine?
- Who owns the data pipeline and the integration code after handover?
- Show me a reference deployment with the same hazard class.
The budgeting side of the same decision is covered in our note on building a TCO model. Both documents together are what separate a purchase from a project.