The 400G/800G Procurement Evidence Contract: What Buyers Should Require Before Acceptance

Most optics purchase orders are precise about the product and vague about the proof. They name a part number, a quantity, a delivery date, and a price agreed by quotation. What they rarely name is which documents establish that the delivered goods are what was ordered, who produces those documents, when they arrive, and what happens if they do not.

That gap is invisible while everything works. It becomes expensive at exactly the wrong moment — when a batch behaves differently from the qualification samples, when a component inside the module has been substituted without anyone noticing, or when a link is unstable and two organisations each have a plausible reason to believe the problem belongs to the other. At that point the discussion is about expectations, because nobody agreed on records.

The remedy is not a longer specification. It is an evidence contract: a short, explicit agreement, settled before the purchase order, about which artifacts establish conformity and what acceptance is conditioned on.

This article sets out how to construct one for 400G and 800G optics. It is a procurement governance piece, not a product selection guide and not a migration plan. Commercial and legal terms are outside its scope; where obligations, remedies, or liability are involved, that is a question for your own counsel rather than for a supplier’s engineer or for an article.

What an evidence contract is, and what it is not

An evidence contract answers one question: when the goods arrive, what will we look at to decide whether they are acceptable?

It is not a quality standard, and it does not tell the supplier how to manufacture. It defines the interface between two organisations — which artifacts cross the boundary, in what form, at what point, and with what identifying information attached. A supplier remains free to run their process as they see fit; the contract simply fixes what is visible to the buyer.

Three properties make one useful:

• Agreed in advance. Evidence requested after a dispute begins is negotiation. Evidence agreed before the order is procedure.
• Specific about identity. An artifact that cannot be tied to a particular delivery, lot, or serial number proves something about the supplier in general and nothing about your goods.
• Bounded. Requiring everything imaginable produces refusal or box-ticking. The useful set is small and chosen for what it would let you do if something went wrong.

The broader discipline this sits inside is supplier risk management. NIST’s guidance on cybersecurity supply chain risk management makes the general point that acquisition needs to be treated as an ongoing relationship with defined visibility rather than as a single transaction (NIST SP 800-161r1), and its more recent traceability work addresses establishing and communicating provenance across supply relationships (NIST IR 8536). Neither document prescribes the matrix below. They are background for why defined visibility matters; the specific artifact set is a commercial choice between you and your supplier.

The acceptance evidence matrix

The practical form of the contract is a table agreed with the supplier before the order. Each row names an artifact, who produces it, when it is due, and what it establishes.

Responsibility boundaries

Evidence problems are frequently ownership problems wearing a technical costume. Five roles are typically involved, and the failure mode is that each assumes another is handling it.

Buyer procurement owns the contract itself: agreeing the matrix, ensuring it is referenced by the order, and holding the supplier to the timing. Procurement is not expected to evaluate technical content, but it is the only function positioned to ensure the requirement exists before the order is placed.

Buyer network and operations owns the environment definition and the validation. They specify the hosts, software versions, fiber and distances the order is scoped to, run staged validation, and preserve failure evidence when something goes wrong. If this function is not consulted before the PO, the context row is filled in with assumptions.

Supplier sales owns the commercial commitment and the accuracy of what has been agreed. Their responsibility in an evidence contract is largely negative: not to commit to artifacts their organisation cannot produce, and not to characterise a general capability as a specific one.

Supplier engineering and quality owns the technical content of the evidence, the change notification, and the diagnostic response. The practical test of whether this function is genuinely engaged is whether the buyer’s technical questions reach someone who can answer from records rather than from a datasheet.

Any integrator or reseller in the path owns the flow-through. If a third party sits between buyer and manufacturer, the contract needs to state explicitly whether artifacts pass through unchanged, whether the integrator adds their own, and who is responsible when the manufacturer’s record is required. An integrator can coordinate well; what they generally cannot do is produce a manufacturing record they do not hold.

The boundary that causes the most difficulty in practice sits between buyer operations and supplier engineering, because an unstable link genuinely can originate in the module, the host, the fiber plant, or the interaction between them. Naming an escalation owner before the order does not resolve the technical question, but it prevents the first week being spent deciding who should be looking at it.

Evidence strength: three levels

Not all artifacts carry equal weight, and it is worth being explicit with a supplier about which level a given row requires.

Level 1 — Declaration. A statement that a requirement is met. Useful, cheap, and appropriate for stable, low-consequence attributes. Its limitation is that it is not tied to your goods: a declaration describes a product family, not the units in your carton.

Level 2 — Traceable record. A record connected to identifiable material — a lot number, a build reference, a serial range. This is materially stronger, because it lets you ask a specific question later and get a specific answer. Most rows in the matrix above are satisfiable at this level, and this is usually the right target.

Level 3 — Test evidence in the agreed environment. Results obtained on the actual host platforms, fiber and distances defined in the context row. This is the only level that speaks to behaviour in your deployment rather than to conformity in general, and it is the level that staged validation produces.

The practical guidance: use Level 1 where the consequence of being wrong is low, require Level 2 as the default for anything you might need to investigate later, and reserve Level 3 for the configurations you are about to deploy at scale.

