When Nothing Happens,
Engineering Is Working

1 Introduction: The Paradox of Invisible Success

A data center that operates reliably does not announce itself. There are no alarms. No emergency calls at 3:00 AM. No scrambled teams racing against a cascading failure. The cooling systems hum within tolerance. The UPS systems remain on bypass, ready but unused. The BMS screens show green across every parameter. And nobody outside the operations team notices, because there is nothing to notice.

This is the paradox at the heart of critical infrastructure engineering: the better the work, the less visible it becomes. When an operations team does its job perfectly, the outcome is indistinguishable from a facility that requires no management at all. The signals of excellence are, by definition, the absence of signals. No incidents to report. No near-misses to investigate. No emergency maintenance windows to justify. Just continuous, silent, reliable operation — a condition that depends on recognizing weak signals and safety indicators before they escalate.

"Reliability is not a feature. It is a process. Systems do not remain reliable by design alone, but by daily human and organizational effort." [1]

Yet this invisibility creates an organizational problem. How does an engineering team justify staffing levels, training budgets, and maintenance investments when the evidence of their effectiveness is the absence of failure? When finance sees months of zero incidents, the instinctive conclusion is not "this team is exceptional" but "perhaps we can reduce costs here."

This problem is not theoretical. The Uptime Institute's 2024 Annual Outage Analysis reports that over 55% of significant data center outages are attributed to operational and human factors, not equipment failure [3]. The same report notes that facilities with robust operational programs experience 3-5x fewer incidents than those with minimal programs. Yet operational budgets consistently face pressure because their deliverable is nothingness.

This flagship entry establishes the foundation for the Operations Journal series: proactive engineering is not an absence of activity — it is a different kind of activity. One that can be documented, measured, quantified, and valued. The goal is to make the invisible visible through structured methodology, evidence-based metrics, and operational science.

We begin with theory — not as academic luxury, but because the language we use to describe operations determines what we measure, value, and fund. The Safety-I vs Safety-II distinction is the difference between an organization that reacts to failure and one that actively engineers success.

2 Safety-I vs Safety-II: A Theoretical Foundation

Erik Hollnagel's Safety-I and Safety-II (2014) fundamentally reframed how safety professionals think about organizational performance [1]. His distinction between two paradigms — now influential across aviation, healthcare, and critical infrastructure — provides the theoretical backbone for this journal's approach to data center operations.

2.1 Safety-I: The Traditional Paradigm

Safety-I represents the traditional approach to safety management. Under this paradigm, safety is defined as the absence of adverse outcomes. The operating assumption is that systems work correctly by default, and when they do not, something has gone wrong that must be identified, analyzed, and corrected. The primary activities of Safety-I are:

• Reactive investigation: When an incident occurs, determine the root cause
• Error elimination: Identify human errors and procedural failures, then create barriers to prevent recurrence
• Linear causality: Assume that outcomes have identifiable, traceable causes that can be isolated
• Compliance focus: Ensure that procedures are followed and deviations are flagged

In data center operations, Safety-I manifests as incident-response-driven management. The team investigates outages, writes root cause analyses (RCA), implements corrective actions, and measures success by the declining frequency of incidents. The KPI dashboard tracks failures, near-misses, and SLA breaches. When there are no incidents, there is nothing to report.

Safety-I is not wrong — it is incomplete. It explains why a chiller tripped, but not why 10,000 other hours passed without one. It attributes success to the absence of failure rather than to the presence of competent performance.

2.2 Safety-II: The Proactive Paradigm

Safety-II inverts the perspective. Rather than defining safety as the absence of adverse outcomes, Safety-II defines it as the presence of adaptive capacity — a concept we explore further in our analysis of resilience beyond traditional tier ratings. The operating assumption is that systems are inherently variable, and successful outcomes occur not because everything follows plan, but because people continuously adjust their performance to match conditions [1].

Under Safety-II, the primary activities shift fundamentally:

• Proactive monitoring: Understand how things go right, not just why they go wrong
• Performance variability: Recognize that human adaptation is a source of resilience, not just a source of error
• Non-linear thinking: Accept that outcomes emerge from complex interactions, not single causes
• Functional focus: Study everyday work to understand the conditions that enable success

2.3 Application to Data Center Operations

