SOP / MOP / EOP Drills | Case Study 4

Drawn from the author's operating experience. Client details are anonymized.

Data Center Strategies: Inside Hyperscale series Author: Scott Stillings

The point of this case, in one paragraph

A procedure for a new facility is a hypothesis about a plant nobody has operated yet. This case is about how that hypothesis gets tested before it gets trusted: writing the SOP, MOP, and EOP library for the plant that actually exists, then running slow, consequence-bearing evolutions on major equipment, medium-voltage systems, diesel generators, cooling systems, with each shift, with no time pressure, predicting indications aloud before acting, and stopping openly when the indications differ from the SOP.

That method surfaced SOP errors, taught the team that it is safe not to know, and revealed something no single shift could have seen on its own: that automatic transfer switch (ATS) transfer times varied from instantaneous to multiple seconds. No uptime figure, cost saving, or percentage improvement is claimed for this case, because none was measured in a form that can be published. What is recorded here is qualitative: what was done, and what changed in how the team worked.

1. Situation

A newly constructed, new-design, liquid-cooled AI facility was approaching turnover. The author was brought in to build the operation from scratch: hire the team in advance of turnover, prepare the standard operating procedures (SOPs) and emergency operating procedures (EOPs), set shift-operations expectations, and take over at turnover, the signing moment after which responsibility shifted instantly to a team that had never owned or operated a data center.

Three features of the situation made the procedure problem harder than a document count would show:

The procedures had never been exercised. A commercial nuclear procedure may be thirty years old, exercised dozens of times, carrying lessons from generations of operators. A data-center procedure for a new AI-era design may never have been exercised at all. The configuration of the equipment often did not exist before the contractor handed it over. There was no employee who had experience on it, and nobody who could be hired to operate it. The team had to build the experience and the capability in real time, while the facility was already in service.
The team was new to the plant, and the plant was new to everyone. The operators hired had real operating backgrounds, but none of them had operated a data center before, and none had operated this plant before, because the plant had never been operated by anyone. A procedure written before turnover was therefore written by people who had never operated the building it described.
The first year was going to test the procedures whether or not anyone planned for it. The following twelve months brought, as recorded in the author's account, a cluster of early equipment failures, seasonal cooling transitions, chiller tuning and calibration problems, and a cascading loss-of-cooling incident. A procedure error that survived until an incident was an error that would be discovered at the worst possible moment, under alarm, at 3 a.m., by the least experienced person on shift.

The question was therefore not whether the procedures had errors. The question was whether the culture would catch them before they caught the crew.

2. What was found

The findings below are the author's account of the facility, stated qualitatively. No site, employer, date, or measured result is given, and no figure in this section is a measured outcome.

Finding 1: The procedures were hypotheses, and some of them were wrong. Because the facility was brand new and the procedures had never been used, the team discovered errors and things that did not work as the SOP anticipated once the plant was running. That is the normal condition of a new facility, and it is the condition most handover plans understate: the least reliable procedures a facility will ever have are the ones written before turnover.

