20 use cases · 6 domains · colocation and GPU cloud

Situations you recognise. Answers on one screen.

Each use case starts from a moment an operator knows: a UPS on battery, a GPU that stalls a job, a tenant riding a fault, a hall that cannot be sold. Each one names the SynapseDC modules that answer it.

20Use cases
6Domains
2Business models in the first release
13Modules they draw on
01SeeEvery alarm scoped to the site, the building and the estate in one model.
02UnderstandWho is affected, what it costs, and the ranked cause with evidence.
03ActThe next step ordered by money and customers at risk, approval-gated.
04PlanSellable capacity, the next hall and the records that keep the loop honest.

Flagship use case · every datacenter

One fault, one chain.
Impact, cost and the next action in a minute.

This is not a separate product. It is what alarm scope, the estate model, the money model and Opstral AI do together whenever something fails. It does not care whether the alarm came from a UPS, a CDU, a fibre trunk or a GPU: the fault is scoped to the site, the services and customers behind it are read from the physical paths, the money is charged to one issue, and the recommended step waits for approval when it is disruptive.

Output: incident with services, customers and money attachedOutput: ranked cause with evidenceOutput: approval-gated action, recordedWorks across: power · cooling · network · GPU · access
01ScopeSite, edge, dependency or downstream. Downstream never counts on its own.
02ImpactServices, customers and premium customers read from the busway, the trunk or the job.
03MoneyLost so far, credits by tier, the next cliff. One issue per service.
04ActionOrdered by money and customers at risk. Disruptive steps wait for a person.

Facility 4 use cases

Power, cooling, environment and the physical last mile.

FacilityUC-F1Colocation · NeoCloud

A UPS goes on battery and nobody knows who is affected

The BMS raises a point alarm. Which cabinets, which tenants and whose SLA are worked out by hand.

The alarm is scoped to the site, an incident opens with every service on that busway, the customers and premium customers are listed, and the money per hour and the next credit cliff are on the incident.

  • Alarm scoped to the site, incident opened automatically
  • Services, customers and premium customers listed from the power path
  • Cost per hour and time to the next credit tier
  • Ranked cause with evidence, approval-gated action
< 60 salarm to incident with impact54services on the busway listed$2.6k/hexposure shown on the incident
FacilityUC-F2Colocation · NeoCloud

How long do we ride through if the utility fails now?

UPS minutes, generator readiness and fuel live in three places and are checked by walking the plant room.

One card per site: UPS minutes at today's load, generator kW and start readiness, fuel hours, and the checks behind each figure. The what-if takes any feed, UPS, side or PDU away and shows what goes dark.

  • Ride-through from live UPS, DG and fuel readings
  • What-if per feed, UPS, side, PDU, cooling unit and trunk
  • Single points of failure listed per site
  • Maintenance planned and booked as changes
14 minUPS ride-through at today's load38 hfuel at current draw7SPOF classes checked per site
FacilityUC-F3Colocation · NeoCloud

A cooling unit fails and the floor has no spare

The CRAH alarm is visible; whether the floor still has N+1 and which racks will heat first is not.

Heat balance per floor against remaining capacity, the racks served by the failed unit, inlet temperatures trending, and liquid loops with their CDUs, so the operator knows whether to move load or wait for the fix.

  • Heat balance and spare per floor
  • Racks and services served by the failed unit
  • Inlet trend and environment zones against safe bands
  • Fire, leak and access state on the same screen
1.6 / 1.7 MWheat against remaining capacityper floorcooling spare judgedzoneswith safe-band tracks
FacilityUC-F4Colocation · NeoCloud

Which PDU outlet is this server plugged into?

Cords, panels and trunks were documented at install and never again. A fault proves the record wrong.

The physical last mile is derived per site: feed → UPS → busway → PDU → outlet → PSU, and port → patch cord → panel → trunk → ODF → cross-connect. Both are drawn on the device and in the 3D datacenter layout.

  • Power chain to every PSU, cabling to every port
  • Devices with both cords on one side flagged
  • Trace views in the 3D datacenter layout
  • Records kept under change control in DCIM
every PSUmapped to its outletevery portmapped to its trunk1 CRon every record change

GPU cloud 4 use cases

Jobs, GPUs, rails and the building's effect on both.

GPU cloudUC-G1NeoCloud

One failed GPU stops a 152-GPU training job

An Xid error on one GPU stalls the whole allocation. The GPU team sees the error; nobody sees the job, the customer or the cost.

The job with the biggest blast radius is on the Command Center and GPU Fleet: the customer, GPU time lost per hour, minutes since the last checkpoint and work to redo, with a Critical incident opened on the node.

  • Per-GPU telemetry joined to the job and the customer
  • Blast radius, GPU time lost and work to redo
  • Critical incident within the polling interval
  • Revenue impact on the job's service