In a data center context, Safety-II thinking means asking fundamentally different questions. Instead of asking "Why did the HVAC system fail last Tuesday?" a Safety-II approach asks "What are the daily adjustments, monitoring activities, and preventive actions that ensure the HVAC system operates reliably for the other 8,759 hours of the year?" The first question yields an incident report. The second yields an understanding of operational competence.

James Reason's Managing the Risks of Organizational Accidents provides complementary framework through his Swiss Cheese Model [2]. Reason argues that catastrophic failures rarely result from a single error. Instead, they occur when multiple defensive layers simultaneously fail, like holes in Swiss cheese slices aligning. In proactive operations, the goal is not merely to add more cheese slices (more barriers) but to continuously monitor and maintain each layer's integrity.

Weick and Sutcliffe's work on High Reliability Organizations (HROs) extends this further [7]. They identify five hallmarks of organizations that operate reliably in high-risk environments: preoccupation with failure, reluctance to simplify, sensitivity to operations, commitment to resilience, and deference to expertise. These are not abstract principles. They are observable behaviors that can be cultivated, measured, and maintained through deliberate organizational design.

The implication for data center operations is clear: if we only measure what goes wrong, we will never understand what keeps things going right. The operational journal exists to capture both sides. It documents incidents, yes. But more importantly, it documents the proactive work that prevented incidents from ever occurring.

3 The Operational Journal Concept

The Operational Journal is not a maintenance log. It is not a shift handover report. It is a structured documentation methodology that bridges the gap between "as designed" and "as operated," capturing the real-world engineering decisions that determine whether a facility achieves its design intent or drifts toward failure.

In traditional operations, documentation focuses on two extremes: design documents (which describe how things should work) and incident reports (which describe how things failed). The vast operational territory between these extremes goes largely undocumented. This territory includes the daily adjustments, the subtle observations, the predictive interventions, and the preventive actions that constitute the actual work of keeping critical infrastructure running. The Operational Journal captures this territory.

3.1 The Gap Between Design and Reality

Every facility begins with a design basis. Engineers specify equipment ratings, redundancy topologies, environmental parameters, and failure modes. These specifications are validated during commissioning. Then the facility goes live, and reality diverges from design. Load patterns differ from projections. Equipment degrades at rates that vary from manufacturer specifications. Environmental conditions fluctuate beyond design envelopes. Staff rotate, bringing different experience levels and operational philosophies.

The gap between "as designed" and "as operated" is where operational engineering lives. EN 50600 [10] provides a standardized framework for data center design and operation, but the standard acknowledges that operational performance depends on more than design compliance. It depends on the quality of ongoing operational management, which includes monitoring, maintenance, change management, and continuous improvement.

3.2 What the Journal Captures

Each journal entry follows a consistent structure, designed to create a body of evidence that demonstrates operational competence over time:

• Context: The operational environment, load conditions, and relevant parameters at the time of observation
• Signal: The observation, data point, or trend that triggered attention. This may be a BMS alarm, a maintenance finding, a DCIM trend, or an operator's intuition based on experience
• Analysis: The engineering reasoning applied. What theories were considered? What data was examined? What risks were assessed?
• Action: The intervention taken, including any MoC processes, procedural changes, or coordination required
• Outcome: The verified result. Did the intervention achieve its intended effect? What evidence confirms this?
• Learning: What was learned, and how does this feed back into operating procedures, training, or design standards?

This structure serves multiple purposes. For the operations team, it creates institutional memory that survives staff turnover. For management, it provides evidence of proactive value. For auditors and regulators, it demonstrates compliance with ISO 55001 [6] asset management principles and ITIL [8] service management frameworks. For the broader engineering community, it contributes to the collective knowledge of how critical infrastructure actually operates.

3.3 The Journal as Evidence

Perhaps most critically, the Operational Journal creates a defensible record of proactive competence. When the question arises, "What does the operations team actually do when nothing goes wrong?" the journal provides the answer. It documents the hours of monitoring that detected a subtle trend. It records the preventive maintenance that replaced a component before failure. It captures the risk assessment that led to a procedural change. It shows the communication that aligned stakeholders around a preventive action.

In aggregate, the journal transforms invisible work into visible evidence. It shifts the organizational narrative from "nothing happened because the facility is well-designed" to "nothing happened because the operations team engineered that outcome through deliberate, documented, measurable action."

4 The Eight-Stage Proactive Framework

