Solutions · Real-time scoring
Compute live feature vectors with the same logic you trained on.
Send current source reports into the ClearFeature execution path and compute requested feature groups using the same versioned Feature Project used historically.
What 'real-time' means here — precisely
In ClearFeature, online computation is request-triggered. A scoring request arrives with current source data; the runtime executes the requested feature groups through the DAG and returns the vector. ClearFeature is not a stream processor continuously recomputing every feature in the background — it computes when a decision asks, which is what most decision systems actually need.
The second-implementation trap
Most teams get real-time features by writing them twice: once for training data, once inside a low-latency service. The second implementation starts as a faithful port and ends as a sibling — with its own null handling, its own rounding, its own bugs. The model, trained on the first implementation, quietly receives the second.
The request-time path
Scoring request
Live source reports
the data available right now
Feature Runtime
Same versioned DAG
dependencies resolved by the platform
Response
Feature vector
requested feature groups
Your model
scoring stays in your systems
Dependencies execute online too
A dependent feature like payment_to_income_ratio needs its upstream features computed first. Online, the platform resolves that order exactly as it does historically — you request the feature group, not a hand-maintained sequence of calls. Dependency logic is defined once, in the registry, for both paths.
Request what the model needs
Feature groups let a scoring request name the set of features a model consumes. The runtime computes that group and everything it depends on — nothing more. Model interfaces stay explicit, and adding a feature to a model is a registry change, not a service rewrite.
Latest values, kept close
The most recent computed feature values are held in Valkey, the platform's latest-value store, for fast retrieval by consumers that need current state rather than fresh computation.
Consistency is the actual feature
The value of request-time execution on ClearFeature is not raw speed — it is that the vector your model receives live is computed by the same tested code that built its training data. Real-time ML fails more often from silent inconsistency than from milliseconds.
Where ClearFeature stops
ClearFeature computes and manages features. Model serving — hosting the model, running inference — remains your system. The platform hands your model a consistent vector; what happens next is yours.
Building request-time scoring?
See the full execution model, or tell us about your latency and consistency requirements.