energyOS Capabilities

AI foundations

energyOS is built on a layered machine learning architecture that combines several distinct paradigms. No single model is sufficient for energy market intelligence — the platform uses supervised learning as its foundation, extended by deep sequential modeling, ensemble methods, and an LLM reasoning layer that ties outputs together into interpretable language.

Supervised learning

Supervised learning is the core paradigm underlying the platform's price forecasting and fair value estimation capabilities. The system is trained on labeled historical data — input features (storage levels, weather deviations, PADD utilization rates, LMP spreads) mapped to known output values (historical settlement prices, forward curves). The model learns a function that maps inputs to outputs, then generalizes to unseen market states.

In energy markets, supervised learning is particularly powerful because fundamental drivers have well-understood relationships with price outcomes — the challenge is quantifying those relationships across non-linear, regime-dependent data. The platform's training pipeline feeds from historically labeled data, retrains on rolling windows to adapt for drift, and is evaluated continuously against withheld test sets to measure degradation before it affects the inference.

Huber regressor — penalized linear modeling

The Huber Regressor is used within the platform's linear model layer as a robust alternative to standard ordinary least squares regression. Standard regression is highly sensitive to outliers — a single extreme price spike (a common event in energy markets) can distort model coefficients and invalidate forecasts for the subsequent period. The Huber loss function addresses this by behaving like mean squared error for small residuals (where accuracy matters) but switching to mean absolute error for large residuals (where outliers must be down-weighted). The transition point, known as epsilon (ε), is tuned per commodity and contract horizon.

In practice, this means the fair value models remain stable through short-term supply shocks, SCADA events, or weather-driven spikes — producing estimates that reflect underlying fundamentals rather than being distorted by transient market stress. The linear layer feeds its output as a feature into the ensemble models, creating a composited estimate that combines interpretable fundamental relationships with non-linear learning.

Quantile gradient boosting — training on separate data quartiles

Gradient Boosting Machines (GBMs) underpin the platform's contract horizon forecasters. The platform uses quantile regression variants of gradient boosting, which train separate models for different quantiles of the target distribution — typically the 10th, 50th, and 90th percentiles. This produces a range estimate rather than a point forecast, which is critical for energy trading decisions where understanding the upside and downside tail matters as much as the central case.

Each quantile model is trained independently. The 90th percentile model learns the parameters of upside outcomes — high storage draws, cold snaps, plant outages — while the 10th percentile model learns downside scenarios. The 50th percentile (median) estimate becomes the platform's fair value anchor. All three outputs are surfaced to energyOS Chat and available via the LLM reasoning layer when you query a contract for its price range.

Non-linear deep learning — LSTMs and neural networks

Energy price data is inherently sequential — what happened over the past 14 days meaningfully informs what will happen over the next 7. Standard machine learning models treat each input vector as independent, discarding temporal ordering. Long Short-Term Memory (LSTM) networks address this by maintaining a memory cell that selectively retains or forgets information across time steps. This allows the model to learn multi-week patterns — winter build-into-draw transitions, end-of-season storage roll patterns, multi-month refinery turnaround cycles — that would be invisible to non-sequential models.

The feedforward neural networks within the platform are built using PyTorch, with ReLU activations in intermediate layers and sigmoid activations in the final layer for bounded outputs. Architecture depth and hidden unit counts are tuned per commodity vertical — gas storage models use deeper networks than crude oil price models due to the longer memory dependency in the underlying fundamentals.

Adaptive retraining — managing market drift

All supervised models are subject to concept drift: as market structure changes, historical training data becomes progressively less representative of current conditions. The platform implements a rolling-window retraining schedule that continuously updates model weights against recent data. Retraining frequency varies by model type — fast-moving price models retrain weekly, while structural models (PADD utilization regressors, LNG export correlators) retrain on a monthly cycle aligned with data release schedules.

Drift detection is monitored using population stability indices (PSI) computed on held-out validation sets. When PSI exceeds threshold, an automated retraining job is triggered in AWS SageMaker — producing a candidate model that is evaluated against the production model before replacement. No model update reaches production without automated evaluation approval.