Finding 2: The plant behaved differently from shift to shift, and no single shift could see it. Automatic transfer switches in the cooling system transferred in times that varied from instantaneous to multiple seconds [Author's account, qualitative range, no measured times recorded].

One shift experienced an instant transfer, another a multi-second transfer, and neither would have known the behavior varied until the teams shared their separate experiences with each other. The variation was not a defect in any one switch, as far as the account records. It was a property of the plant that only became visible when observations were pooled across shifts.

Finding 3: Indications differed from the SOP, in small ways that mattered. Standing in front of medium-voltage switchgear, the team would discuss what indications they expected when closing in a 34.5 kV feed [Author's account], and sometimes the indications were slightly different. A small difference in an expected indication is easy to dismiss, the job still worked, the feed still closed, and dismissing it is exactly how a procedure starts lying about the building. Each small difference was, in the author's account, an "aha moment": proof that nobody present knew everything, and that the team learned it together.

Finding 4: The gap was not knowledge, it was permission. The operators were capable and experienced in other high-consequence settings. What they did not yet have was a shared, practiced habit of stopping a job in the open when the plant disagreed with the book, and of treating the disagreement as information rather than as a delay, a failure, or a reason for blame. Without that habit, SOP errors stay hidden, because the person who finds one has no safe way to say so.

Finding 5: Reliability, in this account, is day-to-day attention, not heroics. The author's doctrine, as recorded in the account, is that reliability is day-to-day attention to detail, trend, anticipation, and condition-based response: the quiet dedication of individuals who maintain defense in depth by keeping not only the primary paths functional, maintained, and preserved, but the secondary paths as well.

Big crises produce heroics, and heroics are memorable. They are not the day-to-day in a well-designed, well-maintained facility. The day-to-day is noticing a trend before it becomes an alarm, and noticing that an indication does not match the procedure before the procedure is trusted with a real event.

3. What was done: the method

Method numbers in this section, the 27 Gate checks, the score bands, the 7-day review window, the Top-10 list, are the consultant's own method, not verified facts.

The method has four parts: write procedures to a standard that makes them usable at 3 a.m.; test them in slow, consequence-bearing evolutions; validate them by drilling; and share what each shift learns so the whole team sees what no single shift can.

3.1 Authorship: write a procedure an operator can follow at 3 a.m.

SOPs, MOPs, and EOPs are not interchangeable, and the library was written as three distinct classes:

SOP, routine operation. How to do a routine job the same way every time: start a chiller, transfer a load, take a pump out of service for maintenance. The normal path, written down so that normal does not depend on memory or on who happens to be on shift.
MOP, method of procedure. The plan for a specific piece of work on a live plant: a one-time job, with a defined scope, a sequence, a risk assessment, and a back-out plan if something goes wrong. Almost everything that happens in an energized building, vendor maintenance, a breaker replacement, a controls change, happens through a MOP, scheduled into a window and deconflicted against every other team working in the same building at the same time.
EOP, emergency operating procedure. The one run when something has already gone wrong, written for the moment when judgment is hardest to trust because the alarms are coming in fast and the stakes are high. The EOP exists so the crew does not have to invent a response. They follow the steps, in order, until they reach the step that allows them to stop.

Every procedure in the library was written to the same test, which the author applies to every document: simple to use, easy to access, reliably accurate. Simple to use means the steps are written in the order they are actually performed, in plain language, with no step that requires the reader to guess what the author meant. A procedure that needs an expert standing next to the operator to interpret it is not a procedure; it is a hint.

Easy to access means it can be found when it is needed, where it is needed, without a search through three systems and a phone call. Reliably accurate means the procedure describes the building as it actually is, not as it was designed, the hardest of the three, because buildings change, setpoints are adjusted during an incident and left adjusted, and a vendor modifies a control sequence while the as-built drawing never catches up.

In practice, the authorship standard applied in this case was:

One procedure, one job, one document. A header block states the purpose in one sentence, when to use it, when not to use it, the prerequisites, the notifications required before starting, and the abort authority, who may stop it, and the words to use.
Numbered steps, one action per step. Each step names the equipment exactly as it is labeled in the field. If the label is wrong, the label is fixed before the procedure is published; the procedure is not annotated to work around a wrong label.
An expected indication after every state change, and what to do if it does not appear. Stop, hold, or back out; never "continue and see". A step without an expected indication is a step the operator cannot verify, and an unverifiable step is where errors hide.
Hold points before irreversible actions, verified by a second authorized person. A back-out plan before the first irreversible step, and a stated point of no return.
Times, not vibes. The wait is stated, and the indication that ends it is stated.
Field validation before issue. The author walks every step in the field with an operator who has not written it, on the real plant, in the real state the procedure assumes. Steps that cannot be performed as written are rewritten, not annotated. EOPs are field-validated after energization.
Version control is safety control. One controlled copy, with a version number, an owner, and a review date. A superseded MOP in a drawer is a live hazard.

Change control sits over all three classes. Nothing in a live facility changes without a reviewed, approved change: the procedure is updated, the training is updated, the people who will use it are told, and the old version is retired so that nobody follows it by accident. A change made in the field and never written down is not an improvement. It is a trap for the next crew, who will follow the book and find that the building no longer matches it.

3.2 The consequence-bearing evolutions method

Shortly after turnover, once the team owned the systems and could operate them under their own SOPs, the author gathered each shift to perform specifically designed evolutions on major equipment, medium-voltage systems, diesel generators, cooling systems, deliberately with no time pressure, going very slow, discussing along the way what they expected to happen next.

The design of these evolutions is the heart of this case, and it is worth stating precisely, because it is easy to copy badly:

Real consequence, real safety risk, no time pressure. These were evolutions on live major equipment, not classroom exercises and not tabletop discussions. The consequence was real, which is what made the learning stick, and the absence of time pressure is what made the learning safe. A team that is rushed through an evolution learns to hurry. A team that is given time learns to notice.
Predict indications aloud before acting. Before an operator opened a valve, started a pump, closed in a feed, or changed a mode, they said what they expected to see, which indications would move, in which direction, and by roughly how much. The prediction, not the action, was the point: a wrong prediction is information, and it is cheapest when it is caught before the action is taken.
Stop openly when indications differ. If the indications did not match the prediction, the operator stopped and said so, in front of the team. Stopping was the correct action, not a delay to be explained away. It was okay to stop. It was okay to ask questions. It was okay to pause and dive deep into the technical information or seek help, in an open and collaborative way.
Teach that it is safe not to know. The evolutions were deliberately structured so that the leader did not know everything either, and said so. Standing in front of medium-voltage switchgear, discussing what indications were expected when closing in a 34.5 kV feed [Author's account], and finding the indications slightly different, was an "aha moment" precisely because it was shared: nobody present knew everything, and the team learned it together. That is what let individuals feel safe and free to be curious.
Every shift, separately. Each shift performed the evolutions itself, rather than one shift demonstrating to the others. That is what made the ATS discovery possible: each shift's own experience, recorded and then shared, became the evidence that the plant behaved differently at different times.

The mechanisms, as the author states them, are simple to state and hard to sustain: promote curiosity; establish psychological safety so individuals ask the questions they are curious about and encourage each other to dive deeper and understand more; and through that curiosity keep teams agile against changes in technology and new system deployments, because they are curious about how new things work and why things are the way they are. The warning that goes with it is direct: this cultural attribute is perishable. It has to be honed and continuously driven by the leader, or it fades.

3.3 The ATS transfer-time discovery: a worked example

The ATS finding is the clearest illustration of why the method works, and why a single shift's experience is never the whole picture.

During the cooling-system evolutions, the teams observed the automatic transfer switches transferring in times that varied from instantaneous to multiple seconds [Author's account, qualitative range, no measured times recorded]. One shift experienced an instant transfer. Another experienced a multi-second transfer. Neither shift, on its own, had any reason to think the behavior varied: each shift's own observations were consistent, within that shift's experience, and each shift could reasonably have written down what it saw as "how the ATS behaves".

The discovery only happened because the observations were shared across shifts, at handover and in the evolution debriefs, and because the sharing was treated as evidence rather than as a contradiction to be resolved in favor of one shift's account. Shared observation became collective learning: the team now knew that transfer time was a variable, not a constant, and could plan, write procedures, and set expectations accordingly, rather than one shift writing a procedure that assumed an instant transfer and another shift discovering, during a real event, that it was not instant.

The pattern is this: within any one shift, transfer times fell in a narrow range, while across all shifts the range was wide, from instantaneous to multiple seconds. No transfer times were measured or recorded in a publishable form, so no values are given here. The grouping of observations by shift is described qualitatively, not as a count of how many transfers each shift observed.

3.4 Drill validation: a drill is a test of the procedure first

A drill is a test of the procedure, the operator, and the plant, in that order. If the drill fails, the first suspect is the procedure, not the person. That ordering matters, because it decides where the fix goes: if outages are caused by careless people, the fix is exhortation, which does not work; if they are caused by procedures that are hard to use, hard to find, or wrong, and by training and culture that do not support them, the fix is the procedures, the access, the training, and the culture.

The drill types are distinct, and the record must say which one happened:

Tabletop, talk through the sequence, no plant touched. It proves the team knows the sequence. It is a discussion, not a drill, and must not be recorded as one.
Walk-through, perform the steps in the field without changing plant state. It proves the procedure matches the field.
Injected-fault drill, actually create the failure under controlled conditions. This is the only type that validates timing. The decision to inject on live load, and the method, is the duty manager's, under the site's own MOP and permit, never the consultant's, and never without that approval.
Full IST-linked drill, integrated systems testing scenarios observed from the operator's side. Observation only: the drill program starts where IST ends, and IST is not a substitute for drills.

Pass criteria are stated before the drill, not invented afterwards:

First stabilizing action inside 60 seconds of opening the document [Practitioner target, AI Data Center Guide template, not a standard]. The point of the target is that an EOP must give the operator the first stabilizing action fast; a procedure that has to be read end-to-end while a hall heats is not a usable procedure.
The procedure as written works, every step performed as written, in order, without improvisation. Any improvisation is a procedure defect, recorded and fixed.
Indications match, every expected indication appeared within the stated time.
Communications worked, the right people were notified, in the right order, and the handover note was complete.
Return to normal is also drilled: the drill is over when the plant is back in its normal state, the log is written, and the handover note is complete.
The debrief produces owned actions with dates before the team leaves the room. Drill records are filed with the procedure, not in a separate folder no one reads.

After any real incident, the EOP used is reviewed within 7 days and re-drilled if it was changed [Consultant's method]. A drill that "passed" because the fault was not actually injected is recorded as "not validated". Never fault-inject on live load without the site's own MOP, permit, and duty-manager approval, and never run a drill the EOP itself does not authorize.

Cadence, as the consultant's own method, is: Top-10 EOPs drilled at least annually each; loss-of-power and loss-of-cooling drilled at least twice a year in the first year; one injected-fault drill per quarter in the first year, as a recommendation to agree with the duty manager, not a default; and a tabletop for any EOP changed since its last drill, before it is reissued [Consultant's own method, recommended cadence, to be set by site risk].

The Top-10 starting list for a site is: loss of utility with generator start and transfer; UPS fault or UPS on bypass; loss of cooling in an air-cooled hall; loss of cooling in a liquid-cooled hall (CDU or pump failure); coolant leak, small or large, with isolation; loss of BMS view or loss of supervisor;

fire alarm or gas discharge; generator fails to start or fails under load; chilled-water or facility-water loss or contamination; and loss of a distribution path, such as a breaker trip or bus fault. The site adds its own: seasonal extremes, fuel-system fault, water ingress, and any security incident affecting the hall.

The expected shape of SOP-error discovery over successive drill cycles is that most errors are found in the first cycles, when the procedures are still hypotheses, and fewer new errors appear in each later cycle as the library matures. No error count was recorded in a publishable form, so no counts are given here. The point is cumulative: a library that has been drilled is a library that has been corrected.

3.5 Sharing: shift handover as the mechanism that makes one shift's learning the team's learning

None of the above works if learning stays on the shift that found it. The mechanisms that carried learning across shifts in this case were ordinary instruments of operations, used deliberately:

Shift handover transferred risk, not status alone. The outgoing shift briefed the incoming shift on what had changed, what was degraded, what was being watched and why, and what the next shift should expect, a continuous narrative, not a checklist of completed tasks. The ATS variation is the example: it only became team knowledge when it was handed over.
The corrected procedure library was the shared memory. When an evolution or a drill found a procedure error, the finding was recorded, the procedure was corrected, and the correction was shared. The review asked what in the procedure, the training, or the plant made the outcome likely, not who was to blame.
The least experienced person can stop the job. Abort authority was real and named in the procedures: who may stop a task, and the words to use. A team that cannot stop is a team that will keep going past the point where stopping was cheap.
That matters most at 3 a.m., which is when the method is actually tested: an operator alone, tired, under alarm, with a procedure that does not quite match the indications, needs to know, from experience, not from a briefing, that stopping and calling for help is the expected behavior. That knowledge is only built if stopping is rewarded in daylight first.

4. Outcome, as recorded in the author's account

This section reports only what the author's account records, in qualitative terms. No measured outcome is claimed. There is no PUE figure, no downtime figure, no cost-saving figure, and no percentage improvement in this case study, because none is available in publishable form, and inventing one would mislead the reader about what a procedure and drill program can prove.

What the account records is:

SOP errors were found in the field, before they caught a crew. Because the facility was brand new and the procedures had never been used, the evolutions surfaced errors and things that did not work as the SOP anticipated. That was the teaching moment, and it happened on the team's terms, slow, in daylight, with no time pressure, rather than during a real event.
The ATS transfer-time variation became known to the whole team. One shift's instant transfer and another's multi-second transfer stopped being two private experiences and became one shared fact about the plant, recorded and available to the next person who wrote or followed a procedure that depended on it.
Stopping became normal. Operators learned, by doing it in the evolutions, that it is okay to stop, okay to ask questions, and okay to pause and dive deep into the technical information or seek help, in an open and collaborative way. The author records that as the foundation for the other changes: a team that will stop in daylight will stop at 3 a.m.
Reliability was practiced as day-to-day attention. Trend, anticipation, and condition-based response, watching what indications should look like, and noticing when they do not, became the team's working method, not a slogan. The secondary paths were maintained with the same attention as the primary paths, because the secondary path is the one that has to work on the day the primary path does not.

What did not happen, as far as the account records, is equally important: the account does not record a measured improvement in any performance metric, and this case study does not claim one. A procedure library that has been corrected is not the same claim as a plant that is measurably more efficient or more available, and the two should not be conflated.

5. What changed afterwards

The changes recorded in the account are changes in how the team worked, not changes in the plant's measured performance:

Procedures stopped being hypotheses and became records of the plant. Field validation and drill findings were fed back into the SOP, MOP, and EOP library, so the library described the plant as operated, not the plant as designed. A procedure is not written once. It is exercised, corrected, and rewritten for as long as the building runs. The day a team stops doing that is the day the procedure starts lying about the building, and a lying procedure is worse than no procedure at all, because it gives the crew confidence it has not earned.
Predicting indications aloud became a habit, not an exercise. The evolution practice, say what you expect before you act, carried into ordinary operations, so that a mismatch between expectation and indication was caught as a question to answer rather than filed away as a curiosity.
Drills tested the procedure first, then the operator. The ordering, procedure first, person second, plant third, meant drill failures produced procedure corrections with owners and dates, rather than retraining as the default answer.
Knowledge that had been held by individual shifts became held by the team. Shift handover, the corrected procedure library, and the shared ATS observation are all mechanisms for making knowledge collective. A team that depends on one shift's memory of a quirk is one roster change away from losing it.
The first year ended with the team knowing what it still did not know. Modes that had never been exercised, control sequences that had only been tested at partial load, and procedures that had not yet been drilled were listed as residual risks, not assumed to work. That list, not a claim of completion, is the honest output of a first year.

6. Research and context: why this case matters beyond one facility

This section is industry context from published sources, labeled per figure. It is not a description of the facility in this case, and its figures must not be read as results for that facility.

The human and procedure share of outages is rising, and procedures are the largest preventable cause. In Uptime’s 2026 analysis, 92% of respondents said human error was at least a minor contributor to their most recent impactful outage [VERIFIED, Uptime Institute, Annual Outage Analysis 2026, May 2026, Fig. 13, Resiliency Survey 2026], and failure to follow established procedures was the leading driver of human-error outages at 59% (n=199) [VERIFIED, same source, Fig. 14].

In Uptime's 2026 analysis, failure to follow established procedures was the leading driver of human-error outages at 59% (n = 199) [VERIFIED, Uptime Institute Annual Outage Analysis 2026, May 2026].

For Category 3–5 outages, 87% of operators believe better management and processes would have prevented their most recent incident, on the Uptime survey's own base [VERIFIED, Uptime 2025 survey PDF for the 87% figure, different base].

The cost side is material: 57% of the most recent significant, serious, or severe outages cost more than $100,000, and 1 in 5 cost more than $1 million [VERIFIED, Uptime Annual Outage Analysis 2026, May 2026; base: respondents’ most recent major outage, 2025 survey].

The two procedure-failure modes sit side by side, and they need different fixes. Sometimes the crew did not follow the procedure, and sometimes the procedure was wrong, incomplete, or impossible to follow as written. That distinction decides where the fix goes, and it is why this case tests the procedure first in a drill: a failure-to-follow finding is a training and authorization question, while a flawed-procedure finding is an authorship and field-validation question. Treating both as "operator error" fixes neither.

EOPs are built to be field-validated after they are written. The documented EOP development process runs: narrative Top-10 list, then technical review by owner, operations, engineer, and construction, then field validation after energization, then annual review [VERIFIED, FacilitiesNet, "Develop Site-Specific Emergency Operating Procedures for Critical Facilities"]. That sequence is the industry version of this case's method: a procedure that has never been walked in the field after energization is not yet a procedure, it is a draft.

Uptime's "Top 14" guidance makes the same point from the drill side: the best readiness is regularly simulating every EOP scenario, including disconnecting pumps, chillers, and CRAHs to trigger authentic BMS alarms [VERIFIED, Uptime Institute, "Top 14 Considerations for Addressing Data Center Facilities Management Risks", February 2021, practitioner guidance].

Procedure libraries are large, and their size is part of the risk. Uptime describes a good MOP as having very detailed steps, including timestamps, initial blocks, and signature fields, and notes that libraries run to hundreds of documents [VERIFIED, Uptime Institute Top 14, February 2021, via the research report]. A library of that size cannot be validated by reading it. It can only be validated by walking it and drilling it, procedure by procedure, with the people who will use it, which is why this case's method is slow by design.

There is no single public operational-readiness standard. Commissioning is covered generically by ASHRAE Guideline 0 and Standard 202; the data-center-specific ASHRAE Guideline 1.6P was only at first public review draft in October 2026, not final [VERIFIED, draft status, October 2026].

Uptime's Operational Sustainability and M&O Stamp of Approval assess operations, but they are assessments, not a step-by-step readiness checklist an operator can download and follow [VERIFIED, Uptime Institute]. That absence is why a consultant's procedure and drill framework must be labeled as the consultant's own method, not as a standard, and why this case study presents a method, not a certification.

Hiring is a constraint on procedure quality. 53% of operators report difficulty finding qualified candidates for open roles, up from 46% in 2025 (REPORTED: Uptime Institute, Global Data Center Survey 2026, July 2026, Fig. 17; n=607 in 2026 versus n=650 in 2025, via a reputable secondary summary, primary not inspected). The biggest skills gaps are electrical at 38%, junior and mid-level operations at 38%, operations management at 35%, and mechanical at 34%.

A new facility cannot hire its way into a procedure library that matches its plant; it has to write the library, walk it, and drill it with the team it has, which is the premise of this case.

Fatigue is part of the same picture: sustained overtime at or above 10% correlates very strongly with increased rates of incidents, including outages and serious injury [VERIFIED, Uptime Institute Top 14, February 2021, practitioner guidance]. A rota that depends on sustained overtime is therefore a readiness finding, not a resourcing preference, and a tired operator is the person least able to notice that an indication does not match the procedure.

One figure deliberately not quoted here: the claim that nearly 70% of early equipment failures trace to design, installation, or startup deficiencies (Donato, 2013) is dated and unverified today [UNVERIFIED, Donato, Emerson/Vertiv ERS, 2013; do not present as a current statistic]. It is omitted from the argument above for that reason. Similarly, no market-size figure for transition-to-operations consulting is quoted, because none was found in public sources that measures this niche specifically [UNVERIFIED, no public source found; not quoted].

7. What a reader can take away

A procedure for a new plant is a hypothesis. Test it before you trust it. Field-validate every procedure with someone who did not write it, on the real plant, in the real state the procedure assumes. Steps that cannot be performed as written are rewritten, not annotated.
Predict indications aloud, and stop when they differ. The habit costs seconds and saves incidents. Say what you expect before you act; when the plant disagrees with the book, stopping is the correct action, not a delay.
Make it safe not to know, and prove it by rewarding stopping. Psychological safety is not a value statement; it is a behavior the manager demonstrates when an operator stops a job in daylight. If stopping is punished, it will not happen at 3 a.m.
Run slow, consequence-bearing evolutions, with no time pressure. Real equipment, real consequence, each shift separately. That is how a team learns what its plant actually does, rather than what the design said it would do.
Pool observations across shifts. No single shift can see the full behavior of the plant. The ATS variation in this case was invisible until shifts shared what each had seen. Handover is the mechanism, not an afterthought.
Drill the procedure first, then the operator. State pass criteria before the drill, record which type of drill happened, and treat any improvisation as a procedure defect to be fixed. A drill that "passed" because the fault was never injected is recorded as "not validated".
Keep procedures accurate, or stop trusting them. Change control, version control, and a review after every incident or drill finding are what keep the book matching the building. A lying procedure is worse than no procedure at all.
Do not confuse a corrected library with a measured improvement. A procedure library that has been walked and drilled is a qualitative achievement until it is evidenced by drill records, a failure log, and trend data. Claim only what the evidence supports.

8. How the consulting offers map to this case

The mapping below describes what the offers cover for a client in a similar position. The two offers are used by their exact names, and nothing in this section is a promise of a result.

Offer mapping: what each offer covers in this case’s terms
Offer	What it covers, in this case's terms
Transition-to-Operations Readiness	The readiness assessment before the signing moment: people, procedures, asset information, and support arrangements checked before operations takes responsibility. Includes the scored Handover Gate: Sign, Sign with conditions, or Do not sign, applied per area or building. The procedure checks in the gate (checks 8–13 of 27) ask whether the SOP library covers the first 90 days, whether the MOP library covers every planned intervention on critical plant with hold points, a back-out plan, and abort authority, whether the EOP library covers the Top-10/15/20 predicted failure modes and has been field-validated after energization, and whether document control and change control exist. A library that has never been walked in the field is a gate finding, not a paperwork gap.
Operational Efficiency & Procedure Review	Review of the SOP, MOP, and EOP library and operating efficiency: procedure quality checks (a procedure fails review if any check fails), drill validation, and setpoint and cooling-efficiency opportunities. Advisory only, the consultant recommends operational changes and identifies where a design change would be needed, for the engineer of record to assess. He does not redesign plant, never changes a setpoint, sequence, or staging logic, never instructs a change, and never promises a PUE or saving figure. Changes are made only by the site's authorized persons under change control, with owner and engineer-of-record agreement. Authorship or rewrite of priority procedures, drill-program design, and drill observation are scoped in writing, not assumed.

Scope and limits: read before inquiring

In scope: data-center operations; transition from construction to operations; operational efficiency. Operability review, handover criteria, and operations-and-maintenance input at the operator's side of handover are in scope.
Not offered: Tier or M&O certification (only Uptime Institute awards those); engineering design or a PE stamp; commissioning re-performance or witnessing and signing of commissioning test records; 24×7 cover, acting as duty manager, or operating the site; licensed or energized work, or directing energized work; a fixed price for undefined scope, or a fixed timeline before scoping; a zero-outage guarantee, a guaranteed uptime figure, or a guaranteed PUE or saving figure. Construction and build consulting is out of scope except for operability, handover, and operations-and-maintenance input as above.
"Power In, Heat Out, Nothing Down" is the book's core model, not a consulting promise. It is not presented here as an uptime guarantee, and no statement in this case study should be read as one.

Sources and labeling

Sources consulted for this case study:

The author's operating account: reliability as day-to-day attention to detail, trend, anticipation, and condition-based response; slow, deliberately designed, consequence-bearing evolutions by each shift (medium-voltage, diesel generators, cooling) with no time pressure; predicting indications aloud before operating; stopping openly when indications differed from the SOP; surfacing SOP errors; the 34.5 kV feed indications; ATS transfer times varying from instantaneous to multiple seconds, visible only when teams shared observations; SOPs and EOPs built from scratch at a new liquid-cooled AI facility, with the team hired in advance and shift expectations set.
Research report, 1–2 November 2026, industry context, outage data, commissioning levels, EOP development process, provider coverage.
Uptime Institute, Annual Outage Analysis 2025 (via CoreSite summary) and Annual Outage Analysis 2026, May 2026; Uptime Institute, "Top 14 Considerations for Addressing Data Center Facilities Management Risks", February 2021.
ASHRAE Guideline 1.6P, first public review draft, October 2026; ASHRAE Guideline 0 / Standard 202 (commissioning, generic).
FacilitiesNet, "Develop Site-Specific Emergency Operating Procedures for Critical Facilities". EOP development process.
AI Data Center Guide procedure skeleton (60-second first-stabilizing-action target [Practitioner target, AI Data Center Guide template, not a standard]).

Case Study 4: SOP / MOP / EOP Authorship and Drill Validation