Verdigris vs SkySpark | 8 kHz ML vs 1 Hz Rule-based FDD

Verdigris vs SkySpark: ML on waveforms vs rules on BMS data

SkySpark and Verdigris are both fault-detection platforms for electrical infrastructure. They solve different problems with different inputs. SkySpark is a software-only analytics layer. It runs rule-based Sparks against existing BMS, metering, and Project Haystack data, typically at 1 Hz. Verdigris is a hardware-plus-software platform. It captures its own 8 kHz waveform data through EV2 sensors. ML models above the sensor layer learn equipment failure modes from waveform shape.

The substantive question is which platform sees the failure modes that matter. Data center critical power is the contested ground. SkySpark performs rule-based fault detection and diagnostics (FDD). The input is whatever the BMS samples. Verdigris recovers stranded capacity. It detects degradation that BMS polling misses entirely.

THEY ANSWER:

“Which alarms matter today?”

SkySpark rule output

Rack-7 temp > 78°F
AHU-2 setpoint deviation
Chiller-1 runtime anomaly
14 rules passing
6 rules suppressed (acked)

[post-aggregation, 15-min]

WE ANSWER:

“Can this circuit hold +30% load safely?”

Verdigris validated limit

CIRCUIT
PNL-3-B
MEASURED LIMIT
412 Acontinuous
HEADROOM
+31%vs nameplate (validated)
EVIDENCE
8 kHz × 21d

[waveform → ML → certificate]

Same panel · Different questions · Different decisions

Verdigris example output, values illustrative. Per-circuit limits derive from your panel's measured 8 kHz signature; the 21-day window matches the T-Mobile rectifier finding (EVD-003).

Capability	SkySpark	Verdigris
Data source	Depends on customer's BMS, metering, and existing data feeds	Own 8 kHz waveform capture via EV2 hardware
Sampling rate	Whatever the source provides (typically 1 Hz BMS polling)	8,000 samples per second at the circuit
Analytics method	Rule-based FDD via Axon scripting ("Sparks")	ML models on waveform features
Project Haystack	Native data model	Different data model, ingests via API and protocols
Rule authoring	Manual rule authoring per asset class	Zero rule authoring, ML learns failure patterns
Failure detection coverage	Known patterns that match a Spark	Novel failure modes inferred from waveform physics
Hardware	Software-only platform	Verdigris EV2 sensors included
Deployment model	Requires Axon expertise and BMS data quality	Turn-key sensors plus cloud intelligence
Target market	Commercial buildings, campus, healthcare, DC secondary	Data center critical power, AI factory

The substantive question is what each platform can see, and which failure modes fall between BMS samples.

How does 8 kHz ML detection compare to rule-based FDD on BMS data?

Rule-based fault detection works when you already know what to look for. An operator writes a Spark in Axon. The rule has a shape. If reactive power deviates by more than X for longer than Y, raise a fault. That Spark fires when preconditions match. When preconditions never match, the Spark stays silent. Equipment failing through an unknown mechanism stays undetected.

Verdigris approaches the same operator problem from the other direction. EV2 sensors capture 8 kHz waveform data at the circuit. Physics-grounded features come off the waveform. The list includes harmonics, phase relationships, transient behavior, and power factor. ML models learn what healthy equipment looks like per asset class. A degrading rectifier drifts away from learned-normal. The drift shows up long before any threshold-based rule would fire.

The T-Mobile deployment crystallizes the difference. Of 800+ rectifiers, 32 were degrading. That is 4% of the fleet. Zero rule-based systems triggered. The rules were not poorly written. No rule existed for the specific 5th-and-7th-harmonic total harmonic distortion (THD) ratio shift. That signature precedes capacitor end-of-life. Verdigris ML caught the drift from waveform shape alone. The advance window ran 21 days.

Rules find the known. ML on high-resolution data finds the unknown. That is the architectural argument in one line.

Why does purpose-built 8 kHz hardware matter for fault detection?

SkySpark is software. It processes whatever data feeds reach it. The BMS typically polls at 1 Hz. Most metering subsystems report 5-minute averages. Those are the resolutions SkySpark works with. No analytics engine can manufacture detail that was never measured.

Verdigris owns the data acquisition layer. EV2 sensors install on existing circuits. They capture waveforms at 8,000 samples per second. The analytics layer above never inherits the BMS resolution ceiling. A 200-millisecond harmonic event compresses to one reading at 1 Hz. The same event produces roughly 1,600 data points at 8 kHz. IEEE 519-2022 anchors the harmonic limits. EPRI publishes capacitor-aging reference signatures. Verdigris ML uses both.

Alert fatigue compounds the resolution gap. Data center operators receive an average of 4,484 alerts per day. 67% are ignored. A platform that fires more rules into that stream does not help. A platform that surfaces validated drift signals does. This is not a software advantage rules-on-BMS can close by writing better code. It is an architectural choice. Bring your own data, or analyze someone else's.

Where SkySpark wins

SkySpark has real strengths in the right context. If your sites already run on Project Haystack, SkySpark fits the native data model with no protocol bridging required. Teams with Axon talent in-house get the most out of the platform, because custom Sparks reward operators comfortable in the scripting language. The rule library approach also shines where fault patterns are well-understood: existing libraries find what someone has already written a rule for.