Proactive operations is not a single activity. It is a systematic cycle of eight interconnected stages, each contributing to the overall reliability of the facility. This framework draws from ISO 55001 asset management principles [6], ITIL 4 service management [8], and resilience engineering theory to create an integrated approach to operational excellence.

4.1 Environmental Scanning

Environmental scanning extends beyond the facility boundary to monitor conditions that could impact operations: weather (extreme heat, storms, flooding), utility grid stability (voltage, planned outages, frequency deviations), vendor advisories (firmware, recalls, known defects), and industry intelligence (peer facility outages, emerging failure modes, regulatory changes).

Effective scanning is active filtering and prioritization, not passive consumption. A heat advisory triggers pre-cooling protocols, generator pre-start, and customer notifications. A firmware vulnerability triggers patch assessment and change management. The Uptime Institute's 2023 resiliency survey found that facilities with formalized scanning programs experienced 40% fewer weather-related incidents [3].

4.2 Predictive Analysis

Predictive analysis transforms telemetry into actionable foresight. Modern data centers generate massive data volumes through BMS, DCIM, and CMMS platforms. The challenge is not data availability but interpretation — establishing baselines, defining thresholds, and distinguishing normal variation from early degradation.

A practical example: a chiller's coefficient of performance (COP) gradually declines over months. The decline is invisible in daily monitoring because each day's reading falls within the acceptable range. But when plotted as a trend, the degradation becomes apparent. Predictive analysis identifies this trend, projects when the COP will breach the minimum acceptable threshold, and triggers a maintenance intervention before the chiller's efficiency degrades to the point where it impacts cooling capacity.

CBM and PdM programs, as described in IEEE 3007.2 [12], rely on this analytical capability. They shift the maintenance paradigm from time-based schedules to condition-based triggers, optimizing both reliability and cost.

4.3 Preventive Execution

Preventive execution is the disciplined implementation of planned maintenance — scheduled PM activities, quarterly inspections, annual shutdowns. In a proactive framework, execution is not calendar-driven alone. It is informed by environmental scanning (external conditions), predictive analysis (degradation trends), and risk assessment (highest-value interventions).

The quality of preventive execution determines the integrity of Reason's Swiss Cheese defenses [2]. Each maintenance activity either strengthens or weakens a defensive layer. A properly executed UPS battery test confirms backup power reliability. A poorly executed test, or a skipped test, creates an unknown vulnerability. RCM methodology provides the analytical framework for determining which preventive activities deliver the greatest reliability benefit relative to their cost and risk.

4.4 Condition Monitoring

Condition monitoring provides real-time and periodic assessment of equipment health beyond standard parameters: vibration analysis (rotating equipment), infrared thermography (electrical connections), oil analysis (transformers, generators), partial discharge testing via UltraTEV and acoustic sensors (medium-voltage switchgear, cable terminations), and battery impedance testing (UPS systems).

Condition monitoring detects latent failures — conditions that exist but have not yet manifested as functional failures. A hot PDU busbar connection may carry current for months before thermal failure. IR thermography detects the elevated temperature early, enabling planned intervention rather than emergency response during peak load. Similarly, partial discharge activity in MV switchgear can be detected months before insulation breakdown through UltraTEV and acoustic emission sensors, preventing catastrophic arc flash events.

ASHRAE TC 9.9 [11] provides thermal monitoring guidelines that set the framework for environmental condition monitoring within data halls. These guidelines define allowable temperature and humidity envelopes, but the proactive operations team uses them as the starting point for more granular monitoring that identifies micro-trends within the allowable envelope.

4.5 Risk Assessment

Risk assessment integrates outputs from all preceding stages using FMEA, Fault Tree Analysis (FTA), and risk matrices to quantify likelihood, impact, and prioritize mitigation.

In a proactive framework, risk assessment is continuous — not a one-time design exercise. When scanning identifies an unusual condition, when analysis reveals degradation, or when monitoring detects a latent defect, the framework determines response urgency. This prevents both under-reaction (ignoring genuine signals) and over-reaction (emergency responses to planned-intervention conditions).

4.6 Stakeholder Communication

Stakeholder communication includes upward reporting (value demonstration, investment justification, risk posture), lateral coordination with vendors (maintenance alignment, technical intelligence sharing), and customer communication (operational transparency, planned activities).

