HBOM and EU Battery Passport with SWT3

1. The Regulatory Landscape

If you manufacture batteries, operate data centers, or build hardware products for the EU market, you are about to face a new reality: you will need to prove, with traceable evidence, what is in your products, where it came from, and what happened to it over its entire lifecycle.

This is not a reporting exercise you can handle with spreadsheets. The EU Battery Regulation requires machine-readable Digital Product Passports by February 2027. The Energy Efficiency Directive requires annual disclosure of PUE, water usage, and energy sources for every data center above 500 kW. CSRD requires auditable sustainability data. The Cyber Resilience Act requires hardware bills of materials. And they all require traceability -- proof that the data was captured at the right time, by the right system, and has not been altered since.

The challenge is not collecting the data. Most organizations already have BMS systems, thermal sensors, and battery management controllers producing measurements. The challenge is creating an evidence chain that an auditor or regulator can independently verify without trusting the reporting organization's own databases.

These regulations do not exist in isolation. A data center operator who deploys GPU clusters with lithium-ion UPS batteries faces obligations under the Battery Regulation (battery passports), EED (energy and water reporting), CSRD (sustainability disclosure), and CRA (hardware SBOMs) -- simultaneously. A battery manufacturer shipping cells to automotive OEMs needs Digital Product Passports that track state-of-health from factory to end-of-life recycler.

The common thread is traceability. Regulators do not simply want the numbers. They want proof that the numbers were reported at specific times, by identified parties, and that the evidence chain has not been altered.

2. What SWT3 Witnesses

When your building management system reports that facility power consumption is 2,400 kW and IT load is 1,800 kW, SWT3 records those reported values with a SHA-256 fingerprint. If anyone later disputes what was reported, the fingerprint proves the exact values that were recorded at that exact moment. SWT3 does not validate whether 2,400 kW is accurate -- it proves that 2,400 kW is what the system reported.

This distinction matters for assessors. The witness anchor is evidence of reporting, not evidence of accuracy. The assessor must separately verify that the reporting system is calibrated, maintained, and trustworthy. SWT3 provides the cryptographic chain that connects the reporting system's output to an immutable ledger entry.

For regulatory compliance, this separation is a feature, not a limitation. Regulations like the EU Battery Regulation require that manufacturers maintain traceable records. They do not require that the record-keeping system also be the measurement system. SWT3 handles the record-keeping layer with cryptographic integrity, while your existing instrumentation handles the measurement layer.

3. Two Namespaces, One Protocol

SWT3 organizes HBOM and DPP procedures into two namespaces within the Universal Control Taxonomy (UCT). The HBOM namespace covers infrastructure-level and component-level concerns -- inventories, lifecycles, environmental metrics, and supply chains. The DPP namespace covers product-level concerns -- battery health, charge cycles, degradation events, and end-of-life disposition.

4. Quick Start: Data Center HBOM (Python)

This example witnesses a hardware inventory, a thermal reading, and a PUE measurement for a data center. Ten lines of code produce three independently verifiable witness anchors.

from swt3_ai import Witness

witness = Witness(
    tenant_id="datacenter-eu",
    api_key="axm_...",
    endpoint="https://sovereign.tenova.io/api/v1/witness"
)

# Record the current hardware inventory
witness.witness_hardware_inventory(
    component_count=847,
    manifest_hash="a1b2c3d4e5f6...",
    delta_from_baseline=3
)

# Record a thermal reading from the GPU cluster
witness.witness_thermal_profile(
    ambient_temp_c=22.5,
    component_temp_c=68.3,
    threshold_exceeded=False
)

# Record the facility PUE from the BMS
witness.witness_power_usage(
    total_facility_kw=2400.0,
    it_load_kw=1800.0,
    pue_x1000=1333
)

5. Quick Start: Battery Passport (Python)

This example witnesses the three most common battery passport events: a state-of-health snapshot, a completed charge cycle, and a degradation event detected by the battery management system.

from swt3_ai import Witness

witness = Witness(
    tenant_id="battery-mfg-eu",
    api_key="axm_...",
    endpoint="https://sovereign.tenova.io/api/v1/witness"
)

# Record current battery state of health
witness.witness_battery_soh(
    soh_percent=92.3,
    cycle_count=1247,
    capacity_kwh=48.6
)

# Record a completed charge cycle
witness.witness_charge_cycle(
    event_type="charge_complete",
    energy_kwh=42.1,
    peak_temp_c=35.2
)

