Can Scalytics Helios run read-only, without controlling anything?

Yes. The default posture is observe and recommend. Scalytics Helios ships in shadow mode: it forecasts, plans, and shows the dispatch it would have made and the savings it would have produced, while writing nothing. Writes are enabled per system and per limit when you are ready. Sensing and acting are separate planes with a read-only boundary between them.

Does Scalytics Helios replace my EMS, BMS, or SCADA?

No. Scalytics Helios reads from your control systems and, when permitted, writes bounded setpoints back. Your systems keep final authority and enforce every safety limit. Scalytics Helios adds the layer that aligns compute placement with energy availability, which those systems were not designed to do.

How does Scalytics Helios treat inference SLOs versus flexible training?

Latency-critical and SLO-bound work is pinned and never shifted against its contract. Scalytics Helios optimizes only the slack, such as pre-training, fine-tuning, batch inference, and ETL. The objective minimizes cost and carbon subject to every SLO as a hard constraint.

Can Scalytics Helios participate in demand response or curtailment programs?

Yes. Demand response, curtailment avoidance, and battery dispatch are solved in the same optimization as workload placement. Scalytics Helios can hold or shed flexible load during a curtailment window and recover it in the next clean window, with the trade-off visible before it acts.

Open Energy Control Plane · Apache 2.0

Helios

The open energy control plane for data centers and the grid.

AI is no longer hardware-bound. It is power-bound. Scalytics Helios bridges extreme-scale compute with the physical grid. Turn massive data center demand into a dispatchable energy asset. Lower power costs for operators. Flexible load for utilities. Sovereign, open-source, and strictly air-gappable.

Self-hostable, sovereign, and built on standard Kafka transport. Helios defines exactly when energy is drawn, dynamically modulating your compute load to match intermittent renewable supply and market pricing.

Request a technical briefing → See the architecture

In production with European clean energy providers

▸ Why energy is the basis ▸ Grid Intelligence

DISPATCH · site:eu-north · window:24h LIVE

carbon intensity now142 gCO₂/kWh

day-ahead price$31.40 /MWh

on-site solar78 MW

battery state64% · charging

flexible load available40% of fleet

grid carbon, next 24h · teal = clean window

HOLDtrain/llm-pretrain-7b · 9,200 GPUh→ 02:10

RUNinfer/realtime · SLO 50mspinned

RUNbatch/etl-nightly · SLO 24hnow

prov: dispatch d-4471 → forecast f-118 → topic.grid:0:90211

Shift Load. Cut Power Costs.

AI is bound by megawatts. Not by hardware.

Scalytics Helios turns grid signals, market pricing, and weather forecasts into workload placement. Modulate your data center load to match intermittent renewable energy over a standard telemetry backbone.

Start with an AI Audit →How It WOrks

Why this exists

Demand was never the hard constraint. Intermittent clean supply meeting AI-scale load is.

Utilities have managed predictable load for a century. AI compute and renewable generation break this model. Data center demand is scaling abruptly, while solar and wind generation depend on weather rather than schedules.

The IEA projects data centers will draw roughly 1,000 TWh in 2026, which mirrors the annual consumption of Japan. Firm clean capacity takes years to build and connect. During this lag, renewable power is curtailed when it is abundant, while compute runs on whatever the grid happens to offer. The shortage is not total generation. The shortage is timing.

The market is responding on the physical side. Vertically integrated operators like IREN are building pipelines of co-located compute and clean energy. What is missing for the rest of the industry is the control layer that makes flexible compute follow clean power. Helios is that layer. It moves the megawatt that would have been curtailed into your next training run.

~1,000 TWh

Projected data center electricity use in 2026, comparable to Japan's annual consumption.

IEA

~156 GW

AI workload power demand projected by 2030, more than quadrupling from 2025.

McKinsey

~40%

Share of large-fleet scheduler jobs that are deferrable, the slack Helios turns into clean compute.

Published hyperscale scheduler data

First principles

AI is the revolution. Energy is the basis it stands on.

Every inference and training run is electricity converted into intelligence. Helios ensures this computation aligns with clean power availability. Solar while the sun is up, wind while it blows, and firm clean power from local storage or small modular nuclear when intermittent sources drop.

The revolution · AI compute

Training Inference Agents

△

placement & timing ↓ Helios ↑ clean power

▽

The basis · clean energy

Solar

Available while the sun is up

Wind

Available while it blows

Small modular nuclear

Firm, dispatchable clean power

Fusion

On the horizon, abundant

Storage

Shifts clean power in time

Remove the base and the layer above cannot stand. Helios makes compute follow clean supply, instead of forcing clean supply to chase compute.

What Helios does

Five jobs. One control plane.

Helios operates a small set of architectural decisions that turn an AI estate from a fixed load into a steerable asset. Each job runs on the same backbone, with the same provenance, and the same read-only line between observation and action.

Sense the energy estate