Effective stakeholder communication also serves a Safety-II purpose: it creates the organizational context in which proactive work is recognized and valued. When management understands that the zero-incident quarter resulted from twelve documented preventive interventions rather than from good luck, the investment case for operations becomes self-evident.

4.7 Knowledge Management

Knowledge management preserves operational learning: SOPs, MOPs, EOPs, training materials, annotated equipment manuals, and a searchable lessons-learned database. ITIL 4 [8] provides structured approaches ensuring information is captured and accessible when needed.

The value becomes clear during staff transitions. When a senior engineer departs, their knowledge of equipment quirks, failure patterns, and workarounds leaves with them. A robust KM system preserves this institutional memory so successors benefit from accumulated experience rather than relearning through trial and error.

4.8 Continuous Improvement

Continuous improvement closes the loop — feeding learnings back into updated procedures, revised training, adjusted maintenance intervals, and evolved practices. Dekker's "just culture" [9] provides the foundation: an environment where learning is prioritized over blame, and teams are empowered to implement improvements without fear of punishment.

Continuous improvement is not aspirational. It is measurable. Each improvement can be tracked: how many procedures were updated this quarter? How many training modules were revised based on operational feedback? How many design standards were modified based on operational experience? These metrics transform the abstract concept of "getting better" into tangible evidence of organizational learning.

5 Proactive vs Reactive: Cost Quantification

The business case for proactive operations rests on a fundamental economic principle: the cost of prevention is almost always lower than the cost of remediation. This is not an article of faith. It is a quantifiable reality that can be demonstrated through rigorous cost analysis. The Uptime Institute's 2024 data estimates that the average cost of a significant data center outage now exceeds $250,000, with major outages at large facilities reaching into the millions [4].

5.1 Direct Cost Comparison

The following table presents a representative comparison between proactive and reactive costs across common data center scenarios. These figures are derived from industry benchmarks and operational experience across Tier III and Tier IV facilities.

Source: Publicly available industry data and published standards. For educational and research purposes only.

5.2 The MTBF / MTTR Economics

The economic relationship between proactive and reactive operations can be expressed through reliability metrics. Proactive operations systematically increase MTBF (by preventing failures) and decrease MTTR (by ensuring readiness when failures do occur). The compound effect on availability is dramatic.

The proactive scenario achieves a 16x reduction in annual downtime, not through any single dramatic intervention but through the cumulative effect of thousands of small operational decisions that extend MTBF and reduce MTTR. The Uptime Institute's staffing and training guidelines [5] directly correlate staffing adequacy and training quality with these reliability outcomes.

5.3 Hidden Costs of Reactive Culture

Beyond direct financial impacts, a reactive operational culture incurs hidden costs that are difficult to quantify but significant in impact:

Source: Publicly available industry data and published standards. For educational and research purposes only.

Including these hidden costs, the case for proactive operations becomes overwhelming. Reactive operations create a self-reinforcing cycle: each incident consumes resources meant for prevention, making the next incident more likely.

6 Case Context: 10MW Facility Operations

To ground this framework in reality, consider the operational context from which this journal originates: a 10MW critical data center facility operating at Tier III equivalency. Over a six-month period, the operations team documented twelve prevented incidents, each representing a potential service impact that was detected, assessed, and mitigated before any customer-visible effect occurred.

6.1 The Twelve Prevented Incidents

These twelve cases span electrical distribution, cooling, fire protection, and IT systems. Each was detected through proactive monitoring, analyzed using the eight-stage framework, and resolved before becoming an incident.

Source: Publicly available industry data and published standards. For educational and research purposes only.

6.2 The Aggregate Effect

The aggregate avoided cost across these twelve interventions ranges from $920,000 to $2,170,000. The total cost of the proactive activities that enabled their detection, including monitoring equipment, training, labor hours, and maintenance materials, was approximately $180,000 over the six-month period. This yields a return on prevention investment of approximately 5:1 to 12:1, depending on which end of the cost range materializes.

But the financial return understates the true value. Consider what would have happened if even one of the critical-rated items, say the MV switchgear bus section, had progressed to failure. A medium-voltage arc flash event in a data center can result in extended facility downtime (weeks, not hours), equipment damage requiring full replacement, potential personnel injury, regulatory investigation, and permanent customer loss. The prevented incident is not merely a cost saving. It is the preservation of the facility's operational continuity and its license to operate.

