Continuous safety engine
Oxaide Horizon
Continuous monitoring for BESS assets that need more than a one-off review. Horizon applies the same physics-informed approach in an ongoing operating context, with customer-controlled deployment options.
Edge-first
Deployment posture
Pilot scoped
Commercial model
Why Horizon Exists
Horizon exists for operators who need continuous visibility after the baseline has been established. It is intended for cases where periodic review is no longer enough and the customer wants a persistent operating layer around asset condition.
Real-Time dQ/dV Engine
Processes cycle data continuously so the operator has a live view of condition rather than a periodic retrospective.
Edge-First Architecture
Supports customer-controlled deployment close to the asset, including environments where raw data should remain on site.
Rust Safety Kernel
Core analytics are implemented in Rust for predictable execution in operational settings where reliability matters.
True SoH Tracking
Maintains a calibrated view of asset condition over time and can expose that signal to adjacent operating systems.
Deployment Options
Deployment is chosen around customer controls, telemetry access, and operational requirements.
Dispatch Integration
Horizon can expose a lightweight API for EMS, control, and monitoring integrations.
GET /horizon/asset/{id}/soh → float 0–1 (True SoH)
GET /horizon/asset/{id}/usable-energy → MWh
GET /horizon/asset/{id}/plating-risk → score 0–100 + boolean alert
GET /horizon/asset/{id}/soc-envelope → recommended ceiling/floor
Pre-Requisite
Horizon works best from a calibrated starting point. Most pilots begin with an Oxaide Verify review of the target asset so the operating model reflects the site rather than a generic baseline.
BESS Pilot Engagement
Verify baseline · deployment setup · pilot monitoring
Scope first
Defined review scope
Boundary, telemetry window, and mandate question are pinned down before conclusions move.
Encrypted handling
Protected review workflow
Review traffic and operating data are handled with encrypted transfer and controlled access.
Customer boundary
Customer-controlled deployment
Managed, private, and isolated deployment paths are available when the environment requires them.
Direct accountability
Principal sign-off
Technical accountability stays close to the method rather than disappearing into a generic workflow.