Solutions · Model reproducibility
Know what your model knew when it made the decision.
ClearFeature combines versioned feature logic with point-in-time source availability so historical feature vectors can reflect the information a production decision could actually use.
Reproducibility is more than saving a prediction
Most systems can tell you what score a model produced. Far fewer can answer the question that actually gets asked — by model validation, by auditors, by your own engineers debugging a bad cohort: what inputs produced that score, computed by which implementation, from which information? A logged prediction and a model version are two pieces of a four-piece puzzle. The other two are the feature code and the data that was available.
The three-clock problem
Every source record lives on three clocks — and confusing them is how reconstruction goes wrong.
event_ts · 10:00
what the data describes
observation_ts · 10:05
the decision is made
available_at · 10:15
the system could first know it
The report describes 10:00. The decision happened at 10:05. But the system could not know the report until 10:15 — so an honest reconstruction of that decision must exclude it, even though it ‘existed’ at the time. Joining history on event time alone silently rewrites what the model knew.
Feature code matters just as much
Even perfectly reconstructed source data is not enough if you recompute with today's feature logic. If the burden-ratio implementation changed in March, reconstructing a January decision with the current code produces a vector the January model never saw. Reproducibility needs the implementation that was live — which is only possible when feature logic is versioned as a first-class artifact.
How ClearFeature makes decisions reconstructible
Three properties, combined:
Versioned Feature Projects
Every feature carries a version; artifacts are immutable and governed by explicit promote/rollback pointers.
Availability-aware history
Sources are stored with when they became available, not just what they describe.
Observation-time execution
Historical vectors are computed as of a decision time, using only what was available by then.
Together: reproducible feature execution — the same code, over the same information boundary, producing the same vector.
In credit
A validator asks why a segment was approved in Q3. With versioned features and availability-aware history, the answer is computed, not archaeologically assembled from pipeline logs.
In trading and forecasting
Backtests are only meaningful if research sees data on the schedule the live system saw it. The same availability discipline that reconstructs decisions also keeps research honest.
Go deeper
The complete temporal model — event time, availability time, observation time, and how point-in-time datasets are constructed — is covered in the technical guide.
Could you reconstruct last quarter's decisions?
If the answer is not a confident yes, it is worth a conversation about how your feature history is built.