Proof in the Power: Validating Building Resilience Through Practical Tests

Why paper plans fail when the power actually goes out

This episode opens with a vivid failure that captures the core problem with resilience programs that exist only on paper. A building was switched to backup power, but the results were immediate and ugly: emergency lights stayed dark, elevators stalled between floors, card readers failed, and the leasing desk was overwhelmed with calls. It took 40 minutes before anyone fully understood what had happened.

That story sets up the main lesson of the conversation: a generator starting is not the same thing as a building being resilient. In this case, the generator itself was not the only issue. A transfer path had been altered, emergency lighting circuits were out of scope, and the systems people assumed were protected were not actually working together the way the documentation suggested.

The episode argues that resilience should be proven with observable, timestamped, end-to-end evidence rather than assumptions, anecdotes, or maintenance notes.

What “proving resilience” actually means

One of the most useful parts of the discussion is the plain-language definition of resilience validation. The goal is not to create a thicker binder or another checklist that says a breaker moved. The goal is to collect evidence that the full path from source to load worked as intended.

That means teams should be looking for artifacts such as:

• Timestamped logs
• Dashboard captures
• Photos taken during the test
• Signed checklists
• Evidence showing the complete system path worked end to end

This matters because tenants do not experience resilience in diagrams. They experience it in lights, access control, elevators, phones, cameras, and the other systems they depend on every day.

Why buildings drift out of sync over time

The conversation highlights a recurring pattern in commercial properties and mixed-use environments: the map and the territory drift apart. Drawings and runbooks may say one thing while the actual wiring, panel routing, or service path says something else.

That drift happens for practical reasons:

• Panels are rerouted during renovations
• Runbooks are not updated after changes
• Maintenance schedules shift
• Legacy circuits remain in place
• Ownership of the full outcome is fragmented

A strong example comes from a fiber failover test on a mixed-use campus. The primary fiber was pulled to validate failover. From a routing perspective, the network appeared healthy because BGP converged. But important services still failed. Phones stayed down, and the security center lost camera feeds. The reason was simple and dangerous: some services were still hardwired to a legacy circuit that never switched, with static routes and a mispatched panel hiding the problem.

The lesson is clear. A console can say the network is fine while tenants are still living through an outage.

Governance matters as much as technology

Another major theme in the episode is that resilience failures are often governance failures. If nobody owns the end-to-end outcome, testing becomes a checkbox exercise instead of a proof exercise. Handoffs happen without evidence. Assumptions pass from one vendor or team to another. Then the first real audit of reality is a live outage.

This is especially important in buildings where facilities, IT, telecom, security, and outside vendors all touch part of the same critical path. The conversation makes the case that resilience testing needs clear ownership, documented acceptance criteria, and follow-through when a weakness is exposed.

Tabletops versus live tests

The episode does not frame tabletop exercises and live testing as an either-or decision. Instead, it argues that both are necessary because they answer different questions.

Tabletops are useful for:

• Process validation
• Communication planning
• Dependency mapping
• Coordinating people and vendors

Live tests are necessary for:

• Verifying physical behavior
• Confirming transfer paths
• Watching UPS performance under load
• Testing carrier routing and actual service continuity
• Finding hidden dependencies that documents miss

The practical pushback in the episode is strong: tabletop-only programs can create process comfort without creating physical confidence. That is false assurance, and the speakers encourage teams to use tabletops to plan live tests, then use live tests to validate reality.

How to reduce risk when testing live

For teams worried about disruption, the guidance here is pragmatic rather than reckless. The recommendation is not to run giant all-building exercises without guardrails. Instead, the speakers advocate for small, targeted live tests that reduce surprise while exposing real issues.

Risk can be managed by:

• Scheduling during low-impact windows
• Pre-staging rollback plans
• Notifying tenants in advance
• Limiting scope to a single critical path
• Coordinating any required safety permits

The broader point is that discovering a weakness during a controlled test is far cheaper than discovering it during a real event.

A practical power-side failure mode

The discussion also walks through a power-related example involving generators and UPS behavior. At one site, the UPS had been sized for immediate IT loads, while the generator had been sized and tested under light conditions. During a real outage scenario, the generator took longer to stabilize than expected. UPS batteries dipped earlier than planned, and non-IT systems such as strobe lights and remote access panels dropped.

The fixes were not mysterious, but they did require clarity on business impact. Options included:

• Increasing UPS runtime
• Moving non-critical loads off the UPS
• Retiming generator load transfer

The conversation treats this as a business decision as much as a technical one. If teams know what can fail, for how long, and with what tenant impact, they can choose between capital investment and operational workarounds with more confidence.