Each case will be detailed in subsequent journal entries using the Section 3 format. Together, they demonstrate that proactive operations produce documented, measurable outcomes — not merely the absence of failures.

7 The Culture Trap: Heroes vs Boring Competence

There is a deeply embedded cultural bias in organizations that rewards dramatic response over quiet prevention. The engineer who stays up all night restoring a failed system is celebrated as a hero. The engineer who quietly replaced a degrading component three weeks earlier, preventing the failure entirely, receives no recognition because there was no crisis to resolve. This is what we call the Culture Trap, and it is one of the most significant barriers to achieving operational maturity.

"The field of safety has, over the years, built up a belief that we should find and fix failures. But this belief may also have kept us from seeing what goes right, and understanding why." [1]

7.1 The Firefighter Hero Syndrome

In reactive organizations, the highest-status individuals are crisis responders — called at 2:00 AM, knowing every system from troubleshooting every failure, their dramatic saves becoming legends. These individuals are often extraordinarily skilled. The problem is systemic: the organization rewards conditions that produce crises rather than conditions that prevent them.

Sidney Dekker's analysis of organizational culture [9] identifies this as a systemic issue, not a character flaw. When organizations measure success by incident resolution speed (MTTR) rather than incident prevention (MTBF), they create incentive structures that value reactive competence over proactive discipline. The natural consequence is that resources flow toward response capability rather than prevention capability, which in turn increases the frequency of events requiring response.

7.2 The Boring Competence Paradox

Truly excellent operations are boring. The shifts are uneventful. The maintenance schedules are followed. The monitoring screens are green. There are no dramatic stories to tell, because the dramatic situations were prevented before they developed. This "boring competence" is the hallmark of mature operational organizations, but it is deeply unsatisfying to organizational narratives that seek drama, heroism, and visible achievement.

The challenge for operations leaders is to reframe this narrative. Boring competence must be recognized not as the absence of achievement but as the highest form of achievement. The data speaks clearly: the Uptime Institute's research shows that facilities with the lowest incident rates are those with the most disciplined, most documented, most process-driven operational cultures [3]. These are not exciting cultures. They are effective cultures.

7.3 Breaking the Trap

Breaking the Culture Trap requires deliberate organizational intervention across three dimensions:

• Metrics reform: Shift primary KPIs from reactive measures (incidents, MTTR, SLA breaches) to proactive measures (prevented incidents, PM compliance, training hours, knowledge base updates, maturity scores)
• Recognition redesign: Create formal recognition mechanisms for proactive achievements. Celebrate the engineer who detected the degrading bearing, not just the one who replaced it after failure
• Narrative transformation: Use the Operational Journal to tell the story of prevention. Make the invisible work visible through documentation, reporting, and stakeholder communication

Weick and Sutcliffe's concept of "preoccupation with failure" [7] provides the intellectual foundation. In High Reliability Organizations, the absence of failure is never assumed to be evidence of safety. Instead, it triggers deeper investigation: "What are we not seeing? What risks are accumulating beneath the surface of our green dashboards?" This mindset transforms boring competence from a liability (nothing to report) into an asset (everything to investigate).

8 Maturity Metrics: The Five-Level Model

Operational maturity is not binary. Organizations do not simply transition from "reactive" to "proactive." Instead, they progress through identifiable stages, each characterized by specific capabilities, metrics, and organizational behaviors. The five-level maturity model presented here draws from the Capability Maturity Model Integration (CMMI) framework, adapted for data center operations using principles from ISO 55001 [6], ITIL 4 [8], and the Uptime Institute's operational assessment criteria [3].

Source: Publicly available industry data and published standards. For educational and research purposes only.

8.1 Assessment Dimensions

The maturity assessment evaluates eight dimensions of operational capability, each weighted according to its impact on overall reliability. These dimensions are not independent; they interact in ways that can either amplify or undermine the overall maturity level. An organization with excellent monitoring but poor knowledge management, for example, may detect problems it cannot effectively resolve because the procedures and training are inadequate.

