P0The pipeline
Every stage earns its place, and the order is the point. Work done here lands cheaply; the same work found later lands where it costs the most.
What the system has to do, before anyone names a part.
2 stages
The requirement resolved into categories, parameters, and trade-offs.
1 stages
Who can actually build it, checked rather than listed.
2 stages
A shortlist and an RFQ package carrying its own evidence.
2 stages
01Stage by stage
Application, constraints, quantity, timing.
We start from the system you are building, not from a part number. Duty cycle, environment, payload, endurance, certification target, volume, and date. Most sourcing failures are already present at this step, written down as a part number that was never derived.
Inputs
Output
A requirement record with the constraints made explicit.
System decomposed into component architecture.
The requirement is decomposed into subsystems and then into component categories. This is where a request for 'a motor' becomes a coupled decision across motor, ESC, propeller, and pack — because those four cannot be selected independently.
Inputs
Output
A component structure showing what must be sourced and what is coupled.
Categories mapped to technologies and supplier landscape.
Each category is mapped against the technologies that serve it and the companies operating in it — manufacturers, authorised channel, integrators, and resellers, held apart rather than merged into one list.
Inputs
Output
A candidate landscape per category, with the role of each company stated.
Identity, capability, and technical claims checked.
Claims are reconciled against independent sources. A datasheet number that only exists on the datasheet is recorded as unverified, not repeated as fact. Where sources disagree, the disagreement is the finding.
Inputs
Output
A validation record per supplier and per claim, with evidence attached.
Validation record
RB-11 · Harmonic-drive actuator
Stage 04 output, as it appears in a record.
Validated records assembled into a comparable set.
Surviving options are placed on one comparable basis — same parameters, same conditions, same units. This is the first point at which a genuine comparison is possible, which is why it sits here rather than at the start.
Inputs
Output
A ranked shortlist with the reason each option is on it or off it.
A structured RFQ package built from the requirement.
The RFQ is generated from the requirement record, so suppliers are quoting the same thing under the same conditions. Ambiguity removed at this step is the ambiguity you do not argue about at incoming inspection.
Inputs
Output
An RFQ package issued to qualified suppliers.
Qualified suppliers engaged with decision context intact.
Quotes return against a known basis, and the decision context — what was validated, what was flagged, what remains open — travels with them. The record is what you hand to engineering, to quality, and to finance.
Inputs
Output
A procurement decision with a traceable basis.
02What you bring
The BOM is something this process produces, so there is no need to arrive holding one. Describe the system and we take it from there.
You bring
The application and what it has to do
You bring
Performance envelope and operating conditions
You bring
Volume and the date you need it by
You bring
Certification target, if there is one
We derive
The component structure
We derive
The validated supplier shortlist
We derive
The part numbers and the BOM
We derive
A costed basis for the decision
Start with the application
Tell us what the system has to do. We take it from requirement through to a decision that carries its own evidence.