152GPUs stopped by one failure$625/hGPU time lost52 minsince the last checkpoint
GPU cloudUC-G2NeoCloud

A job is 24 % slower and the cause is in the plant room

CDU flow drops, GPUs throttle, the job slows. The facility team sees the CDU; the platform team sees a slow job.

Thermal slowdown is traced from the job to the GPUs to the rack to the CDU loop. The slowest job and its cause sit together, with the hardware-slowdown flags and the step-time share lost.

  • Throttle reasons and clocks per GPU
  • CDU loops and rack heat joined to the pod
  • Slowest job with step-time share lost
  • Incident on the cooling fault, not the job
24 %step time lost62 %CDU flow at the loop144GPUs slowed
GPU cloudUC-G3NeoCloud

Where should the next 256-GPU job go?

Placement is a guess between free GPUs, rack headroom, cooling state and power already paid for.

Pods are ranked for the job: free healthy GPUs, rack power headroom, cooling state (CDU for liquid), contracted headroom, kW already paid under the block or floor, and the marginal power cost per GPU-hour.

  • Fit per pod: good, tight or no
  • Power already paid for shown as free
  • Marginal power cost per GPU-hour
  • Model picker: B200, H200, H100, Gaudi 3…
8–256GPUs per placement query$0.19power per sold GPU-hourper podfit and headroom
GPU cloudUC-G4NeoCloud

GPUs are allocated, drawing power and doing nothing

Idle allocations are billed and powered, but invisible between the scheduler and the facility.

Idle jobs are listed with their GPUs, the power they draw and what that costs per day, next to the inference pods that could be capped in the peak tariff window.

  • Idle allocations by job, customer and pod
  • Energy and cost per job and per tenant
  • Power-cap savings against the GPU time it costs
  • Findings against the power contract
6 hidle allocation found in the demoper tenantenergy and cost4finding types against contracts

Network & edge 2 use cases

Backhaul, fabric and the alarms that belong to a site.

Network & edgeUC-N1Colocation · NeoCloud

A backhaul link drops: is it our fault or a symptom?

Remote PoPs raise alarms when a datacenter link fails. The NOC chases symptoms instead of the cause.

Every alarm carries a scope: site, edge (counted at both ends), dependency or downstream. Downstream symptoms never count on their own; they appear under the causing incident. Edge redundancy reads redundant, lost or isolated.

  • Scope on every alarm, downstream never double-counted
  • Edge redundancy per site
  • Ranked root-cause hypotheses with evidence
  • A completed change cited by the RCA marked as the cause
4scope classesboth endsedge links counted0downstream symptoms counted alone
Network & edgeUC-N2NeoCloud

Four fabric cables down and a host lost both uplinks

InfiniBand and front-end Ethernet faults land as port alarms with no view of which node lost its rails.

Links read by plane (InfiniBand, Ethernet front-end, OOB), rails per node with ports and errors, the host that lost both uplinks named, and the transceiver or fibre trunk in the RCA with DOM readings as evidence.

  • Fabric planes instead of routing protocols
  • Rails per node: ports, errors, flaps
  • Cable incidents with transceiver / trunk RCA
  • Cable path from port to the far device
3planes: IB · Ethernet · OOBper noderail healthDOMreadings in the RCA

Commercial 4 use cases

Tenants, SLAs, credits and the power bill.

CommercialUC-C1Colocation · NeoCloud

Which issue is costing the most right now?

Revenue at risk and SLA credits are reconstructed after the event, and never agree between teams.

Each impacted service is charged to one issue, its most severe cause. Lost so far, credits by tier, the next cliff and what is at stake reconcile across issues, customers, datacenters and sites. A cost-of-delay curve orders the work.

  • Down, degraded or exposed, charged to one issue
  • Credits by tier, net of those already locked in
  • Σ issues = Σ customers = Σ sites, always
  • Cost of delay per issue
1issue per impacted service3 tiersof SLA credit tracked24 hforecast per issue
CommercialUC-C2Colocation

Which tenants are riding a critical fault right now?

A fault is live and the account team hears from the tenant first.

Exposed services are shown while the fault is live: tenants on the affected path, their SLA, what a four-hour outage would cost in credits, and the notice cadence due to each.

  • Exposed tenants per fault, premium first
  • Potential credits for a four-hour outage
  • Customer notices on an update cadence
  • Why at risk, on the tenant's page
4 houtage scenario priced15/30/60minute notice cadenceper tenantwhy at risk
CommercialUC-C3Colocation · NeoCloud

Free racks are not sellable racks