• Documentation (10%): Quality, currency, and accessibility of operating procedures, equipment records, and as-built documentation
• Training (15%): Comprehensiveness of training programs, including initial qualification, ongoing proficiency, and scenario-based exercises
• Change Management (15%): Rigor of MoC processes, including risk assessment, stakeholder notification, rollback planning, and post-change verification
• Monitoring (15%): Coverage and sophistication of monitoring systems, including BMS, DCIM, alarm management, and trend analysis capability
• Maintenance (15%): Integration of preventive, predictive, and condition-based maintenance strategies, PM compliance rates, and spares management
• Emergency Readiness (10%): Quality of emergency procedures, drill frequency, response team competency, and communication protocols
• Continuous Improvement (10%): Feedback loop effectiveness, lessons learned integration, procedure update frequency, and innovation adoption
• Leadership (10%): Management commitment to operational excellence, resource allocation adequacy, safety culture promotion, and strategic vision

8.2 Industry Benchmarks

Based on industry data from the Uptime Institute and operational assessments across multiple facilities, the following benchmarks provide context for maturity scoring:

• Tier I facilities: Average composite score of 25 (Preventive level). Basic maintenance programs, limited documentation, reactive incident management
• Tier II facilities: Average composite score of 45 (Predictive level). Structured maintenance, developing documentation, some trend analysis
• Tier III facilities: Average composite score of 65 (Proactive level). Comprehensive maintenance, formal change management, condition monitoring deployed
• Tier IV facilities: Average composite score of 82 (Generative level). Integrated operations, advanced analytics, continuous improvement embedded in culture

These benchmarks are approximations based on aggregate data and should be used directionally rather than prescriptively. Individual facility performance varies significantly based on organizational factors, staffing quality, and management commitment.

9 Calculator: Operational Maturity Assessment

Use the interactive calculator below to assess your facility's operational maturity across the eight dimensions. Rate each dimension on a 1-5 scale, where 1 represents ad-hoc practices and 5 represents fully optimized, industry-leading performance. The calculator will compute your composite maturity score, identify priority improvement areas, and compare your results against industry benchmarks.

10 Conclusion: Making Invisibility Visible

This article began with a paradox: in critical infrastructure, the better the engineering, the less visible the outcome. We have argued that this invisibility is not an inherent property of operations but a failure of measurement, documentation, and organizational narrative. The work of proactive engineering is real, measurable, and valuable. It simply requires different tools to capture and communicate its impact.

The theoretical foundation provided by Hollnagel's Safety-II framework [1] gives us the language to describe operational success in positive terms rather than merely as the absence of failure. Reason's Swiss Cheese Model [2] gives us the visual metaphor for understanding how proactive activities maintain defensive layers. Weick and Sutcliffe's HRO principles [7] give us the organizational design criteria for building cultures that sustain proactive performance.

The eight-stage framework translates theory into practice. Environmental scanning, predictive analysis, preventive execution, condition monitoring, risk assessment, stakeholder communication, knowledge management, and continuous improvement are not abstract concepts. They are concrete activities that can be scheduled, resourced, executed, measured, and reported. The Operational Journal captures these activities in a structured format that creates evidence of operational competence.

The economic case is compelling. Our analysis demonstrates that proactive operations deliver a 4:1 to 10:1 return on prevention investment, with the potential for dramatically higher returns when critical failures are prevented. The twelve documented cases from a single 10MW facility over six months represent over $1.2 million in avoided costs, achieved through approximately $180,000 in proactive activities.

"When nothing happens, it is not because nothing was done. It is because everything was done. The absence of failure is the presence of engineering."

The culture trap, the organizational bias toward rewarding reactive heroism over proactive discipline, is perhaps the most challenging obstacle. But it is not insurmountable. By shifting metrics, redesigning recognition systems, and transforming the organizational narrative through structured documentation, operations leaders can create environments where boring competence is celebrated as the highest form of professional achievement.

The five-level maturity model provides a roadmap for progressive improvement. No organization becomes generative overnight. But with deliberate effort, structured assessment, and sustained commitment, any operations team can advance from reactive firefighting to proactive engineering excellence. The interactive calculator in Section 9 provides a starting point for self-assessment and a framework for measuring progress over time.

This article is the foundation. Every subsequent entry in the Operations Journal will build upon these frameworks, documenting real operational cases that demonstrate how theory translates into practice. Each entry will follow the structured format described in Section 3: context, signal, analysis, action, outcome, and learning. Together, they will create a body of evidence that makes the invisible visible.

Because when nothing happens in a data center, it is not because the facility runs itself. It is because engineers are working. And that work deserves to be seen.