GDS Technology — Built, Wired and Secured podcast banner
Watch on YouTube →
Baseline Signals: Practical Telemetry for Smarter Building Operations
Episodes General
Episode 72

Baseline Signals: Practical Telemetry for Smarter Building Operations

July 8, 2026
Key takeaways
  • A small set of baseline signals can reveal system drift before tenants report a problem.
  • Power draw, valve or actuator travel time, door or damper states, and BAS availability checks provide strong early coverage.
  • Five- to fifteen-minute trends work for most assets, while short high-resolution buffers help with critical incident forensics.
  • Telemetry only works when facilities and IT define ownership, alert routing, and false-positive handling in advance.
  • Open formats, low-code dashboards, and a 30-day validation pilot help prove value before long-term platform commitments.

Show Notes

Why Baseline Telemetry Matters

In this episode of Built, Wired & Secured, Alex Morgan sits down with Michael Harrington and James Rogers to talk about a practical question that affects commercial building operations every day: how do you catch system drift before tenants start calling? The discussion opens with a familiar scenario. A lobby feels warm on a midweek morning, staff assume it is a fluke, and only days later do multiple suites lose conditioned air. By then, a stuck actuator and a failing pump have already turned a manageable issue into lost productivity, urgent repairs, and avoidable disruption.

The core message of the episode is simple: teams do not need exotic analytics or oversized budgets to improve early warning. What they need are a few repeatable, reliable signals that show when a system is drifting away from normal behavior. Instead of waiting for visible failure or customer pain, operators can track small changes that point to trouble early enough to intervene.

Small Signals Beat Big Surprises

Michael and James emphasize that useful telemetry starts with discipline, not complexity. A measurement only matters if a team actually checks it, understands what normal looks like, and documents what changed. One of the clearest examples from the conversation is actuator or valve travel time. If a valve used to close in two seconds and now takes eight, that is not just an interesting statistic. It is a practical warning sign that something is degrading.

That kind of change matters because it shifts maintenance from emergency response to planned correction. Catch it early, and a team may avoid rushed parts orders, weekend labor, and tenant complaints. Miss it, and the same issue can escalate into downtime, backlog, and a string of temporary fixes that never fully address root cause.

  • Small shifts in performance often appear before full failure.
  • Reliable signals are more valuable than large volumes of unreviewed data.
  • Disciplined checks and documented fixes are what turn telemetry into operational value.

What Shows Up First in the Real Cost of Failure

The conversation ties telemetry directly to business outcomes. Michael points out that tenant complaints are only the visible part of the problem. Below the surface, building teams absorb overtime, expedited replacement parts, undocumented temporary workarounds, and a growing maintenance backlog. These hidden costs compound quickly.

That is why the group keeps returning to one central question: what breaks if this goes down? It is a practical way to prioritize where telemetry should begin. Rather than trying to instrument everything, teams should start with the assets whose failure creates the most tenant impact or operational disruption.

The Minimal Signals That Matter

One of the most useful parts of the episode is the discussion of what to monitor first. James lays out a minimal set of baseline signals that can cover both mechanical performance and connectivity without creating overwhelming data volume.

  • Power draw on critical pumps and fans
  • Actuator or valve travel time
  • Contact states for key doors or dampers
  • A synthetic BAS availability check

Together, these signals provide visibility into whether critical equipment is operating, whether control components are slowing down, whether physical states are where they should be, and whether the building automation front end is reachable. This is a practical, owner-friendly approach because it focuses on signals that are interpretable and actionable.

Sampling Cadence Without Drowning in Noise

The episode also tackles a common implementation challenge: how often should teams sample data? Too slow, and important drift can be missed. Too fast, and teams create noise, storage costs, and alert fatigue. The recommendation offered here is balanced. For many assets, five- to fifteen-minute aggregated cadence is enough to reveal drift without overwhelming staff or systems.

At the same time, the speakers acknowledge that some high-risk assets may justify finer telemetry. Their compromise is especially practical: keep five-minute rolling trends as the default, then maintain a short high-resolution buffer for critical assets. For example, ten minutes of one-second or five-second sampling can provide valuable forensic context around an incident without forcing owners into permanent high-cost storage.

Ownership Is as Important as Instrumentation

Another strong theme in the episode is that telemetry fails when ownership is vague. If facilities look at mechanical trends and IT looks at network checks, nobody may end up watching the intersection where meaningful issues appear. That gap creates confusion, delayed response, and blame when an alert is triggered.

The recommendation is straightforward: define ownership before collecting data. Facilities should interpret mechanical signals and help set thresholds. IT should manage transport, storage, and authentication. Both groups should work from a shared playbook that explains who gets paged, who covers after hours, and how false positives are recorded and reviewed.

  • Assign alert ownership up front.
  • Use one shared escalation playbook.
  • Document how teams validate and classify alerts.

How to Run a Pilot This Quarter