The four-step checklist listeners can use this week

One of the strongest takeaways in the episode is a short checklist designed for real-world use during a low-impact maintenance window:

• Confirm ownership and sign-off from facilities and IT
• Pick one critical end-to-end path and define a one-sentence success criterion with a time limit
• Capture evidence with timestamps, logs, photos, and a responsible party signature
• Run the rollback and hold a 15-minute debrief that records actions and next steps

The recommendation is to repeat this quarterly for critical paths. That cadence helps teams keep documentation aligned with reality and catch drift before it becomes a crisis.

How to avoid checkbox testing

The conversation is especially sharp on what should happen after a test. Reports should not be filed and forgotten. Test findings should be treated as defects that need triage, ownership, and either budget or mitigation. If a gap is exposed, it should be tracked through capital planning, vendor SLA management, or operational changes until someone closes the loop.

Without a single owner, evidence ends up on a shared drive while the risk remains in the building.

Three actions to take next week

If your team wants to start proving resilience right away, this episode offers a clear first move:

• Run a targeted live test of one critical path during a low-impact window and capture timestamps and logs
• Hold a short tabletop with facilities, IT, and primary vendors to map hidden dependencies
• Create or update a one-page checklist with acceptance criteria and assign an owner

The episode closes with a simple standard: small, frequent, evidence-based tests beat rare, grand exercises. That approach creates useful documentation, better capital planning, and faster action when a real incident hits.

The notes also mention a one-page resilience test checklist from GDS Technology available in the episode notes and on their resources page for teams that want a practical starting point.

Proof in the Power: Why resilience has to be tested, not assumed

Many buildings have backup power plans, failover diagrams, maintenance records, and operating procedures that look solid on paper. The problem is that paper does not keep tenants moving during an outage. Working systems do.

In this episode of Built Wired and Secured, the conversation focuses on a hard truth that property owners, facilities teams, and IT leaders often learn the expensive way: resilience is not something you claim. It is something you prove.

The opening example makes that point immediately. A building was switched to backup power, but the outcome was chaos. Emergency lights stayed dark. Elevators stalled. Card readers failed. The leasing desk was flooded with calls. It took 40 minutes before anyone understood what had actually happened.

That is the gap this episode addresses. Not whether a generator starts. Not whether a network route appears healthy in a console. But whether the full operational path people depend on continues to work under stress.

The real issue is usually not one device

One of the most practical lessons in the episode is that resilience failures are rarely caused by a single obvious component. In the opening story, the generator was not the whole problem. A transfer path had been altered, emergency lighting circuits were out of scope, and the protected environment people assumed they had was not the environment they actually had.

That distinction matters because organizations often test isolated pieces of infrastructure instead of testing outcomes. A generator can start successfully while critical tenant-facing systems still fail. A network can converge from a routing perspective while phones, cameras, or other services remain down. A UPS can support core IT loads while adjacent operational systems quietly fall away sooner than expected.

In other words, infrastructure components can pass their own local checks while the building still fails the business test.

Observable, timestamped, end-to-end

The episode offers a simple standard for what good resilience validation looks like: it should be observable, timestamped, and end to end.

That means teams need evidence that the path worked from source to load. Not a vague note. Not a memory of how the test “usually goes.” Actual proof.

Useful evidence includes:

• System logs with timestamps
• Dashboard screenshots or captures
• Photos taken during the event
• Signed checklists
• Documented acceptance criteria

This is a strong operational discipline because it changes the standard from “we believe it worked” to “we can show what happened.” That shift is important for day-to-day governance, but it is even more important during handoffs, post-incident reviews, and capital planning discussions.

If a building team wants approval for load segregation, longer UPS runtime, panel corrections, or carrier cleanup, evidence makes the case. Anecdotes do not.

Why systems drift apart over time

The conversation also explains why so many building environments become misaligned even when nobody is being careless. Over time, the map and the territory diverge.

Renovations happen. Panels are rerouted. Legacy circuits remain in place. Maintenance plans change. Documentation lags. Runbooks are not updated after small field changes. Different vendors own different slices of the environment. Eventually, the designed state and the actual state are no longer the same.

The episode gives a strong network example from a mixed-use campus. During a failover test, the primary fiber was pulled. BGP converged, so the network looked healthy from a routing perspective. But phones stayed down, and the security center lost camera feeds. The root cause was not a dramatic software failure. It was hidden dependency: some services were still tied to a legacy circuit, along with static routes and a mispatched panel.