Space says yes, power says no, cooling says maybe. Sales promises what the hall cannot deliver.

Space, power, cooling, ports and GPUs per site and hall, net of planned devices, contracted power, approved plans and idle allocations. Net available is what can be sold today.

  • Capacity by dimension, by site and hall
  • Reservations: reserved, committed, pipeline, requested
  • PUE and energy per site
  • Forecast against the 85 % line
6capacity dimensions4hold classes netted offper hallspace and power
CommercialUC-C4Colocation · NeoCloud

We pay for power we don't use

Take-or-pay floors, demand ratchets and idle colocation blocks are found when the invoice arrives.

The bill is priced against the tariff and the contract: energy, demand charge on the floor or peak, idle kW, and findings when a block is nearly used, a new peak sets the ratchet, or draw rises with no change in progress.

  • Bill per site against real tariffs
  • Idle kW paid but not sold
  • Findings raised as alarms and incidents
  • Cost per sold MW and per sold GPU-hour
4contract finding typesper siteidle kW priced$/GPU-hpower against price

Security & access 3 use cases

Logical, OT and physical security as one case.

Security & accessUC-S1Colocation · NeoCloud

A badge-in at 02:10 and an ACL change on the WAN edge

The door system and the network logs never meet. Two events, two tools, no case.

Physical and logical detections are correlated: the badge read, the unapproved config change on the edge router outside any change window, and the user, in one case on NIST 800-61 phases with ATT&CK techniques.

  • Cross-domain detections: PACS + config drift
  • Cases with phases, evidence and owner
  • ATT&CK coverage and gaps
  • Change windows as context for every detection
1 casefrom two domains800-61phases on every caseATT&CKEnterprise + ICS
Security & accessUC-S2Colocation · NeoCloud

A UPS network card still has default credentials

Plant controllers sit on the OT network with vendor defaults and Modbus open to anything that can reach them.

OT zones are rated on IEC 62443 (target vs achieved level), default credentials and a Modbus write on a UPS card raise a case, and hardening checks per device family show the drift.

  • OT zones with SL-T vs SL-A
  • Default-credential and Modbus-write detections
  • Hardening checks and unauthorised drift
  • SSVC decisions from CVSS, EPSS and KEV
62443zones and levelsSSVCvulnerability decisionsper familyhardening checks
Security & accessUC-S3Colocation

Who entered the cage, and were they escorted?

The access audit is a quarterly spreadsheet; tailgating and held-open doors are found by chance.

Twenty-four hours of entries and badge reads per site, exceptions (tailgating, forced or held doors, anti-passback, unescorted visitors, overstays), who is on site now, and the quarterly rights review.

  • On site now, by role and reason
  • Exceptions with evidence and owner
  • Access rights review: expired and unused badges
  • Audit trail per door and person
8exception types24 hlog on every sitequarterlyrights review

Plan & build 3 use cases

Capacity, plans, records and commissioning.

Plan & buildUC-B1Colocation · NeoCloud

What does a new 2 MW hall cost, and when can it go live?

A new hall is planned in a spreadsheet, priced from memory and approved by email.

A template sizes the hall, benchmarks price it, lead times schedule it, rules check it, the approval path follows the CapEx band, and the plan pack carries drawings, BoM and the business case to sign-off.

  • Templates and benchmarks, versioned
  • CapEx, NPV, payback and phases
  • Rule checks and readiness
  • Plan pack, review portal and approvals
59templates230benchmarks6plan families
Plan & buildUC-B2Colocation · NeoCloud

Which servers are past end of sale, site by site?

Refresh candidates are found by walking the halls or by vendor notice.

Lifecycle per device: install date, warranty, support contract, vendor end of sale and support. A refresh plan selects every eligible device at a site, splits them over waves and sources the replacements.

  • Warranty, support and vendor dates per device
  • RMA cases and spares per part family
  • Refresh plan over waves
  • Sourcing from stock, site or vendor
4lifecycle statesper modelend of sale and supportwavesfor every refresh
Plan & buildUC-B3Colocation · NeoCloud

Install a rack of GPUs without losing the record

The build team installs, the record is updated later, and the live estate starts from a record nobody trusts.

The install is planned work under a change request: U reserved, device installed as a record, ports connected, cords to outlets, and the work order, kit and commissioning gates tracked to handover.

  • Reserve U, install, connect under one CR
  • Work orders with kit status and sign-off
  • Commissioning L1 → L5 in order
  • Handover completes the plan and releases holds
1 CRon every writeL1–L5gates in orderper WOkit and crew window

Bring the situation your team keeps dealing with.

Bring the fault your team keeps dealing with. We walk it end to end on a demo estate shaped like yours, then agree what a one-site pilot should prove.