Data scale & domains

The total breadth of data integrated into energyOS is one of its primary structural advantages. Rather than relying on a narrow set of price feeds, the platform ingests data across multiple energy domains — each with its own release cadence, column schema, and set of derivative analytics. The scale is not incidental: it is the prerequisite for the cross-domain correlation engine and the LLM's ability to reason over multi-market relationships.

PADD data — a worked example of depth

To illustrate the depth of integration, consider only the Petroleum Administration for Defense Districts (PADD) dataset. PADD regions divide the United States into five districts for tracking refined product logistics. The platform integrates all five districts with their full column sets, updated in alignment with EIA release schedules.

Each PADD series contains multiple columns — for example, PADD1 crude runs alone includes: duoarea, area-name, product, product-name, process, process-name, series, series-description, padd1_crude_runs_mbbld, units, distillate_stocks, gasoline_stocks, crude_stocks, and refinery_util. Every column is independently normalized, tested for stationarity, and fed into the feature pipeline.

Autonomous data integration — release cadences

Integration is batched at specific release intervals corresponding to each source's publication schedule. The system does not poll — it is event-driven, triggering ingestion jobs on confirmed release windows. This ensures the signal store reflects data as quickly as possible after publication while avoiding redundant processing.

ML models

The platform operates three parallel model layers, each targeting a different aspect of market intelligence. They run independently within the pipeline and their outputs are combined in the Intelligence Interface to support a complete analytical picture.

Infrastructure

All platform compute, inference, and storage runs within a dedicated AWS environment. The infrastructure is containerized using Docker, with model serving handled via Amazon Elastic Container Registry (ECR) and execution environments provisioned as ECS tasks. This architecture ensures isolated, reproducible execution with independent scaling across pipeline stages.

LLM layer and prompt design

The language model layer is the final stage of the pipeline — the surface that translates scored signals into interpretable analytical language. The LLM does not access the internet, external APIs, or any data outside the current session context. Its knowledge is strictly bounded by the signals injected into its context window at query time.

Prompt design is tailored to each partner engagement during onboarding. The system prompt encodes the partner's specific market focus, preferred analytical frameworks, vocabulary, and response conventions. A trading desk prompt differs significantly from a grid operations prompt: the former emphasizes price discovery, spread relationships, and position context; the latter prioritizes dispatch readiness, load forecasting confidence, and anomaly severity.

This means two partners asking the same question — "What is the current market regime?" — will receive responses calibrated to their respective market contexts and analytical priorities. The LLM reasoning is not generic; it is a configured intelligence layer that reflects the specific commercial context of your team.

energyOS Chat — the intelligence interface

energyOS Chat is not a search engine or a data retrieval tool. It is a reasoning environment. Every response is grounded in the real signal context, constructed through deliberate analytical logic, and bounded by what the models can actually support. The platform is designed to think out loud — surfacing its reasoning, citing the signals it used, and explicitly flagging uncertainty when it exists.

Critical thinking, not display

The platform is built for analysts who bring hypotheses, not just questions. The most powerful use of energyOS Chat is not asking for data summaries — it is asking the platform to stress-test an assumption, find a relationship you hadn't considered, or explain why a correlation is breaking down at the current market state.

When you upload your own data, the EOS Scalar engine scores it against every active signal and surfaces named correlations with alignment scores between 0 and 1. This is where the platform earns its value — taking your proprietary position data, scheduling logs, or operational metrics and finding their hidden relationships to the broader market environment you did not already know to look for.

Identifying what your data is actually saying

One of the most valuable applications of the platform is using it to understand your own data more completely. Analysts often have proprietary datasets — trading logs, operational schedules, physical position summaries — that contain signals they have not fully decoded. The EOS Scalar Correlation engine scores your uploaded data against all active market signals, surfacing statistically significant alignments that may not have been visible in your internal analysis.

This process is not simply correlation reporting. The LLM layer interprets each alignment in market terms: if your position data shows a strong positive alignment with PADD3 refinery utilization and a negative alignment with ERCOT real-time LMP, the platform explains what that combination suggests about the structural position you are holding — and what market conditions would put it under stress.

