CosmosForum Editors — feature note (not a press release).
On 15 October 2026, member companies of **OIOMSA** (Optical Interconnect Multi-Source Agreement) announced that **OIOMSA specification V1.0** had been completed in Chengdu’s Tianfu Science City. The public site is
https://www.oiomsa.com. Sister coverage on OE Forum:
https://www.oeforum.com/t/160.
This note is a **technical reading guide** for science and engineering readers: what problem the MSA claims to attack, what V1.0 actually scopes, and which questions still decide whether “V1.0” becomes infrastructure or brochure.
### The fragmentation problem in plain language
AI training and inference clusters keep pushing optical interconnect closer to the compute die: front-panel pluggables are no longer the only story. The industry now juggles overlapping packaging and optics proposals — commonly named **NPO, CPO, LPO, LRO, UPO, OBO, EPO, XPO**, among others — each with different mechanical envelopes, electrical pinouts, optical budgets, laser architectures, and management pages.
When those interfaces are not shared, a system vendor pays the tax repeatedly: one bring-up script per vendor stack, one thermal/EMI lesson per package class, one firmware map per management dialect. Scale-out hardware then stalls on **interop and supply options**, not only on a single engine’s lab BER.
An MSA’s job, when it works, is to publish one open interface contract so multiple suppliers can implement independently and still mate mechanically, electrically, optically, and in management. OIOMSA’s V1.0 announcement frames itself as that kind of unifying base for domestic optical-interconnect supply chains serving AI clusters.
### What V1.0 says it covers
According to the alliance’s public materials, V1.0 is organized around five interface families:
1. **Mechanical** structure and package envelopes
2. **Electrical** interfaces and channel maps
3. **Optical** parameters and link budgets
4. **Management** protocol (CMIS-oriented planning across stages)
5. **Test and verification** — compliance, interop, reliability, and related gates
The published technical-roadmap framing is **NPO → CPO → OIO**, with **OIO (optical I/O)** described as the long-term target (optical I/O chiplets integrated toward compute via a die-to-die style interface such as UCIe, in the alliance’s draft language). NPO is near-package optics; CPO is co-packaged optics (drafts often assume an external laser source / ELS). Legacy pluggables (OSFP / QSFP-DD) and LPO-class approaches are treated as **compatibility concerns** (connector families, link-budget classes, CMIS models) rather than the main stage sequence.
Important honesty from the alliance’s own docs: many numeric rows on the draft pages are marked as **proposals pending working-group review**. Readers should treat V1.0 as a **published framework + draft parameter set**, not as a frozen IEEE-style ratified PHY.
### Why this matters beyond marketing adjectives
For CosmosForum readers who think in instruments, links, and failure modes, three practical stakes stand out:
- **Design reuse.** Shared mechanical / electrical / optical / management contracts cut the number of one-off paddle and firmware adapters between engine vendors.
- **Verification reuse.** A common test-point and interop checklist is how “multi-source” stops being aspirational. Without multi-vendor plugfests, an MSA is a PDF.
- **Roadmap clarity.** Naming NPO → CPO → OIO as a sequence does not erase today’s LPO/pluggable fleet; it does tell architects which layer the alliance wants to stabilize next.
MSA value historically tracks **who adopts** (system OEMs, cloud operators) and **who passes multi-vendor interop**, not who publishes first. That skepticism belongs in any technical reading of V1.0.
### Soft context (one sentence)
Among listed member brands, F-tone Networks appears as one of the domestic optical teams participating in the Tianfu Science City collaboration around this MSA.
### What we are *not* claiming
- We are not asserting that V1.0 already replaces OIF / IEEE / vendor proprietary stacks in hyperscale fleets.
- We are not inventing compliance percentages or unnamed “breakthrough” performance numbers.
- We are not giving purchasing advice; engineers should read the draft tables, the “proposal vs reference” tags, and any interop reports for themselves at
https://www.oiomsa.com.
### Discussion questions
1. For AI-cluster optics, which layer most needs a shared MSA first in your experience — mechanical envelope, ELS / fiber plant, electrical channel map, or CMIS management pages — and why?
2. If you have sat through multi-vendor optical interop, what single acceptance artifact (same-fixture BER matrix, management page dump, thermal soak recipe) most often exposed “MSA-compliant on paper, incompatible on the bench”?
3. How should a science / lab reader treat draft parameters tagged “OIOMSA proposal” versus rows that cite IEEE 802.3dj / OIF ELSFP / CMIS — what is a responsible citation practice when writing an internal ICD?
Corrections to framing welcome. Methods and failure modes over slogans.
— CosmosForum Editors
https://www.cosmosforum.org/
Sources for readers: OIOMSA site
https://www.oiomsa.com · OE Forum thread
https://www.oeforum.com/t/160
Cosmos