Design basis
Topology, capacity, reach, environment and operating model are tied to each proposed line item.Dependency check
Hardware, optics, cabling, NOS image, telemetry, automation, power and cooling are reviewed together.Exception record
Unknowns, alternatives, exclusions and owner decisions remain visible instead of being buried in a quote.Acceptance basis
The buyer defines measurable pre-shipment, receiving or site checks before purchase.
Evidence boundary
Catalogue hardware is an input, not procurement validation.
The representative switch in this panel shows the kind of line item a buyer may assess. Its image and catalogue record do not establish suitability for a topology, optic, software image, site or operating model.
What establishes a project-specific claim
- An approved requirement-to-bill-of-material matrix for the intended topology
- Named optics, software, power, cooling, management, support and lifecycle assumptions
- Recorded exceptions plus measurable acceptance criteria and approval ownership
Turn the requirement into a traceable matrix
A port count is not a deployable specification. Each quote line should trace back to a role in the topology and forward to the optics, software, management, power, support and acceptance assumptions that make it usable.
- Topology role, interface speed, quantity, reach and growth assumption
- Optics or cable form factor, connector, lane rate and compatibility requirement
- NOS version, configuration ownership, telemetry, automation and rollback path
- Power, cooling, rack, support, spares, delivery and documentation requirements
Make exceptions visible before approval
Where a requirement is not yet proven, the review should mark it as an assumption, test item, alternative or exclusion. This gives engineering and procurement a shared decision record and prevents an unverified statement from becoming an implied commitment.
- Unsupported or unconfirmed optics and breakout combinations
- Image, feature, telemetry or automation assumptions that need validation
- Environmental, logistics or support boundaries still awaiting confirmation
- Changes that require the bill of materials or acceptance plan to be re-approved
Define the purchase-basis output
A useful output names what is included, what remains open, which evidence will be supplied, who owns each action and what constitutes acceptance. The exact documents depend on the quoted scope.
- Approved requirement and bill-of-material matrix
- Optics, software and configuration assumptions
- Acceptance checklist with observable pass or exception language
- Support, escalation, documentation and change-control notes
Purchase basis
Questions procurement and engineering should answer together
Why is a datasheet not enough?
A datasheet describes a device. The purchase basis also needs the topology, optics, software image, operating model, site constraints, support and acceptance boundary.
Can xSONiC review an existing RFP or bill of materials?
A review can be discussed. Send the current requirement, topology, line items, known constraints and the evidence expected from the supplier.
What happens to an unverified requirement?
It should be marked for testing, replaced with an approved alternative, accepted as a documented risk, or excluded. It should not be silently treated as proven.
Does this replace receiving or site acceptance?
No. It creates the purchase basis. The receiving, commissioning and site-acceptance activities still need their own agreed scope.