# Record a degradation event flagged by the BMS
witness.witness_degradation_event(
    degradation_type="thermal_stress",
    soh_delta_percent=0.8,
    ambient_temp_c=42.0
)

6. TypeScript Examples

Data Center HBOM

import { Witness } from "@tenova/swt3-ai";

const witness = new Witness({
  tenantId: "datacenter-eu",
  apiKey: "axm_...",
  endpoint: "https://sovereign.tenova.io/api/v1/witness"
});

// Hardware inventory with baseline comparison
witness.witnessHbomInventory({
  componentCount: 847,
  manifestHash: "a1b2c3d4e5f6...",
  deltaFromBaseline: 3
});

// Thermal profile from monitoring system
witness.witnessHbomThermal({
  ambientTempC: 22.5,
  componentTempC: 68.3,
  thresholdExceeded: false
});

// PUE from building management system
witness.witnessHbomPue({
  totalFacilityKw: 2400.0,
  itLoadKw: 1800.0,
  pueX1000: 1333
});

// Water consumption for WUE reporting
witness.witnessHbomWater({
  litersConsumed: 12500.0,
  wueRatioX1000: 1800,
  sourceType: "recycled"
});

// Supply chain provenance for a component supplier
witness.witnessHbomSupplyChain({
  supplierId: "Samsung-SDI-Korea",
  provenanceVerified: true,
  countryOfOrigin: "KR"
});

Battery Passport

import { Witness } from "@tenova/swt3-ai";

const witness = new Witness({
  tenantId: "battery-mfg-eu",
  apiKey: "axm_...",
  endpoint: "https://sovereign.tenova.io/api/v1/witness"
});

// State of health snapshot
witness.witnessDppSoh({
  sohPercent: 92.3,
  cycleCount: 1247,
  capacityKwh: 48.6
});

// Charge cycle event
witness.witnessDppChargeCycle({
  eventType: "charge_complete",
  energyKwh: 42.1,
  peakTempC: 35.2
});

// Degradation event
witness.witnessDppDegradation({
  degradationType: "thermal_stress",
  sohDeltaPercent: 0.8,
  ambientTempC: 42.0
});

// End-of-life handoff
witness.witnessDppEol({
  dispositionType: "recycling",
  handlerId: "Umicore-BE-0471",
  finalSohPercent: 72.1
});

7. Component Lifecycle Chain

The HBOM-LIFE.1 procedure witnesses component lifecycle events. A component moves through defined stages from installation to end-of-life. Each transition produces a witness anchor, creating a verifiable chain of custody for every tracked asset.

from swt3_ai import Witness

witness = Witness(
    tenant_id="datacenter-eu",
    api_key="axm_...",
    endpoint="https://sovereign.tenova.io/api/v1/witness"
)

# GPU installed in rack
witness.witness_component_lifecycle(
    event_type="installed",
    component_id="GPU-A100-SN-00421",
    age_days=0
)

# GPU commissioned after burn-in testing
witness.witness_component_lifecycle(
    event_type="commissioned",
    component_id="GPU-A100-SN-00421",
    age_days=1
)

# Scheduled maintenance at 6 months
witness.witness_component_lifecycle(
    event_type="maintained",
    component_id="GPU-A100-SN-00421",
    age_days=180
)

# Degradation detected after 2 years
witness.witness_component_lifecycle(
    event_type="degraded",
    component_id="GPU-A100-SN-00421",
    age_days=730
)

# Decommissioned for replacement
witness.witness_component_lifecycle(
    event_type="decommissioned",
    component_id="GPU-A100-SN-00421",
    age_days=1095
)

# Sent to recycling facility
witness.witness_component_lifecycle(
    event_type="recycled",
    component_id="GPU-A100-SN-00421",
    age_days=1096
)

The six supported lifecycle event types are: installed, commissioned, maintained, degraded, decommissioned, and recycled. Every anchor in the chain carries the same component_id, allowing an assessor to reconstruct the complete history of any individual component by filtering ledger entries on that identifier.

8. Battery Health Tracking

The EU Battery Regulation requires manufacturers to provide state-of-health data throughout a battery's life. Three DPP procedures work together to build a complete health profile: DPP-SOH.1 captures periodic SoH snapshots, DPP-CHRG.1 records individual charge and discharge cycles, and DPP-DEGRAD.1 records degradation events flagged by the battery management system.

SoH Snapshots Over Time

