CIOS Site Plane Open-Core: Controls That Ship With the Modular AI DC
After you lock a Liquid Cooling Alias, the next RFP question is rarely about metal. It is about controls: what operating system runs when the block powers on, what telemetry you can query on day one, and what the vendor is still parking on a Roadmap strip.
This page is the late-funnel answer for that moment. CIOS — the Compute Infrastructure Operating System — ships with every MDCX modular data center block. On the site plane today it gives operators path-addressed telemetry, Modbus TCP and SNMP v2c drivers, alarms that become tickets on the same path, and usage records for operational truth. CIOS does not invoice. The core is open-core Apache-2.0. Multi-site fleet, GPU-level telemetry, and AI Ops stay published Roadmap — not shipped claims.
For envelope choice and the factory clock, see the sibling posts Liquid L1240/L1800 · 90 days EXW and Factory-tested vs field-built. Product depth lives on the CIOS product page.
Every block needs a site plane — not a BMS bolt-on
Hardware without an operating system is just metal. A modular AI plant is not a generic building with a tag dump bolted on after mechanical finish. It is pods, CDUs, immersion tanks, and loops that must behave as first-class objects from power-on.
That is why CIOS is framed as a site plane, not a building management system (BMS) substitute. A flat BMS tag list can poll points. It does not give operators a stable path identity for every sensor and setpoint, or a work queue where each ticket row is the same path the alarm fired on. CIOS is built for modular plants: you query and set by path — for example a CDU supply flow on a pod — not by hunting an opaque tag database.
One site box runs that site plane. The Ops portal is the site home operators actually use: tickets, preventive maintenance, and the site tree. A customer portal surfaces status, SLA, and usage facts. Neither portal is a multi-site NOC claim. Fleet-wide aggregation across sites is Roadmap, not a shipped open-core promise.
Methodology and why the envelope ships factory-tested live on Why MDCX. The controls story here is what runs after that envelope lands.
What ships today on the CIOS site plane
Operators mid-RFP need a fence they can paste into a controls appendix. Here is the shipped site plane, aligned to live /cios:
Path-addressed telemetry. Points are path-shaped. Drivers ingest Modbus TCP and SNMP v2c into a gateway stream and time-series store. You query and set by path — pods, CDUs, tanks, and loops as first-class objects — not a flat tag dump. Writes carry risk classes; this is not open remote control theater.
Alarms → tickets on the same path. When a CDU filter check fails or a UPS sits on battery, the work item is the plant object itself. Ticket lifecycle runs open → acknowledged → resolved → closed. Maintenance windows suppress alarms when work is planned. Webhooks and email sit on that same path-shaped queue.
Usage facts — no invoice. Measurement and usage records are open source: kWh and rack-hour style facts you can list, export, and roll up. Commercial billing, statements, and ERP stay parked. CIOS does not invoice. Facts feed reconciliation and the customer portal — no money fields.
Offline autonomy on one box. A single site box runs the site plane offline for ≥7 days, as published on the CIOS product page. That is site-plane autonomy for one box — not a fleet NOC claim and not a promise that every WAN outage is free.
Two portals, one site. Ops portal for tickets, PM, and the site tree. Customer portal for status, SLA, and usage. Capacity headroom shows remaining power and cooling before the next block lands; forecast assistants remain Roadmap.
If a vendor blurs “controls included” into AI Ops or fleet NOC language without a shipped-vs-Roadmap fence, treat that as a red flag in the RFP — not as parity with the site plane above.
Procurement reviewers usually need one more sentence for the controls appendix: the site plane is the loop you can audit on a single box after factory power-on — path identity, driver ingest, ticket lifecycle, and usage facts — without waiting for a future fleet product. Anything beyond that loop belongs in the Roadmap table below, not in the shipped column of an RFP response.
Open-core Apache-2.0 — what lives on GitHub vs commercial layers
CIOS is open-core. Drivers, gateway, time-series, path dictionary, and usage measurement (facts only — no money) are Apache-2.0. Source is public at CIOS open-core on GitHub.
Commercial layers sit above that core: site twin and capacity engine; tenant / org substrate (billing parked). Those are not the open-core story and are not claimed as free OSS. AI Ops — predictive maintenance and assistants — is Roadmap, not a commercial “already shipping” layer disguised as open source.
The architecture line that matters for procurement is simple: edge-first box. One box owns the complete site loop — drivers → gateway → stream → time-series; path addressing and CLI query/set; alarms, tickets, PM, windows; usage records and local portals. Multi-site fleet plane (cross-site rollup / NOC view, central policy, fleet capacity planning) is a separate plane, and it is Roadmap.
Read the source when you need auditability. Use the product page when you need the shipped fence. Do not treat a GitHub README marketing slip as a claims override — this blog follows live mdcx.org/cios and the MDCX brand boundary (brand MDCX only).
For EPC and operator readers, open-core is not a slogan. It is the audit path: you can inspect drivers and the path dictionary without buying a closed SCADA narrative, while twin, capacity, and tenant commercial surfaces stay clearly labeled as commercial — and AI Ops stays Roadmap until /cios moves it.
Honest Roadmap strip — what does not ship yet
MDCX publishes what ships. The Roadmap strip on /cios is an honest fence — not a promise calendar. Three items stay Roadmap on this URL:
| Roadmap item | What it is not (yet) |
|---|---|
| Multi-site fleet plane | NOC-style aggregation across sites; central policy distribution; fleet capacity planning |
| GPU-level telemetry | DCGM and per-GPU metrics beyond facility path addressing |
| AI Ops | Predictive maintenance and capacity forecast assistants |
Do not read “Ops portal” as fleet NOC. Do not read usage metering as invoicing. Do not read site-plane path telemetry as GPU DCGM. The customer brings the silicon; CIOS on the site plane today is facility path addressing and ops workflow — GPU-agnostic envelope, not a GPU business claim.
Omniverse / twin renderer as shipped open-core is also out of scope for this page. Twin capacity surfaces, where they exist commercially, are not the Apache-2.0 story above.
How CIOS pairs with Liquid Cooling blocks
Pick a block; CIOS ships with it. The Liquid Cooling dual-primary Aliases are envelope links for this trilogy — not a re-pitch of SKU physics:
- L1240C45 — empty-pad Liquid Cooling lead (UPS inside).
- L1800C45 — same 45 ft shell when UPS already sits outside.
Both are Liquid Cooling envelopes — space, cooling, and power. You bring the servers. Immersion Cooling remains a form-factor fork, not the lead story on this URL; see the Liquid Cooling hub when you need line-level options.
Factory-tested delivery and EXW honesty belong to the siblings: Factory-tested vs field-built and Liquid L1240/L1800 · 90 days EXW. This page owns the controls fence after power-on — what the plant speaks, how alarms become work, and which facts you can export without inventing a billing product.
Trilogy order for reviewers: factory-tested envelope → Liquid Alias and EXW clock → CIOS site plane. Skip re-arguing pad power here; Alias choice already lives on the Liquid sibling and the short product pages.
If you need a CapEx starting point for modeling only, published indicative CapEx is $3M/MW of IT power. That figure includes Tier II power distribution and outdoor heat rejection, not the container alone. Prices are indicative only. Actual price is per invoice. Model it in TCO — not a quote and not a CIOS price list.
Next steps
- CIOS product page
- CIOS open-core on GitHub
- Talk to sales
- L1240C45 · L1800C45
- Why MDCX
- Liquid L1240/L1800 · 90 days EXW
- Factory-tested vs field-built
Secondary: GitHub · L1240C45 · L1800C45 · 90 days EXW · Factory-tested vs field-built
FAQ
What is CIOS on an MDCX modular AI data center?
CIOS is the Compute Infrastructure Operating System that ships with every MDCX modular data center block. On the site plane today it provides path-addressed telemetry, Modbus TCP and SNMP v2c drivers, alarms that become tickets on the same path, and usage records for operational truth. CIOS does not invoice. The core is open-core Apache-2.0 at github.com/MDCX-ORG/CIOS. Multi-site fleet plane, GPU-level telemetry, and AI Ops remain Roadmap. Full product fence: CIOS.
How is the CIOS site plane different from a building BMS?
CIOS is built for modular plants — pods, CDUs, immersion tanks, and loops as first-class path objects — not a generic building BMS tag dump. Operators query and set by path. One site box runs the site plane with published offline autonomy of ≥7 days on the product page. Fleet-wide NOC aggregation is Roadmap, not a shipped claim for the open-core site plane. The Ops portal is the site home for tickets, PM, and the site tree — not a multi-site fleet console.
What is open-core vs Roadmap for CIOS?
Drivers, gateway, time-series, path dictionary, and usage measurement (facts only) are Apache-2.0 open-core. Site twin, capacity engine, and tenant commercial layers are not the open-core story. Multi-site fleet plane, GPU-level telemetry, and AI Ops are published Roadmap on mdcx.org/cios — not claimed as shipped in this blog.