For listeners who want a starting point, the episode offers a concrete pilot that can be run in a single quarter. The suggested pilot includes three signals: power draw on a critical pump, actuator travel time on a representative valve, and a synthetic HTTP fetch of the BAS front end. The setup uses low-cost power clamps, travel-time sensors, an edge aggregator, rolling hourly averages, and a short high-resolution buffer.

The team should run the pilot for 30 days, logging each alert as either actionable or noise. That step matters because the goal is not simply to collect data. The goal is to prove operational value. Pairing the pilot with a one-page playbook keeps validation consistent and gives teams a structure for learning what thresholds work in the real environment.

Retention, Governance, and Practical Scale

The speakers also push back on the impulse to keep everything forever. Their advice is to store aggregated trends for longer periods while keeping high-resolution data only around incidents. Governance should be defined early, especially if any data could intersect with tenant-related information. Restrict access, align retention with maintenance cycles, and document every threshold change and tuning decision.

That documentation becomes especially valuable during review. It helps teams understand why a threshold was changed, whether the adjustment improved signal quality, and what lessons should shape broader rollout.

Three Actions to Take This Week

The episode closes with practical next steps:

  • Pick three signals tied directly to tenant impact.
  • Assign ownership and write a one-page escalation playbook.
  • Run a 30-day validation and label every alert actionable or noise.

The final takeaway is clear: effective telemetry is not about collecting everything. It is about choosing a small set of meaningful signals, validating them with discipline, and scaling only after the operational value is proven. For building operators, facilities teams, and IT leaders, that approach can reduce surprise outages, improve response, and create a more reliable environment without overcomplicating the stack.

Deeper dive

Baseline Telemetry Is the Difference Between Drift and Disruption

Commercial buildings rarely fail all at once. More often, they drift. A pump starts drawing power differently. A valve takes longer to move. A front end stays technically available, but responsiveness changes. A door or damper stops behaving consistently. None of those shifts look dramatic on their own, which is exactly why they are easy to miss until tenants feel the outcome.

In this episode of Built, Wired & Secured, Alex Morgan talks with Michael Harrington and James Rogers about how baseline telemetry helps teams catch those subtle signals earlier. The conversation stays grounded in practical operations, not flashy analytics. The focus is on the smallest useful set of signals a team can collect this quarter to reduce surprise outages and make smarter building decisions without committing to a costly full-stack platform first.

Start With the Problem Tenants Feel Last, Not First

The episode opens with a scenario many building teams will recognize. A lobby feels warm one morning. Staff assume it is temporary. A few days later, multiple suites lose conditioned air. By then, the issue has already moved well beyond a minor annoyance. A stuck actuator and a failing pump have cost time, productivity, and money.

That progression matters because tenant complaints often arrive late in the failure cycle. By the time occupants notice and report the issue, operators are no longer dealing with early drift. They are dealing with disruption. The business case for telemetry is not simply better monitoring. It is earlier intervention, less downtime, and fewer emergency decisions under pressure.

That is why one of the most useful questions raised in the episode is also one of the simplest: what breaks if this goes down? For owners, property managers, facilities teams, and IT leaders, that question creates a rational starting point. It keeps telemetry tied to operational impact instead of turning into a broad but unfocused data project.

You Do Not Need More Data. You Need Better Signals.

One of the strongest themes in the conversation is that useful telemetry does not begin with large data volume. It begins with a small number of repeatable signals that the team can trust. Michael and James make the point clearly: reliability comes from disciplined maintenance, a few measurements that are actually checked, and documented follow-through when those measurements change.

The example of valve travel time is especially effective. If a valve used to close in two seconds and now takes eight, that change might look minor in a spreadsheet. Operationally, it is a warning. It suggests wear, drag, or control degradation that may soon become a bigger problem. If the team catches it early, they can schedule work deliberately. If they ignore it, the same issue may surface later as tenant discomfort, emergency labor, rushed part ordering, and a maintenance backlog that grows faster than it clears.

That is a useful lesson for smarter building operations in general. A baseline is not just a record of where a system has been. It is the reference point that lets a team recognize when normal is no longer normal.

The Minimal Signal Set That Covers More Than You Think

The episode outlines a practical first-pass telemetry set that many commercial properties can implement without major cost:

  • Power draw on critical pumps and fans
  • Actuator or valve travel time
  • Contact states for key doors or dampers
  • Synthetic BAS availability checks

This is not an attempt to instrument every possible condition. It is an intentional effort to cover the essentials: whether core equipment is behaving normally, whether control devices are slowing down, whether physical states line up with expectations, and whether the building automation system is reachable.

That owner-friendly approach matters. Telemetry becomes useful when people can connect a signal to a likely action. If the power draw on a critical pump starts trending abnormally, a team can investigate before the pump fails outright. If valve travel time is creeping up, they can inspect a control component before it creates a comfort complaint. If a synthetic BAS check fails, IT and facilities have a shared starting point instead of a finger-pointing exercise.

