"UPS-2 Is on Bypass" Is Not a Sentence a General AI Understands. Colo-Tuned Models Learned It in 2026.

You tried this already. Some time in 2024 you or your operations manager pasted a remote-hands ticket into a chatbot to see whether it could draft the reply, and it told you to consult a licensed electrician. You pasted an alarm string from Liebert iCOM and it produced four paragraphs of confident nonsense about uninterruptible power supplies in general. You closed the tab and concluded that this trade was too specialised, and for that generation of tools you were right.

What changed in 2026 is that vertical models — models taught one industry's own language on that industry's own records — became a real category rather than a marketing line. The reason is unglamorous: the general models are excellent at English and bad at trades, because a trade is mostly abbreviations, units and edge cases that nobody ever writes down.

The words your night shift uses that nothing off the shelf knows

Start with the one in the headline. "UPS-2 is on bypass" has at least three meanings on your floor. On maintenance bypass, during a scheduled Vertiv or Eaton visit, with the wrap-around switch closed and a vendor engineer standing in front of the cabinet — that is a planned condition and the correct response is to note it in shift turnover. On static bypass at 02:14 with no vendor on site — that is the load running raw on utility with no battery behind it, and the correct response is a page, a check of the generator's readiness and a call to whoever holds the service contract. Same four words. Completely different night.

A vertical model is a general model that has been taught one trade's vocabulary, units and exceptions — here, that "on bypass" during a scheduled preventive-maintenance window is paperwork, and the identical phrase at 2am with no work order open is an emergency.

Then there are the units, which are worse, because a general model will answer confidently and be wrong by a factor. Ask one how much power a 30-amp circuit at 208 volts delivers and it will multiply 30 by 208 and tell you 6.24 kilowatts. In your building that circuit is three-phase: 30 x 208 x 1.732, so about 10.8 kVA, and after the eighty-percent continuous-load derate the customer can actually plan on roughly 8.6 kW. Get that wrong on a capacity question and you have either sold a customer power you cannot deliver or left a quarter of a cabinet unsold.

A short list of the things it gets wrong

• A feed and B feed. A general model treats them as labels. They are the two independent paths, and whether a customer is dual-corded on both determines whether pulling one whip is routine or an outage.
• C13, C19, L6-30R, L21-30, CS8269. Receptacle types. Substituting one for another in a reply is how a technician arrives at a cabinet with the wrong cord.
• "RPP 3, panel B, pole 17." A location in your power distribution, not a typo.
• Tier III. The Uptime Institute classification, not third-line support.
• N+1, 2N, concurrently maintainable. Contractual commitments with money behind them, not adjectives.
• "String 2, jar 14, impedance 15% over baseline." A battery finding that starts a replacement conversation, not a general observation.
• PUE 1.42. A ratio. Not 1.42 kilowatts, which a general model has been known to assume.
• 5CP. The coincident peak days that set a large part of next year's demand charges in PJM territory — the single most expensive acronym on this list.
• Smart hands versus remote hands. Different scopes and different billing increments in your own service agreement.

What "tuned on your own records" actually means here

The version that works is not a model that read the internet about data centers. It is a model that has been shown your closed tickets, your change records, your alarm history with the outcome attached, your equipment list down to make and model, and your customer roster with who is single-corded and who is not. That last file is small and it changes everything, because it converts "a breaker tripped" into "a breaker tripped on the B feed of cabinets 22-04 through 22-09, and two of those customers are single-corded."

flowchart TD
  A["Alarm: UPS-2 on bypass, 02:14"] --> B["Tuned model reads alarm text plus site records"]
  B --> C["Is a vendor PM window open tonight?"]
  B --> D["A/B feed status on that RPP"]
  B --> E["Which cabinets on that branch are single-corded"]
  C --> F{"Planned maintenance bypass?"}
  D --> F
  E --> F
  F -->|Yes| G["Log it, no page, flag for shift turnover"]
  F -->|No| H["Page on-call CFT with the affected cabinet list"]

02:14 on a Wednesday, both ways

The old way: PagerDuty fires. Your critical facilities technician wakes up, opens the laptop, logs into EcoStruxure IT or Environet, reads the alarm, checks the maintenance calendar in a different system, remembers that the Eaton engineer was on site for the annual capacitor and fan replacement, goes back to bed. Twenty-two minutes, all of it wasted, and he does it again at 03:40 for a door held open by the same vendor.

The new way: the same alarm hits a triage step first. It sees an approved change record open until 06:00 for UPS-2, sees that the paralleled unit is carrying load normally, sees that no cabinet on that branch is single-corded, writes one line into the shift log and does not page. At 03:55 a different alarm arrives — a CRAH supply temperature climbing with no change record behind it — and that one pages, with the affected cabinet list and the last four readings already in the message.

The point of the tuning is not that the model is smarter. It is that it knows which of those two nights is which, because it has read four hundred of your previous nights.

The arithmetic on false pages

Illustrative assumptions for a single-site operator running a two-technician on-call rotation.

That is roughly $28,000 a year, and it is the smaller benefit. The larger one does not show up on a spreadsheet: a technician who is woken three times a night for nothing stops reading the pages carefully, and eventually one of the pages matters.

Where the tuned model must not be allowed to decide

Suppression is the dangerous half of this. A model that decides not to page you is making a judgement about your risk, and the failure mode is silent. So put hard limits around it in writing before it goes live.

Some alarms should never be suppressible by anything, no matter how confident the model is: fire and clean-agent system alarms, very-early smoke detection at any level, generator start failure, automatic transfer switch failure to transfer, and any loss of redundancy that leaves a customer on a single path. Those page every time. Second, tuning does not survive a facility change — add a switchgear lineup or replace a chiller plant and the model's picture of your site is stale until you show it the new records. Third, the alarm suppression rate is a number to review monthly with the chief engineer, not a setting to configure once. If the suppression rate climbs and nobody asked for it, something has drifted.

Frequently asked questions

Do we have to hand over our whole ticket history to somebody?

You have to make it readable to the model, which is not the same as publishing it. Ask for written terms that your content is not used to train anything shared with other customers, keep the connection inside your own environment where you can, and treat it as a subprocessor in your SOC 2 program. Several operators run this on-premises for exactly this reason; Cisco's own large rollout put weight on the same point.

Our alarm text is a mess of vendor codes. Is it even usable?

The messier it is, the more the tuning is worth, because the mess is what a general model cannot decode. The one thing you do need is the outcome attached to past alarms — what actually happened after each one. If your tickets never recorded the resolution, start recording it now; three months of honest outcomes is worth more than three years of raw alarm text.

How is this different from the alarm-correlation feature our DCIM vendor already sells?

Correlation groups alarms that arrive together. What is new is reading the language: the free-text change record, the vendor's note, the customer's email saying they are single-corded until Friday. That is the material the rules engine has never been able to touch.

Does it write the customer notification too?

It drafts it, and a human sends it. Outage notifications are contractual documents in this business — they get read back to you during credit negotiations. Draft, review, send.

A closing note from us: when redundancy drops, the phone starts ringing before your notification goes out, and it rings on the main line at 2am. CallSphere builds AI voice and chat agents that pick up the business line and the web chat at any hour, identify the caller and their cabinet, log what they are seeing, and page the on-call engineer — so the customer gets a person's answer in seconds rather than a voicemail box while your technician is on the floor.