That is the kind of problem a tabletop may predict in theory, but only a live test will expose with certainty.

Resilience is also a governance problem

A useful theme throughout the episode is that resilience is not just a technical discipline. It is also a governance and ownership discipline.

When no one owns the end-to-end outcome, testing becomes fragmented. Facilities may believe power is covered. IT may believe failover is covered. Telecom vendors may confirm their segment is functioning. Security teams may assume access systems are included. But the tenant does not experience these systems in pieces. The tenant experiences one environment.

That is why the conversation pushes back against checkbox testing. A handoff without evidence is described as a blind bet, and that is exactly right. During an actual outage, assumptions between teams become operational delays. Those delays show up as stalled recovery, confused communications, and avoidable service impact.

Clear ownership changes that. So do acceptance criteria. So does assigning one person or one accountable team to close the loop when a weakness is found.

Why tabletops are not enough

The episode does not dismiss tabletop exercises. In fact, it gives them a useful role. Tabletop discussions are valuable for process, communication planning, dependency mapping, and coordination across internal teams and outside vendors.

But the episode is equally clear about their limitation: tabletops cannot verify physical behavior.

You cannot tabletop whether a mispatched panel exists. You cannot tabletop whether a UPS battery dips earlier than expected under real load. You cannot tabletop whether a legacy service path still depends on a circuit that does not switch. You have to test those things.

The better model is to combine both approaches. Use tabletop exercises to design the live test, identify likely dependency failures, plan safety and rollback steps, and align stakeholders. Then run a small targeted live test to validate reality.

That sequencing is practical, not extreme. It reduces surprise without replacing proof.

Live testing does not have to be reckless

One reason teams avoid live testing is fear of disruption. That concern is valid. Tenants can be affected. Critical services can be impacted. Nobody wants to create an incident while trying to prevent one.

The episode addresses that concern with a measured approach. Instead of broad, high-drama exercises, it recommends small, targeted tests during low-impact windows. That means limiting scope to one critical path, notifying tenants in advance, coordinating permits and safety requirements, and pre-staging rollback plans.

This is a smart operational posture because it accepts the reality of risk while recognizing a larger truth: the most dangerous test is the one you never ran before a real outage.

A practical example on the power side

The power-side example in the episode is especially useful for facilities and IT leaders who assume generator and UPS design automatically translate into resilience. At one site, the UPS was sized for immediate IT loads, and the generator had been sized and tested under light conditions. During a real outage scenario, the generator took longer to stabilize than expected. UPS batteries dropped earlier than planned, and non-IT systems such as strobe lights and remote access panels failed.

That outcome created a business decision, not just a technical one. The possible responses included:

• Increase UPS runtime
• Move non-critical loads off the UPS
• Retiming generator load transfer

The right choice depends on business impact. What fails? For how long? What is the tenant consequence? What level of degradation is acceptable? The episode makes the point that tests provide the data needed to answer those questions with confidence rather than opinion.

A four-step resilience test you can run this quarter

The conversation offers a practical checklist that listeners can use without building a major program first:

• Confirm ownership and sign-off from facilities and IT
• Choose one critical end-to-end path and define a one-sentence success criterion with a time limit
• Capture evidence with timestamps, logs, photos, and a responsible party signature
• Run the rollback and hold a 15-minute debrief to record actions and next steps

That is intentionally simple. It is built for a low-impact maintenance window and designed to create momentum. The recommendation to repeat this quarterly for critical paths is important because resilience drifts unless it is checked regularly.

What to do with the results

One of the best operational insights in the episode is that test results should be treated as defects. If a test reveals a weakness, it needs triage, ownership, and either funding or mitigation.

That could mean:

• Capital planning for corrective work
• Operational sequencing changes
• Vendor SLA follow-up
• Scope corrections in future maintenance
• Runbook and documentation updates

If the output of testing is just a report stored on a shared drive, the organization has not improved resilience. It has only documented risk more neatly.

Three actions to take next week

If your team needs a starting point, this episode makes the first move easy. Run a targeted live test of one critical path during a low-impact window and capture timestamps and logs. Hold a short tabletop with facilities, IT, and primary vendors to map hidden dependencies. Then update or create a one-page checklist with acceptance criteria and assign an owner to close the loop.

That is the practical value of this conversation. It turns resilience from a broad aspiration into a repeatable operating habit.

If this topic is relevant to your property or portfolio, listen to the full episode and use the one-page resilience test checklist referenced in the episode notes. The core takeaway is simple: small, frequent, evidence-based tests create far more confidence than rare, oversized exercises. When the next outage comes, proof will matter more than hope.