Independent compliance evidence for data center energy efficiency reporting
EcoStruxure IT is Schneider Electric's data center infrastructure management (DCIM) platform, deployed in more facilities worldwide than any competing DCIM solution. It monitors power, cooling, and environmental conditions across racks, rows, rooms, and entire sites. It calculates PUE and WUE. It exposes this data through a REST API.
The problem is not data collection. EcoStruxure already does that well.
The problem is evidence independence. When an EU EED auditor asks "prove your PUE was 1.35 last quarter," an EcoStruxure dashboard screenshot is your own system reporting on itself. The operator who runs the facility is also the operator who controls the data. There is no separation between the claim and the evidence.
EU Energy Efficiency Directive (2023/1791) Article 12 requires data centers above 500 kW to report PUE, WUE, and energy consumption to a public database. CSRD requires auditable sustainability metrics that can withstand third-party assurance. ISO 30134-2 defines how PUE should be measured but not how to prove it was measured correctly. The gap between "we collected the data" and "here is independently verifiable evidence" is where SWT3 fits.
SWT3 operates alongside EcoStruxure as an independent witness layer. It does not replace, modify, or intercept any EcoStruxure functionality. EcoStruxure remains the source of truth for facility operations. SWT3 creates a separate, tamper-evident record that an auditor can verify without relying on the facility operator's own systems.
| EcoStruxure Metric | SWT3 Procedure | What the Anchor Captures |
|---|---|---|
| Facility power + IT load | HBOM-PUE.1 |
Total facility kW, IT load kW, PUE ratio (x1000) |
| Inlet/outlet temperatures | HBOM-THERM.1 |
Ambient temp, component temp, threshold breach flag |
| Cooling water consumption | HBOM-WATER.1 |
Liters consumed, WUE ratio (x1000), source type |
| Hardware asset inventory | HBOM-INV.1 |
Component count, manifest hash, delta from baseline |
| DR event participation | ADR-EVENT.1 |
Event phase, committed kW, signal source |
A small script runs on a schedule (every 15 minutes, hourly, or daily depending on the metric). It reads the current values from EcoStruxure's API, then passes them to the SWT3 SDK. The SDK mints a cryptographic witness anchor for each reading and stores it in a separate ledger that the facility operator cannot alter.
Nothing changes about your EcoStruxure deployment. SWT3 is read-only. It never writes to EcoStruxure, never modifies your DCIM configuration, and never requires Schneider Electric credentials or licenses. It simply observes and records.
Most deployments poll every 15 minutes for PUE and thermal data, hourly for water consumption, and daily for hardware inventory. Each anchor gets a timestamp showing exactly when the metric was witnessed.
Why this matters: PUE is the single most scrutinized metric in data center energy reporting. EU EED Art. 12 requires it. CSRD auditors will ask for it. Investors benchmark against it. But a PUE number from your own monitoring system is a claim, not evidence. This procedure turns each PUE reading into a cryptographic record that anyone can verify independently.
What EcoStruxure provides: Real-time facility and IT power readings from PDUs and branch circuits.
What SWT3 records: Total facility power (kW), IT equipment power (kW), and the PUE ratio. PUE is stored as an integer multiplied by 1,000 to avoid rounding ambiguity (a PUE of 1.35 becomes 1350).
Anchor factor_a contains facility power, factor_b contains IT load. PUE = factor_a / factor_b. Compare against ISO 30134-2 thresholds. A PUE of 1.4 or lower is considered efficient for most facility classes.
from swt3_ai import Witness
witness = Witness(
endpoint="https://sovereign.tenova.io",
api_key="axm_live_...",
tenant_id="YOUR_TENANT"
)
# Poll EcoStruxure REST API
metrics = ecostruxure_client.get_power_metrics()
witness.witness_power_usage(
total_facility_kw=metrics["facility_power_kw"],
it_load_kw=metrics["it_load_kw"],
pue_x1000=int(metrics["pue"] * 1000)
)import { Witness } from '@tenova/swt3-ai';
const witness = new Witness({
endpoint: 'https://sovereign.tenova.io',
apiKey: 'axm_live_...',
tenantId: 'YOUR_TENANT'
});
const metrics = await ecostruxure.getPowerMetrics();
await witness.witnessPowerUsage({
totalFacilityKw: metrics.facilityPowerKw,
itLoadKw: metrics.itLoadKw,
pueX1000: Math.round(metrics.pue * 1000)
});Why this matters: Thermal excursions damage equipment, void warranties, and indicate cooling system failures. An auditor may ask whether your facility stayed within ASHRAE A1 recommended ranges (18-27C inlet). EcoStruxure alerts you in real time, but those alerts can be dismissed or silenced. A witness anchor is permanent.
What EcoStruxure provides: Inlet and outlet temperature sensors per rack.
What SWT3 records: Ambient temperature, component temperature, and whether a configured threshold was exceeded at the time of witnessing.
When factor_c = 1, a thermal threshold was exceeded at the time the anchor was minted. Cross-reference with ASHRAE A1 envelope (18-27C recommended inlet range). A history of threshold breaches may indicate cooling capacity issues.
witness.witness_thermal_profile(
ambient_temp_c=22.5,
component_temp_c=35.2,
threshold_exceeded=False
)await witness.witnessThermalProfile({
ambientTempC: 22.5,
componentTempC: 35.2,
thresholdExceeded: false
});Why this matters: Water consumption is becoming the next PUE. CSRD ESRS-E3 requires water and marine resource disclosure. Data centers using evaporative cooling can consume millions of liters annually. Regulators and communities increasingly demand proof that water usage is being tracked and reduced. The source type (municipal vs. recycled vs. rainwater) matters for sustainability scoring.
What EcoStruxure provides: Cooling system water flow rates from chiller plants, cooling towers, and direct liquid cooling systems.
What SWT3 records: Total water consumption volume, WUE ratio (x1000 integer encoding, same as PUE), and water source classification.
WUE ratio in factor_b uses x1000 encoding. A WUE of 1.8 L/kWh is stored as factor_b of 1800. Source type distinguishes between municipal water, recycled water, and rainwater harvesting -- relevant for CSRD ESRS-E3 water disclosure.
witness.witness_water_consumption(
liters_consumed=4500.0,
wue_ratio_x1000=1800,
source_type="municipal"
)await witness.witnessWaterConsumption({
litersConsumed: 4500.0,
wueRatioX1000: 1800,
sourceType: 'municipal'
});Why this matters: Knowing what hardware is in your facility at any given moment is a baseline requirement for security (NIST CM-8), insurance, and capacity planning. EcoStruxure tracks assets, but an auditor needs to know whether the inventory you present today matches what was actually there last month. A manifest hash makes the full inventory tamper-evident, and the delta count shows exactly how many assets changed between snapshots.
What EcoStruxure provides: Asset inventory tracking for servers, network equipment, PDUs, UPS units, and cooling infrastructure.
What SWT3 records: Total component count, a SHA-256 hash of the complete manifest, and the delta (number of additions or removals) since the last witnessed baseline.
A non-zero delta indicates hardware changes since the last witnessed inventory. The manifest hash provides a tamper-evident fingerprint of the full inventory list. Compare sequential manifest hashes to detect unauthorized hardware additions or removals.
witness.witness_hardware_inventory(
component_count=1847,
manifest_hash="a3f7c9d1e5b2...",
delta_from_baseline=3
)await witness.witnessHardwareInventory({
componentCount: 1847,
manifestHash: 'a3f7c9d1e5b2...',
deltaFromBaseline: 3
});Why this matters: Data centers that participate in demand response programs earn revenue by reducing consumption during peak grid stress. But proving that you actually curtailed what you committed to curtail is where disputes arise. This procedure creates a timestamped record of each phase of the DR event, linking your facility's participation to the grid operator's dispatch signal.
What EcoStruxure provides: Facility-level load data during demand response events.
What SWT3 records: The event phase (signal received, curtailment start, curtailment end, restoration), committed power reduction in kW, and the signal source identifier linking to the grid operator's dispatch record.
DR events produce a sequence of anchors linked by the signal source identifier. Query by signal source to reconstruct the complete event timeline. See the ADR Demand Response guide for the full six-procedure lifecycle.
witness.witness_demand_response(
event_phase="curtailment_start",
committed_kw=250.0,
signal_source="ISO-NE-Signal-4821"
)await witness.witnessAdrEvent({
eventPhase: 'curtailment_start',
committedKw: 250.0,
signalSource: 'ISO-NE-Signal-4821'
});| Examiner Question | Where to Look |
|---|---|
| What is the facility PUE? | HBOM-PUE.1 anchor, factor_a / factor_b. Or read pue_x1000 directly and divide by 1000. |
| When did PUE exceed threshold? | Filter HBOM-PUE.1 anchors where pue_x1000 exceeds target value (e.g., > 1600 for PUE > 1.6). |
| Is thermal data independently verified? | HBOM-THERM.1 anchor chain, not EcoStruxure logs. Each anchor has an independent SHA-256 fingerprint. |
| What is the water usage effectiveness? | HBOM-WATER.1 anchor, factor_b (WUE x1000). Divide by 1000 for L/kWh. |
| How often is energy data collected? | Anchor timestamps show the exact collection cadence. Compare consecutive HBOM-PUE.1 timestamps. |
| Can EcoStruxure data be retroactively altered? | No. Anchors are minted at collection time with SHA-256 fingerprints. A modified value would produce a different fingerprint, breaking the evidence chain. |
# Python pip install swt3-ai # TypeScript npm install @tenova/swt3-ai
Both SDKs include all HBOM and ADR witness methods. No additional packages or plugins required.
Create a free account to persist anchors to the SWT3 ledger. You will receive a tenant ID and API key immediately. Anchors become independently verifiable at the public verification endpoint.