Detecting potential shifts you may have overlooked

The regime autoencoder is specifically designed to surface structural breaks — moments when the market moves outside its historically normal behavior in ways that are not yet reflected in price. When the reconstruction error score exceeds threshold, the platform flags a potential regime shift and quantifies the deviation from baseline. This signal is surfaced in all chat responses as a header context, ensuring that every analytical question is answered in the context of whether the market is currently behaving normally.

In practice, regime flags have preceded major price events by one to three sessions — giving analytical teams the advance signal needed to re-evaluate positions before the broader market reprices. The flag does not tell you what to do; it tells you that the assumptions underlying your current analysis may no longer hold.

Distribution

Distribution refers to how market intelligence reaches the people and teams that need it. energyOS is not a broadcast platform — it is a precision instrument. Access is structured around partner workspaces, role-based delivery, and the session context model that ensures every team member receives intelligence relevant to their specific function.

Partner workspace model

Each partner organization is provisioned with an isolated workspace. Feed selection, model configurations, user roles, and system prompt parameters are set per workspace. This means a midstream operator's workspace and a commodity merchant's workspace on the same platform are analytically distinct environments — one is configured for logistics and nomination decisions, the other for directional price discovery.

Feed configuration and prioritization

Not every partner needs every data domain. Feed selection is configured at the workspace level during onboarding — a natural gas trading desk will have gas storage, weather, and NLP signals as primary feeds, with electricity and petroleum as secondary. An ISO operations team will invert this priority. Feed prioritization affects which signals are injected first into the session context window, ensuring the most relevant data is always at the top of the reasoning stack when queries are processed.

Admins can adjust feed priority at any time via Workspace Settings. Significant additions — new commodity verticals, new geographic regions — are handled in coordination with the REDR Labs team to ensure the model layer is appropriately tuned for the new signal space before it is activated.

energyOS updates

The platform is a living system. Model weights, signal schemas, and analytical capabilities evolve continuously — driven by retraining schedules, drift detection, partner feedback, and the ongoing development of the underlying research agenda. This section describes how updates reach the platform and how they affect your workspace.

Model retraining schedule

1. W
   Weekly — price forecasting models

   Fair value models for natural gas and power contracts retrain on a rolling weekly window. Updated model candidates are evaluated against held-out test sets before promotion to production. Partners on affected verticals receive no disruption — model promotion is seamless.

   Automated · No action required
2. M
   Monthly — structural models

   PADD utilization models, LNG export correlators, and regional basis models retrain monthly, aligned with EIA release schedules. Monthly retrains incorporate new structural data that is only available at this cadence.

   Automated · EIA-aligned
3. D
   Drift-triggered — adaptive retraining

   When PSI drift detection exceeds threshold on any active model, an out-of-schedule retraining job is automatically triggered in AWS SageMaker. Admins are notified via the Workspace Settings panel. The REDR Labs team monitors all drift events proactively.

   Event-triggered
4. P
   Partner-driven — roadmap development

   Every partner engagement generates use-case feedback that directly shapes the platform roadmap. New signal integrations, model capabilities, and analytical workflows are routinely sourced from the partner community and developed collaboratively. Partners receive early access to capabilities developed from their own use cases.

   Partnership standard

Use-case examples

The following examples demonstrate energyOS in operational use — real prompts across different analytical contexts, with representative platform outputs. The platform is as specific as the questions you bring to it. These examples are intended to illustrate how precision querying produces precision intelligence.

Market impact

energyOS is built around a thesis: that energy markets are structurally inefficient, and that the primary driver of that inefficiency is the gap between available information and analytical capacity to process it. The platform addresses four specific market dynamics where that gap is largest.

Risk considerations

energyOS is designed as a primary resource for validation and verification of analytical results — not as an execution system. No output from the platform should be treated as a trade instruction, dispatch command, or final operational decision without independent review. Understanding the risk profile of an AI-powered intelligence layer is a prerequisite for using it responsibly.

Risk register

What to read next