Skip to content
ClearFeature

Industries · Energy & trading

Build availability-aware features for research and live trading systems.

Use the same feature definitions across historical analysis and live forecasting while respecting when market, weather, and operational data actually became available.

The data problem behind every forecast

Energy and trading models consume data that is chronically late relative to what it describes: vendor feeds deliver with lag, operational reports are revised, forecasts arrive on publication schedules. A model that looks excellent in research and mediocre live has usually been trained on information timing the live system never had.

Typical data categories

Conceptually — the structured inputs these systems compute features from:

source

Market prices

Trades, quotes, settlements across venues.

source

Weather

Observations and published forecast runs.

source

Load & generation

Consumption and production actuals and estimates.

source

Operations & fundamentals

Outages, capacities, flows, operational reports.

Three clocks, one honest answer

A market event happens at 10:00. Your vendor delivers it at 10:03. Your model predicted at 10:01 — so that event was not knowable, however real it was.

event_ts · 10:00

the market event occurs

observation_ts · 10:01

your model predicts

available_at · 10:03

the vendor feed delivers it

The event was real at prediction time — but unknowable. Research data must exclude it, or the backtest is fiction.

Historical leakage makes strategies look better than they are

Joining research datasets on event time quietly grants every historical prediction a few minutes of clairvoyance. In markets, minutes of future information can be the entire edge — which is why leakage in trading research does not just inflate metrics, it invents them. ClearFeature builds training data from observation times against recorded availability, so research sees the world on the same delay live systems did.

Same transformations in research and production

Availability discipline solves half the problem; implementation drift is the other half. When research features live in notebooks and live features live in the production system, the two definitions of 'rolling imbalance' diverge just like any duplicated code. In ClearFeature, both paths execute the same versioned Feature Project.

The duplicated-implementation problem →

Multi-source DAGs

Sources

Market data

Weather runs

Operational reports

Availability-aware feature DAG

Source features

per-feed computations

Dependent features

spreads, ratios, cross-source signals

Consumers

Forecasting / trading models

your systems — ClearFeature does not execute trades

Fits alongside your forecasting stack

ClearFeature computes feature vectors for research datasets and live requests. Signal generation, forecasting models, and any execution systems remain entirely yours — the platform ends where the feature vector is delivered.

Self-hosted, close to your feeds

Trading organizations run their own infrastructure for good reasons. ClearFeature deploys inside it — next to your market-data feeds and your models — on components your engineers already operate.

The self-hosted model →

Does your research see data on the live schedule?

Tell us how your research and production feature pipelines are built today.