Periodic SoH witnessing creates a verifiable degradation curve. Each snapshot records the current health percentage, the cumulative cycle count, and the remaining usable capacity.

# Factory commissioning -- SoH 100%
witness.witness_battery_soh(soh_percent=100.0, cycle_count=0, capacity_kwh=52.0)

# After 500 cycles -- normal degradation
witness.witness_battery_soh(soh_percent=96.1, cycle_count=500, capacity_kwh=49.9)

# After 1000 cycles -- approaching warranty threshold
witness.witness_battery_soh(soh_percent=92.3, cycle_count=1000, capacity_kwh=48.0)

# After 2000 cycles -- second-life candidate
witness.witness_battery_soh(soh_percent=81.5, cycle_count=2000, capacity_kwh=42.4)

# Below 80% -- end-of-first-life trigger
witness.witness_battery_soh(soh_percent=78.2, cycle_count=2200, capacity_kwh=40.7)

Charge Cycle Monitoring

Individual charge and discharge events can be witnessed to create a granular energy transfer history. The four supported event types are charge_start, charge_complete, discharge_start, and discharge_complete.

# Charge started
witness.witness_charge_cycle(
    event_type="charge_start",
    energy_kwh=0.0,
    peak_temp_c=24.0
)

# Charge completed -- record energy delivered and peak temperature
witness.witness_charge_cycle(
    event_type="charge_complete",
    energy_kwh=42.1,
    peak_temp_c=35.2
)

# Discharge completed -- record energy consumed
witness.witness_charge_cycle(
    event_type="discharge_complete",
    energy_kwh=38.7,
    peak_temp_c=31.8
)

Degradation Events

When the battery management system detects a degradation event, the DPP-DEGRAD.1 procedure records the type, the SoH impact, and the ambient conditions. Six degradation types are supported: calendar_aging, thermal_stress, overcharge, deep_discharge, mechanical, and unknown.

# Thermal stress during a heat wave
witness.witness_degradation_event(
    degradation_type="thermal_stress",
    soh_delta_percent=0.8,
    ambient_temp_c=42.0
)

# Deep discharge event during grid outage
witness.witness_degradation_event(
    degradation_type="deep_discharge",
    soh_delta_percent=1.2,
    ambient_temp_c=28.0
)

# Calendar aging after long storage period
witness.witness_degradation_event(
    degradation_type="calendar_aging",
    soh_delta_percent=0.3,
    ambient_temp_c=20.0
)

9. Supply Chain Provenance

The HBOM-SUPPLY.1 procedure witnesses supply chain provenance for hardware components. Each anchor records the supplier identifier, whether provenance verification was performed, and the country of origin. This supports EU due diligence requirements for conflict minerals, forced labor prohibitions, and supply chain transparency regulations.

from swt3_ai import Witness

witness = Witness(
    tenant_id="datacenter-eu",
    api_key="axm_...",
    endpoint="https://sovereign.tenova.io/api/v1/witness"
)

# Memory modules -- provenance verified
witness.witness_supply_chain_provenance(
    supplier_id="Samsung-SDI-Korea",
    provenance_verified=True,
    country_of_origin="KR"
)

# Power supplies -- provenance verified
witness.witness_supply_chain_provenance(
    supplier_id="Delta-Electronics-TW",
    provenance_verified=True,
    country_of_origin="TW"
)

# Network switches -- provenance pending
witness.witness_supply_chain_provenance(
    supplier_id="Supplier-X-Redacted",
    provenance_verified=False,
    country_of_origin="CN"
)

The supplier_id field accepts any string identifier. Organizations that need to protect supplier relationships at higher clearing levels can hash the supplier name before passing it to the witness method. The anchor still provides a verifiable record without exposing the supplier identity.

10. End-of-Life and Recycling

The DPP-EOL.1 procedure witnesses the final disposition of a battery or product. This is the terminal event in the Digital Product Passport -- the anchor that closes the lifecycle chain. It records the disposition type, the identity of the handler (recycler, refurbisher, or disposal facility), and the final state of health at handoff.

from swt3_ai import Witness

witness = Witness(
    tenant_id="battery-mfg-eu",
    api_key="axm_...",
    endpoint="https://sovereign.tenova.io/api/v1/witness"
)

# Battery sent to certified recycler
witness.witness_end_of_life(
    disposition_type="recycling",
    handler_id="Umicore-BE-0471",
    final_soh_percent=72.1
)

# Battery repurposed for stationary storage
witness.witness_end_of_life(
    disposition_type="repurpose",
    handler_id="SecondLife-Energy-DE-0893",
    final_soh_percent=78.5
)

