Historical AI Features: Event Time Versus Available-At Time

Name the history the buyer needs

Suppose an enterprise buyer wants to reconstruct inputs for predictions made at noon last month. One supplier offers a historical feature dataset rebuilt with subsequent corrections. Another offers the versions available at each prediction time. Both may describe their data as historical, yet they answer different questions. The choice turns on whether the buyer wants the revised account of an earlier event or the information accessible when the prediction was made.

Keep four times distinct. The entity timestamp is the historical prediction time to which features will be joined. A feature event timestamp locates an observation or value in the history being represented. A correction's creation timestamp records when that version was created under the source's definition. The query time is when someone later asks for the historical dataset. Creation and availability coincide only if the data's meaning and delivery history establish that relationship.

The software reference here is Feast v0.66.0, released August 21, 2026. Its release notes identify the optional created-timestamp cutoff. The versioned concepts documentation anchors the behavior discussed here. An offered deployment still needs its own version and offline-store support identified.

References: [S1][S2]

PIT-421: four retained rows for one noon prediction

PIT-421 is an original fictional equipment-risk example. There is one entity, E1, with a historical prediction timestamp of 12:00. The four feature rows below all match E1 and the same feature. No other rows exist. Their values are arbitrary unitless inputs, and C is a correction of B. All times share one stipulated same-day UTC basis.

A later historical query is imagined at 15:00, with a 60-minute feature time-to-live, or TTL. For the availability comparison only, stipulate that each created timestamp accurately records when that version became available online. This is an assumption about the invented data, rather than a property conferred by the column name.

The exercise traces the stated selection rules. No Feast query, model training or evaluation was executed.

The two selections return different inputs

Feast's documented default constrains feature event time. Where a created timestamp is supplied, it breaks ties between rows with the same event time by choosing the highest created timestamp; it does not otherwise exclude later-created rows.

Apply that rule to PIT-421. D has the latest feature event time in the dataset, but 12:10 is after the entity's 12:00 prediction time. D cannot supply that historical input. A, B and C are earlier than noon and within the stipulated 60-minute event window. B and C share the latest eligible event time, 11:50. Their tie is resolved by creation time: C's 12:20 is later than B's 11:55. Default selection therefore returns C, value 12, even though that correction was created 20 minutes after the prediction.

The optional cutoff additionally requires the created timestamp to be at or before the entity timestamp. C fails that condition. B passes it and has a later event time than A, so the result becomes B, value 9. D remains future to the prediction. Under this example's explicit availability assumption, B is the version available at noon; C is the later corrected account of the same 11:50 event.

The input changes because the eligibility conditions change. The numbers establish no model-output difference, accuracy improvement or elimination of every information leak.

References: [S1][S3]

A shorter TTL does not distinguish these corrections

Feast anchors the historical lookback to each entity timestamp, rather than to the time the query runs. For PIT-421's 12:00 prediction, the illustrative 60-minute lookback reaches 11:00. Running the query at 15:00 does not move that historical window to 14:00-15:00.

B and C each have an event age of 10 minutes at noon because both represent 11:50. Reducing the example's TTL to 20 minutes would exclude A's 40-minute-old event while still admitting B and C by event age. C's later creation remains unresolved by that change.

TTL screens how far back an eligible feature event may lie. The additional cutoff screens when its version was created. One condition cannot substitute for the other when corrections preserve the original event timestamp. Neither illustrative TTL is a recommendation for an actual workload.

References: [S1]

Then remove the availability assumption

Now let created_at mean creation in a computation or storage system, before a later publication to the online serving path. In that interpretation, B's 11:55 timestamp says when its stored version was created. It supplies no publication time. Even though 11:55 is before noon, the model might still have been unable to obtain B at noon. The comparison cannot establish availability from that field alone.

This is why Feast's concepts documentation qualifies its online-history interpretation by the meaning of the created timestamp. The cutoff tests the supplied clock; the field's provenance determines what conclusion follows. An actual offer needs to explain how computation, ingestion and online publication relate, and which event its availability field records. Different serving destinations may also require different availability evidence.

Retaining the required versions is equally consequential. If C overwrote B and only C remains, excluding C cannot recreate B's value of 9. Correct entity and feature keys are needed to associate versions with the intended prediction, and the clocks must be interpretable on a common basis. A clean timestamp inequality cannot repair a wrong identity or a missing version.

The documented optional filter excludes rows with null created timestamps, and unsupported offline stores raise an error. The versioned API documentation also states that feature views without a created-timestamp column are unaffected. Resolve the actual offered implementation, store and column coverage before accepting a broader availability claim. These are applicability limits on the selection mechanism, rather than evidence that every deployment supports it.

Even a substantiated availability reconstruction establishes what could be obtained at the declared boundary. Establishing what a particular prediction actually consumed would require evidence from that serving path; retrieval from historical data alone does not supply it.

References: [S1][S3]

Compare offers against the same historical requirement

Consider two invented offers for PIT-421. Offer One promises an event-time history using retained corrections. It identifies the supplied feature series and the latest-created tie rule. Its noon input is C, value 12. This can suit a buyer studying the revised history of the equipment. It can be a valid deliverable without promising reconstruction of information available at noon.

Offer Two expressly promises versions available for historical predictions. Under the example's availability stipulation, it returns B, value 9. Its wider claim needs more than a point-in-time label: the supplier must substantiate the availability field's meaning, retained version history and supported cutoff in the implementation actually offered. If its created field only records earlier computation, the noon availability question remains open.

Ask the supplier to trace one nonconfidential late-correction case against the requested prediction time. The useful explanation identifies the matched entity and feature, the competing versions, the time each represents and the reason one was selected. For this example, merely returning C with an 11:50 event timestamp leaves the buyer's noon-availability requirement unanswered. Returning B without establishing the availability clock leaves a different evidential gap.

Choose One when corrected event history is the required input and its stated coverage suffices. Choose an availability-aware scope when the task requires information obtainable at the historical prediction time, with the necessary evidence for that scope. If both questions matter, distinguish the two outputs and their interpretations. A disagreement between 12 and 9 is then an explainable difference in the requested history, rather than automatic proof that one dataset is defective.

Keep sample design and serving releases with their own evidence

Selecting the intended historical version does not establish representative samples, group-disjoint validation, model quality or production safety. A dataset can meet its time-selection rule while placing related devices on both sides of a training/validation split. The linked grouped-data guide examines that separate population and fitted-preprocessing question.

Likewise, a feature-history extract does not identify the model, transformation and data combination currently serving requests. The linked model-registry guide follows promotion into the observed release and the scope of returning to an earlier state. Use these guides for their respective decisions; neither replaces the version-selection comparison here.

Discuss a separate customer-selected equipment installation

If the chosen system also needs a separate physical equipment installation, Leviathan's Complete Physical Infrastructure Deployment service and project inquiry below are the relevant route. Share a nonconfidential outline of the customer-selected equipment, destination, mounting and IT connection requirements, and physical handoff needs to discuss scope and availability.

That inquiry concerns agreed physical receiving, rack integration, installation and cabling. Feature-store configuration, data processing, model hosting, training or evaluation, and software commissioning remain with the separately appointed software providers.

References: [L1]