The Cadence Question: Fast Enough to Be Useful, Slow Enough to Be Sustainable

Sampling frequency is where many telemetry efforts either overspend or underdeliver. If teams sample too slowly, they miss drift. If they sample too aggressively across the board, they create noise, retention costs, and alert fatigue that their staffing model cannot support.

The recommendation in the episode is practical. For many assets, five- to fifteen-minute aggregated sampling is enough to reveal meaningful trends. It provides visibility without forcing teams to store, review, and react to unnecessary detail. But the discussion does not stop there. The speakers acknowledge that some assets are more critical than others and may justify finer telemetry when incident response capability exists.

The compromise they describe is especially smart: default to five-minute rolling trends, then add a short high-resolution buffer for higher-risk assets. A ten-minute buffer at one-second or five-second sampling can provide the forensic context needed around an incident without driving permanent storage and dashboard complexity across the whole environment.

In other words, owners do not need to choose between blind spots and runaway data costs. They can design for both operational usefulness and budget discipline.

Telemetry Fails When Ownership Is Fuzzy

Technology alone does not fix operational blind spots. One of the most important points in the episode is that telemetry breaks down when teams do not define ownership before rollout. Facilities may own mechanical interpretation. IT may own transport, storage, and authentication. But if no one owns the intersection, alerts stall and accountability disappears.

That is why the conversation emphasizes a shared playbook. Teams need to know who gets paged, who validates the signal, who covers weekends, and how false positives are logged. This is not administrative overhead. It is the difference between collecting data and using it.

For commercial real estate operators, that has a broader implication. The building is no longer just a mechanical environment or just a networked environment. It is both. Smarter operations depend on coordination between those disciplines, especially when the signals that matter cross traditional boundaries.

Why Open Formats and Low-Code Dashboards Matter Early

The episode also offers a smart warning about vendor lock-in. Many teams are pitched full-stack analytics before they have even proven that basic telemetry will improve operations. That sequence is backwards. Before signing long contracts or adopting proprietary analytics layers, owners should prove that telemetry creates measurable value in their environment.

The recommendation is to use vendor-agnostic sensors, open formats, and low-code dashboards for the pilot. That gives the team flexibility while they learn which signals matter, which thresholds are useful, and which alerts consistently drive action. It also reduces the risk of overspending on tools before the organization is operationally ready to use them well.

The example shared in the episode is telling: one campus reduced emergency calls by 40 percent in the first quarter after a three-signal pilot. The lesson is not that every property will match that number. It is that modest telemetry can produce meaningful operational gains when the pilot is focused and the validation is disciplined.

A Pilot You Can Actually Run This Quarter

For teams that want an immediate next step, the episode provides a straightforward pilot plan. Choose three signals: power draw on a critical pump, actuator travel time on a representative valve, and a synthetic HTTP fetch of the BAS front end. Use low-cost sensors, route the data to an edge aggregator, store rolling hourly averages, preserve a short high-resolution buffer, and build a simple dashboard.

Then run the pilot for 30 days and do one thing many teams skip: classify every alert. Was it actionable, or was it noise? That single discipline helps organizations tune thresholds, reduce fatigue, and prove whether the telemetry is helping.

Pair the pilot with a one-page escalation playbook that states who investigates, what to capture during validation, and how false positives are tagged. Start with conservative thresholds, then tighten them as the team learns. That measured approach respects both staffing reality and change management.

Retention and Governance Need a Practical Policy

Another useful takeaway from the episode is that not all telemetry deserves long-term retention. Aggregated trends are valuable for seasonal comparison, maintenance review, and planning. High-resolution data is most useful around incidents. Keeping everything forever increases cost and governance burden without guaranteeing better decisions.

The smarter approach is to define retention up front. Limit access appropriately. Anonymize anything that could touch tenant-related information. Align retention windows with maintenance and operational review cycles. And document threshold changes with the reason behind them. That creates an audit trail for improvement instead of a pile of unexplained configuration changes.

What This Means for Building Teams Right Now

The biggest strength of this episode is its realism. It does not tell building teams to chase perfect visibility. It tells them to start with three to five signals tied to tenant impact, define ownership clearly, validate for 30 days, and scale only when the value is clear.

That is exactly the kind of approach that turns telemetry into a business asset. Fewer surprise outages. Fewer emergency calls. Better coordination between facilities and IT. Better evidence for maintenance decisions. Better justification for future investment.

If you manage building systems, support commercial properties, or advise owners on operational resilience, this episode is a reminder that smarter building operations do not start with complexity. They start with a baseline, a handful of meaningful signals, and the discipline to act on what those signals reveal.

If you want the full discussion, listen to the episode and use it as a blueprint for the first telemetry pilot your team can actually execute this quarter.