# Battery refurbished with new cells
witness.witness_end_of_life(
    disposition_type="refurbishment",
    handler_id="BattRefurb-NL-0214",
    final_soh_percent=65.0
)

The five supported disposition types are: recycling, repurpose, refurbishment, landfill, and hazmat_disposal. The handler identifier should be specific enough for the assessor to verify the handler's authorization -- facility license numbers, EU WEEE registration numbers, or equivalent identifiers.

11. Environmental Reporting

Data centers face annual reporting obligations under the EU Energy Efficiency Directive and CSRD. Three HBOM procedures provide the witness infrastructure for environmental metrics: HBOM-WATER.1 (water consumption), HBOM-PUE.1 (power usage), and HBOM-THERM.1 (thermal monitoring).

Water Consumption and WUE

Water Usage Effectiveness (WUE) measures how many liters of water a data center consumes per kilowatt-hour of IT energy. The HBOM-WATER.1 procedure witnesses the reported values.

# Monthly water consumption report -- recycled water source
witness.witness_water_consumption(
    liters_consumed=12500.0,
    wue_ratio_x1000=1800,
    source_type="recycled"
)

# Facility using municipal water
witness.witness_water_consumption(
    liters_consumed=28000.0,
    wue_ratio_x1000=2400,
    source_type="municipal"
)

# Air-cooled facility -- zero water consumption
witness.witness_water_consumption(
    liters_consumed=0.0,
    wue_ratio_x1000=0,
    source_type="municipal"
)

The five supported water source types are: municipal, recycled, rainwater, groundwell, and mixed. The source type is relevant for CSRD reporting, which distinguishes between freshwater withdrawal and recycled water use.

Power Usage and PUE

Power Usage Effectiveness (PUE) is the primary energy efficiency metric for data centers under the EED. The HBOM-PUE.1 procedure witnesses the total facility power, the IT load, and the computed PUE ratio.

# Hourly PUE reading from BMS
witness.witness_power_usage(
    total_facility_kw=2400.0,
    it_load_kw=1800.0,
    pue_x1000=1333
)

# Summer peak -- cooling overhead increases PUE
witness.witness_power_usage(
    total_facility_kw=2800.0,
    it_load_kw=1800.0,
    pue_x1000=1556
)

# Winter baseline -- lowest PUE
witness.witness_power_usage(
    total_facility_kw=2100.0,
    it_load_kw=1800.0,
    pue_x1000=1167
)

Thermal Monitoring

Thermal data supports both operational safety and environmental reporting. The HBOM-THERM.1 procedure witnesses ambient and component temperatures along with a threshold exceedance flag.

# Normal operation
witness.witness_thermal_profile(
    ambient_temp_c=22.5,
    component_temp_c=68.3,
    threshold_exceeded=False
)

# Threshold exceeded -- triggers operational alert
witness.witness_thermal_profile(
    ambient_temp_c=28.0,
    component_temp_c=92.1,
    threshold_exceeded=True
)

12. What the Assessor Sees

Every witness method produces an SWT3 Witness Anchor -- a structured, independently verifiable evidence record. Here is a representative anchor from an HBOM-PUE.1 power usage witness call:

SWT3-E-CLOUD-HBOM-PUE1-PASS-1788288000-7f3a92c1e405

The anchor encodes the deployment tier, provider, procedure identifier, verdict, epoch timestamp, and a 12-character SHA-256 fingerprint. The assessor can independently recompute the fingerprint from the recorded input values to verify that the anchor has not been tampered with.

Evidence Interpretation

13. Regulatory Mapping

Each SWT3 procedure maps to specific requirements across multiple regulatory frameworks. The following matrix shows which procedures provide evidence relevant to each regulation.

14. Getting Started

Install the SDK for your language:

# Python
pip install swt3-ai

# TypeScript / Node.js
npm install @tenova/swt3-ai

Both SDKs support demo mode -- omit the API key and endpoint to run locally. Witness anchors print to the console so you can verify the output before connecting to the ledger. When you are ready for persistent, independently verifiable evidence, create a free account and set the API key.

Resources

• UCT Registry -- full procedure catalog with regulatory mappings
• SDK Documentation -- Python and TypeScript reference with all witness methods
• PyPI: swt3-ai
• npm: @tenova/swt3-ai
• Anchor Verification -- independently verify any SWT3 Witness Anchor
• Create a free account