Introducing Custra: the commercial real estate intelligence hub

The problem we set out to solve

Walk into any large commercial building and you will find a BMS, a CMMS, fire panels, elevator controllers, an IoT gateway from the last capital project, and a facilities team managing all of it by reconciling alerts manually. The alerts are siloed. The response is reactive. The damage report is written after the leak is visible. The tenant complaint is filed before anyone on the facilities team knows there’s a problem.

This is not a technology failure. Every point system works. The BMS knows the AHU is behaving oddly. The moisture sensor registered an anomaly three days ago. The CMMS has an open ticket from last quarter that no one closed. The systems work. The coordination between them doesn’t.

The insight that drives Custra’s design is that the problem is architectural, not operational. No amount of better dashboards or faster alert routing fixes it, because the failure is happening one layer up: there is no system that maintains a unified operating state for the whole building, correlates signals across systems, detects fault onset before the alarm fires, and routes one correct response. That is the hub that’s missing. Custra is the hub.

What Custra does — and doesn’t do

Custra reads every building system. It maintains a live operating state for each one — a continuously updated model of what baseline looks like, what the current trajectory is, and how far the current reading has departed from it. When a trajectory crosses the departure threshold, Custra names the fault, correlates it with any co-occurring signals in coupled systems, and opens a ServiceCase — a single governed object that tracks the work from first signal to verified closure.

The ServiceCase lifecycle has eight stages: detect, triage, authorize, dispatch, repair, verify, bill, close. Custra handles the bureaucracy. Your team handles the building.

What Custra does not do: it never touches a thermostat, valve, panel, or control system. It never actuates. This is not a phase-one constraint to be lifted later; it is an architectural commitment. Every IoT platform that starts as “insight-only” eventually adds actuators because actuation is where the next dollar looks like it lives. We disagree. The coordination value is permanent; the actuator temptation is a governance risk that we don’t intend to introduce. Custra observes, predicts, and coordinates. That is the boundary, and it holds.

The causal graph

Buildings are physically coupled in ways that generate a specific failure pattern: one system faults, and several dependent systems deviate in consequence. An HVAC unit that begins to overheat elevates the electrical current draw on the circuit, raises CO⊂2; in the served zones as airflow degrades, and increases energy consumption across the cooling plant. Five signals, one root cause.

Without a causal model, those five signals produce five work orders to five trades. With a causal model, they produce one work order to the HVAC contractor — and the other four are suppressed as symptoms, reopened automatically if the root cause dispatch doesn’t clear them.

The coupling graph is how we model the causal structure. It is a directed graph where each edge represents a causal relationship between two building systems — not a correlation, but a cause. The graph is learned from the fleet, not authored by hand.

Three signals go into the graph learner: co-occurrence (which systems co-fault statistically above independence), temporal precedence (which system faults first), and interventional confirmation (which co-flagged systems clear when the root-cause is fixed). The interventional signal is the causal test. If system B co-faults with system A but doesn’t clear when A is fixed, the edge is rejected. Confounders and correlated noise never clear — so they never make it into the graph.

The result: precision and recall of 1.0 across all tested edge cases, including compound stress where six systems fault simultaneously and naive correlation collapses. Strong couplings converge in roughly 100 fault events. 100 buildings in one fleet learn the coupling graph in about three months. One building alone would take years.

This is the density flywheel. More buildings means faster causal learning for every building on the network. The federated layer is not a future product — it is the reason the architecture was designed the way it was, from the first commit.

The four layers

The Custra revenue model has four layers, and the architecture is designed to manufacture each one in sequence as the fleet grows.

L0 — Per-building monitoring. Each building is a fixed $/mo subscription. Revenue scales linearly with buildings; gross margin is approximately 76%. This is the floor, and it is where every services competitor lives. Necessary, not differentiating — but the evidence gate lives here, and you have to clear it before any compounding layer multiplies it.

L1 — Composable platform. Every capability built once deploys to every building. A new trade, KPI, or vertical is a plug-in registration — not a codebase fork. Marginal cost per building falls as capabilities rise. Gross margin climbs toward 88% at scale. This is where platform economics begin to compound.

L2 — Portfolio intelligence. Cross-building rollup, benchmark, and capex forecast. Sells to the owner or REIT at a higher price per building. Portfolio-level benchmarks only exist with a portfolio — value per building rises as the portfolio grows. Turns on at approximately 50 to 100 buildings.

L3 — Federated intelligence. Intelligence learned across all buildings (anonymized) makes every building’s prediction better. A new entrant with 10 buildings cannot replicate what a fleet learns from 10,000. The data moat lives here. Density-unlocked revenue streams grow from roughly 4% to 28% of total revenue as the fleet scales from tens to thousands of buildings.

At 100× the buildings, the model shows approximately 188× the revenue and gross margin rising from 76% to 88%. That is super-linear — and it is manufactured by architecture, not by headcount.

The evidence gate

The platform is synthetically proven. We have run the full case lifecycle — detect, triage, authorize, dispatch, repair, verify, bill, close — end-to-end on simulated building fault data across all 24 building systems, 103 sensor families, and the causal graph learner. The detection results are clean. The lifecycle runs without stubs. The escalation engine cycles correctly through the full chain.

The evidence gate is the next step: detection must be proven on real building fault data before we claim it works on real buildings. We are honest about where we are in that sequence. Real building faults are noisier, more ambiguous, and more physically constrained than synthetic ones. The proof has to happen on real data, and the design-partner engagement is where it happens.

The LBNL Fault Detection and Diagnosis (FDD) dataset is the public labeled reference we are using to calibrate the evidence-gate standard. It contains real HVAC fault events with labeled root causes — exactly the class of evidence the gate requires. When the gate is cleared on the LBNL data and on a design-partner deployment, we will say so explicitly, with the numbers.

Where we are going

Custra is entering its design-partner phase. We are looking for portfolio owners, REITs, and facility managers who want to prove detection together — not be promised it. The engagement is 90 days: ingest connector deployment, operating-state baseline, first fault detection, and a shared findings report. You get a building-intelligence capability proven on your systems and your data. We get the evidence-gate proof. Both sides win.

If that sounds like the right conversation for your portfolio, get in touch.