I would deliberately not tell you what pass thresholds, sampling rates, or mandatory standards to write into these rows. Those depend on your application, your risk tolerance, and what your platform vendors require. A supplier who volunteers universal numbers without knowing your environment is guessing, and a buyer who accepts them has adopted someone else’s assumptions.

For the related question of what a manufacturer characterises before shipment — and therefore what Level 2 and Level 3 evidence can realistically exist — we have described our own bench practice in our QA lab article.

Pre-PO checklist

Before the purchase order is issued:

• [ ] Requirement baseline documented with a version reference both sides can cite
• [ ] Exact part identifier including revision or configuration code confirmed in writing
• [ ] Host platforms, software versions, fiber type and link distances stated and acknowledged
• [ ] Evidence matrix agreed, with each row assigned an owner and a timing
• [ ] Required evidence level agreed per row, and confirmed achievable by the supplier
• [ ] Change and substitution notification practice confirmed, including how affected deliveries are identified
• [ ] Traceability confirmed: what can be recovered from a serial number or lot after delivery
• [ ] Named technical and commercial escalation contacts recorded on both sides
• [ ] Record retention periods agreed on both sides
• [ ] Exception route defined for a missing artifact or an unexpected result
• [ ] Failure evidence preservation method agreed before any unit is returned
• [ ] Integrator or reseller role in artifact flow-through stated explicitly, if applicable
• [ ] Commercial and legal terms reviewed by your own counsel

Post-delivery acceptance workflow

After goods arrive, a workable sequence:

1. Identity check. Confirm the delivered part identifier and revision match what was ordered, and record the lot or serial range received.
2. Artifact check. Confirm the pre-shipment evidence agreed in the matrix is present and carries the identifying information that ties it to this delivery.
3. Receiving inspection. Perform and record your own arrival check, independent of the supplier’s record.
4. Provenance comparison. Compare the delivered lot identity against the qualified samples. If they differ in a way the matrix did not anticipate, that is an exception, not a detail.
5. Staged validation. Validate in the agreed environment before scale deployment — real hosts, real link paths, at operating conditions rather than only at ambient.
6. Record the validated configuration. Capture what was validated: part revision, host platform, software version, and configuration. This is what makes a future change recognisable as a change.
7. Conditional acceptance. Accept against the matrix rather than against an impression. If a row is unsatisfied, use the agreed exception route rather than accepting informally and raising it later.
8. Retain. File the evidence set where it can be found by someone who was not involved in the purchase.

Step 6 is the one whose value appears eighteen months afterwards, when a delivery behaves differently and nobody can reconstruct what the original validated configuration was. It costs a few minutes at the time.

Where Sanoc sits

Sanoc manufactures at its own factory and headquarters in New Taipei City. For an evidence contract specifically, the relevant consequence is that the artifacts in the matrix above are produced inside the organisation that runs the process, so a question about a build or a configuration goes to the people who set it rather than being relayed upstream.

Sanoc products carry a one-year warranty. Sanoc received a 2025 Taiwan Excellence Award. Sanoc operates on a quote basis, so configuration options and commercial terms are confirmed per enquiry rather than published as a price list. The structural picture behind regional sourcing is discussed separately in our article on Taiwan optical manufacturing and supply chain.

We do not publish acceptance thresholds or response-time commitments in articles, and this one contains none. What an evidence contract makes possible is narrower and more useful: an agreed set of records, so that a disagreement later is about facts rather than about recollections.

Conclusion

The reason to do this work before the order is that the alternative is doing it during an incident, when both organisations are under pressure and neither has an agreed reference point.

None of the twelve rows above is difficult to produce. Most competent suppliers already generate the underlying information; what is usually missing is agreement about which parts of it cross the boundary and when. Fixing that costs one conversation before the purchase order.

If you adopt only two rows, adopt lot identity and change notification. The first makes your qualification meaningful. The second means you find out about a change from your supplier rather than from your network. Everything else in the matrix is refinement on top of those two.

Sources and further reading

• NIST — SP 800-161r1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
• NIST — IR 8536, Supply Chain Traceability
• Sanoc — Inside the Sanoc QA Lab: How We Bench-Test Every Batch
• Sanoc — Why Taiwan Optical Manufacturing Matters for Your Supply Chain
• Author column — Liao Yu-Sheng, Ph.D., Founder and General Manager

Related Articles

SANBOX Transceiver Compatibility Configuration for Incident Triage: From DDM to Remote Evidence

SANBOX Transceiver Compatibility Configuration: A Procurement Framework for Multi-Vendor Data Centers

BiDi transceiver decisions for fiber-constrained campuses: A procurement framework

BiDi transceiver procurement: Matched pairs and link acceptance

1000BASE SFP Transceiver Procurement at Enterprise Scale: TCO, Warranty and Compatibility Risk

10G SFP+ Transceiver Procurement: EEPROM Coding, Part Selection, and Acceptance

25G SFP28 Transceiver Procurement and Arrival Acceptance: Specs, DDM and Temperature Grades

100G AOC Acceptance Testing: Arrival Checks, Diagnostic Evidence, and Fault Isolation