Ingest carbon intensity, day-ahead and intraday prices, weather and irradiance forecasts, on-site generation, battery state, interconnect limits, and PPA ledgers. Every signal arrives over a Kafka-compatible backbone and lands as a typed, timestamped record you own.

Forecast supply and demand

Renewable output is intermittent and load is spiky. Helios runs federated generation and load forecasting so dispatch is decided against where power and price are heading, not where they were an hour ago. Models train on your data, within your boundary.

Model the estate as a graph

Generation, storage, interconnects, GPU clusters, contracts, and counterparties become a typed graph. Every dispatch decision writes a provenance row in the same transaction that produces it, so an auditor or PPA counterparty can reconstruct exactly why a workload ran where it ran.

Schedule compute against power

A cost-based optimizer places and times work across the estate. Flexible jobs shift to clean and cheap windows. SLO-bound inference stays pinned. Battery charge and discharge, demand response, and curtailment avoidance are solved together, not in isolated tools.

Act through a sovereign control plane

Helios proposes. Your systems dispose. It writes workload placement to your scheduler (Kubernetes, Slurm, Ray) and bounded setpoints to your EMS or BMS, while final authority and safety limits stay with your control systems. No external service calls exist in the core loop. Air-gapped operation is a supported posture, not an afterthought.

The system

Sense, forecast, decide, act. One backbone.

Helios consumes energy and workload signals from a Kafka-compatible backbone, forecasts and models the estate, solves placement with a cost-based optimizer, and writes bounded decisions back to your schedulers and control systems. Observation and control are separate planes with a strict boundary between them.

Sources

Carbon & price feedsself-hostable, no phone-home

Weather & irradianceday-ahead forecasts

Generation & storagesolar, wind, BESS, PPA, SMR

Compute telemetryGPU utilization, job queues

Transport

Kafka-compatiblekafSCALE, S3-native

Stateless brokersstateless segments

Typed recordstimestamped, owned

Helios

Forecast enginefederated supply/demand

Estate graphkafGRAPH, provenance writes

Cost-based optimizerApache Wayang heritage

Dispatch plannerplacement and timing

Surface

Workload schedulersKubernetes, Slurm, Ray

EMS / BMSbounded setpoints only

Audit pipelinesdispatch provenance

Operator consoleOpenAPI surface

Built on kafSCALE kafGRAPH estate graph kafSIEM-grade provenance Apache Wayang optimizer

Energy-aware scheduling

A data center is a flexible asset, not a fixed load.

Most of an AI estate is more patient than it looks. Pre-training, fine-tuning, batch inference, and ETL carry hours of slack. Published hyperscale data shows roughly 40% of scheduler jobs can wait. Helios turns that slack into two degrees of freedom.

Shift in time. Move flexible work into windows where the grid is clean, where on-site solar is peaking, or where the day-ahead price is low. Charge the battery against the forecast, not the clock.

Shift in space. Place work at the site, region, or PPA where clean power is available right now, across a fleet that spans multiple jurisdictions.

SLO-bound inference never moves against its contract. Latency-critical work stays pinned. Helios optimizes the slack, not the promise.

Every decision is accountable. Provenance is a transactional write. A regulator, auditor, or PPA counterparty can reconstruct why a megawatt-hour was spent on a given workload, from the dispatch decision back to the grid signal that drove it.

PLAN d-4471 · optimizer:wayang · horizon:24h SOLVING

objectivemin(cost · carbon) s.t. SLO

jobs in queue312

shiftable127 · 40.7%

pinned (SLO)185

SHIFTpretrain-7b → eu-north 02:10-38% gCO₂

SHIFTfinetune-batch → nordic-hydro-22% $/MWh

CHARGEBESS → solar surplus 78MW+12 MWh

HOLD DRcurtailment event 17:00 to 19:00opt-in

est. 24h: -31% carbon, -19% energy cost, 0 SLO breach

Architecture commitments

Red lines, in plain text.

A buyer in energy or regulated infrastructure reads commitments more carefully than they read case studies. Each line below is a design constraint, not a roadmap aspiration.

Sensing and acting are separate planes. A read-only boundary sits between observation and control.
The optimizer pushes compute to where the energy is, not the other way around. Raw signals stay in their security zone.
Every dispatch decision writes provenance in the same transaction that produces it. No exceptions.
No external service calls exist in the core loop. Carbon and price feeds are self-hostable, and air-gapped operation is a supported posture.
Safe by default. Helios proposes setpoints; your EMS or BMS keeps final authority and enforces every limit.
Standards on every boundary. Kafka wire protocol inbound, OpenAPI on the control surface, and your scheduler's native API outbound.

What Helios is not

The honest limits.

Energy decisions carry consequences. It matters as much what Helios refuses to be as what it does.

Not a power plant or a utility

Helios does not generate electrons. It decides which electrons your compute uses, and when. It is an ontology and control layer, not a physical generation asset.

Not an EMS, BMS, or SCADA replacement