SkySpark has matured across commercial buildings, campus environments, and healthcare, with breadth across verticals where rule-based FDD is the standard. And for sites that are software-only by mandate, with no appetite for additional sensor hardware on existing circuits, SkySpark's software-only deployment removes the hardware question entirely. For these customers, the trade-off is reasonable: known faults, known data, manageable rule libraries.

What if SkySpark ingests higher-frequency BMS data?

A reasonable question: if we tune the BMS to sample faster and point SkySpark at the higher-frequency feed, does that close the gap?

Sparks run on whatever the BMS delivers. BMS field protocols are the ceiling, not SkySpark's analytics, and rules can only find faults someone anticipated. SkySpark is software analytics on Haystack-tagged BMS data. Sparks are rule-based Axon scripts that fire when configured preconditions match. The input is BMS field-protocol polling, typically around 1 Hz. Even if the BMS delivered higher-frequency data, Sparks remain rule-based. They catch faults a domain expert anticipated and wrote a rule for.

Verdigris is a different architecture: ML on continuous, independent 8 kHz acquisition. ML learns equipment-failure signatures from waveform shape, including signatures no one would write a rule for. The T-Mobile finding (4% of 800+ rectifiers degrading, zero rule-based systems triggered) is the canonical example.

If you already have SkySpark, keep it for rule-based FDD on BMS data it does well. Verdigris is a different architecture, ML on independent 8 kHz waveform, for the failure modes rule-based systems can't anticipate.

Where Verdigris wins

For data center critical power, the calculus changes. Verdigris is purpose-built for operators of data center critical power infrastructure, including UPS, rectifiers, transformers, switchgear, and PDUs. Sites that run AI workloads see sub-cycle GPU power transients that fall between 1 Hz BMS samples entirely, which is exactly where 8 kHz acquisition pays off. For teams that need predictive UPS maintenance, the T-Mobile deployment showed a 21-day advance warning before threshold-based alarms would have fired.

Verdigris also fits operators who want vendor-neutral fleet visibility: EV2 sensors install across Schneider, Eaton, ABB, and Vertiv hardware without OEM lock-in. The platform is most differentiated when reliability is the entry point, detecting equipment degradation that BMS polling never surfaces, not optimizing energy consumption. And for buyers who want turn-key deployment, the package includes sensors, ingestion, and ML with no Axon scripting required. For colocation, NeoCloud, or enterprise data centers, the architecture that brings its own high-resolution data finds the failures that matter.

Evidence: T-Mobile rectifier degradation, Orange Silicon Valley savings

At T-Mobile, Verdigris monitors 800+ UPS rectifiers across data center facilities. 32 rectifiers were degrading. That is 4% of the fleet. Zero rule-based systems triggered. The failure mode was a specific 5th-and-7th-harmonic ratio shift. This precedes electrolytic capacitor end-of-life. The signature lives below standard BMS alarm thresholds.

Verdigris ML caught the drift from waveform shape alone. The advance window ran 21 days. The analysis projected $1.3M to $3.0M in three-year value against $500K investment. ROI ran 3:1 to 6:1. Payback ran 5 to 13 months.

The customer framed the win in their own words.

This represents a strategic shift in how we manage critical infrastructure. While competitors react to failures, we're building proactive intelligence that prevents them. Verdigris Signals gives us visibility into degradation patterns [BMS monitoring] does not surface.

Attribution: Senior Director, Infrastructure and Engineering, T-Mobile

The reliability framing matters at the executive level. Catching 32 degrading rectifiers 21 days early is not an avoided-outage number alone. It is recovered headroom in the critical power path. Loaded but partly compromised gear sits inside the design margin. Operators were already counting on that margin. Restoring it is stranded capacity returned to the AI factory. No new capacity is built.

A SkySpark deployment on the same site would have produced the same silence. Not because SkySpark is poorly designed. Because the input data resolution does not contain the diagnostic signature. Rules do not fire on waveforms that polling never captured.

The pattern reaches beyond critical power. Verdigris found Orange Silicon Valley over $40,000 in annual energy savings the customer had not previously seen. Scott Dworkis is Infrastructure Engineer at Orange Silicon Valley. He framed it like this.

You're likely to learn surprising [findings] once you start digging into the data. [Findings] that go straight to the bottom line. This was certainly the case for us.

This is the architectural argument. The analytics layer is only ever as deep as the data layer beneath it.

Bottom line

Key takeaways for evaluators comparing the two platforms:

Data source decides ceiling. SkySpark analyzes whatever the BMS provides, typically 1 Hz. Verdigris captures 8 kHz waveforms at the circuit through EV2 sensors. No analytics engine can manufacture detail that was never measured.
Rules find the known. ML on high-resolution data finds the unknown. Sparks fire when preconditions match. ML learns healthy-equipment patterns and detects drift, including failure modes nobody anticipated.
Commercial buildings on Project Haystack? SkySpark is the right fit. Data center critical power and AI workloads? Verdigris is purpose-built.
T-Mobile evidence is the architectural argument. 4% of 800+ rectifiers degrading. Zero rule-based systems triggered. 21 days of advance warning from waveform shape alone.
Stranded capacity is the executive frame. Catching degraded gear restores headroom inside the design margin. That is capacity returned to the AI factory, not capacity newly built.