It reads from your control systems and writes bounded setpoints back. Your systems keep authority and safety limits. Helios answers scheduling questions those systems were never built to answer.

Not a carbon-zero button

Scheduling shifts load. It cannot clean a grid that has no clean supply. Helios delivers the most value paired with on-site renewables, storage, and direct power agreements. It respects the physics.

Not a closed SaaS

Apache 2.0, self-hostable, sovereign. The source is inspectable before you commit. The system runs on open standards within your own boundary.

Deployment posture

Runs where your power runs.

Helios is built for behind-the-meter sites, sovereign clouds, and isolated control networks, the places where a phone-home dependency is a dealbreaker.

Footprint

On-premises, behind the meter, in a sovereign cloud, or inside an isolated control network. Zero external dependencies in the core loop. The deployment does not phone home.

Feeds

Carbon-intensity and price signals are self-hostable. Use a market feed where you have one, or run fully offline against your own forecasts. Air-gap is a first-class mode.

Control authority

Helios proposes. Your EMS or BMS disposes. Every setpoint is bounded by limits your control systems enforce. Dry-run and shadow modes ship before any write is enabled.

Transport

Kafka wire protocol inbound. S3-compatible object storage for long-term segment retention. Your data arrives and leaves on the same open standards.

Integrates

Sits above your scheduler and your control systems. Kubernetes, Slurm, and Ray for compute. EMS, BMS, and DERMS for energy. Your stack keeps doing its job.

Source access

Apache 2.0, developed openly. The repository is inspectable, the OpenAPI specification is the contract, and any client that honors it interoperates without our involvement.

Before a first briefing

What buyers ask first.

Yes. The default posture is observe and recommend. Helios runs in shadow mode. It forecasts, plans, and shows you the dispatch it would have made, with the savings it would have produced, while writing nothing. You enable writes per system, per limit, when you are ready. Sensing and acting are separate planes with a read-only boundary between them.

No. Helios reads from your control systems and writes bounded setpoints back when permitted. Your systems keep final authority and enforce every safety limit. Helios adds the layer that aligns compute placement with energy availability, which those systems were never designed to do.

Latency-critical and SLO-bound work is pinned and never shifted against its contract. Helios optimizes only the slack. Pre-training, fine-tuning, batch inference, and ETL carry hours of completion tolerance. The objective minimizes cost and carbon subject to every SLO as a hard constraint.

From whatever source you trust. Helios accepts standard market and carbon feeds where you have them, and runs fully offline against your own forecasts where you do not. Feed ingestion is self-hostable. There are no external service calls in the core loop, so an air-gapped deployment loses no core function.

Yes. Demand response, curtailment avoidance, and battery dispatch are solved in the same optimization as workload placement, rather than bolted on as separate tools. Helios can hold or shed flexible load during a curtailment window and recover it in the next clean window, with the trade-off visible before it acts.

Provenance is a transactional write, not a log line. Every dispatch decision records the forecast, the signal, and the constraint set that produced it, in the same transaction. Any decision in the console walks back to the originating grid record in one step. This makes the output usable for an audit bundle or a contract reconciliation.

Helios is Apache 2.0 and developed openly, consistent with the rest of the Scalytics stack. The repository is inspectable before purchase. The OpenAPI specification is the contract, and the layer it runs on, including kafSCALE, kafGRAPH, and Apache Wayang, is already open. You are never locked to a binary you cannot read.

Where this is

Deployed, assets under management.

Helios is in production. It makes actual dispatch decisions against real energy estates today with European clean energy providers. The architecture below is shipped, open, and inspectable, which is the standard a serious energy buyer holds a vendor to.

In production

Clean energy providers

Deployed in projects with European clean energy providers, placing flexible compute against live generation, price, and carbon signals. Not a pilot deck. A control plane making decisions in the field.

Open source

Apache 2.0, end to end

Helios and the components it runs on, kafSCALE for transport, kafGRAPH for the estate graph, Apache Wayang for the optimizer, and Scalytics Federated for forecasting, are open and inspectable before you commit.

New deployments

Design partners welcome

We are onboarding additional energy-rich compute operators, behind-the-meter sites, and renewable-co-located data centers. If energy is your binding constraint, request a briefing.

Who builds this

Built by a team that has run energy architecture and shipped Apache infrastructure.

Scalytics brings together Apache open-source leadership and senior engineering depth, including team experience inside a major European energy utility. The team includes the original inventors of Apache Wayang, and founder work history spans senior roles at organizations including Allianz, Cloudera, Confluent, E.ON, McKinsey, and Scout24. Helios reflects that background. Disciplined system boundaries, auditable decisions, and an honest line between proposing and controlling.

Request a technical briefing

Make compute follow the clean megawatt.

45 minutes. Architecture, the estate-graph schema, integration paths into your scheduler and control systems, and design-partner terms. Bring your hardest dispatch question.

Book a briefing → Explore Grid Intelligence