What Should a Point-in-Time Supply-Chain Feature Store Actually Save?
September 14, 2026
Altsets
Research by Altsets Research
Reproducible network research needs snapshot identity, relationship direction, metric missingness, entity and security mappings, observation timing, and transformation lineage instead of saving only the final model feature.
Data used:Altsets Supply Chain Intelligence: 90k+ entities, 400k+ relationships, 20+ years of history.
Key findings
- Point-in-time feature infrastructure is designed to prevent future feature values from leaking into historical training data, which becomes especially important when graph features depend on changing relationships and entity mappings.
- Supply-chain features need lineage back to the graph snapshot, relationship evidence, directional metric, entity-security mapping, and transformation version so later backfills or corrections do not silently rewrite old experiments.
For a serious supply-chain strategy, the hardest part may not be the model. It may be proving exactly what every feature looked like at every historical decision date and serving the same definition when the strategy goes live. A graph feature such as customer concentration can depend on entity resolution, security mapping, relationship direction, metric availability, and the network snapshot used to calculate it. If any of those inputs are silently revised after the fact, the research environment and live environment can end up using features that share a name but not the same information state.
A feature store needs more than the final number
Imagine a model feature called top_customer_revenue_share. Saving only the final percentage is not enough for reproducible research. The researcher should be able to recover which relationships were included, which company entity each edge belonged to, which directional metric was used, which snapshot date generated the feature, and what version of the transformation code produced it. If a later entity-resolution change merges two company records or a relationship metric is corrected, the old backtest should remain reproducible rather than silently changing the next time it is run.
The same applies to structural graph features. A shared_supplier_count calculated for a portfolio should be tied to a specific point-in-time graph. Today's network may contain relationships that were unknown or nonexistent at the historical formation date. Recomputing the feature from the newest graph and joining it to old returns creates the appearance of historical data while using modern knowledge. Feature-store architecture exists partly to prevent this class of mistake. Feast, for example, explicitly supports point-in-time correct historical feature retrieval so that future feature values do not leak into model training.
Valid time and observation time should remain separate
Supply-chain data can have several relevant timestamps. A relationship can be economically effective on one date, disclosed on another date, ingested by the system later, and become tradable information only after processing finishes. A reproducible quant platform should decide which of those timestamps controls each research use case. A business-history analysis may care about when the relationship actually existed, while a public-information trading backtest cares about when the strategy could have observed and used it.
Recent work on point-in-time data integrity formalizes the same problem for financial statements by separating economic or valid time from public, system, and tradable time and preserving original versus restated observations in a bitemporal framework. Supply-chain research benefits from the same discipline because relationship backfills and improved entity resolution can otherwise rewrite the historical feature matrix. The monthly snapshot itself is not enough if old snapshots are regenerated with later knowledge.
Store lineage for graph aggregations
Graph features are unusually dependent on upstream lineage. A centrality score can change because one distant edge changed. A peer-group feature can change because a company gained a customer. A portfolio-overlap measure can change because two entity aliases were merged. When the model sees only the final number, these transformations are difficult to audit.
A strong feature pipeline can therefore store or reproducibly reference the graph snapshot, relationship identifiers, entity-security mappings, transformation version, and feature-generation timestamp for each model batch. The researcher does not necessarily need to duplicate the entire graph for every feature row. Content-addressed snapshots, immutable monthly partitions, or stable snapshot IDs can provide lineage without exploding storage. What matters is that the historical result can be regenerated from the same inputs rather than the newest version of the world.
Offline and live features need the same semantics
A strategy can backtest correctly and still fail operationally if the feature definition changes when it moves online. The offline pipeline might calculate customer concentration from a full monthly snapshot, while the live service queries only a partial set of relationships or uses the newest entity mapping. The model then receives a live feature whose distribution differs from the training feature for infrastructure reasons rather than economic change.
Feature stores commonly separate an offline store for historical training from an online store for low-latency serving while attempting to preserve one feature definition across both. Supply-chain systems can use the same principle even if the strategy does not require millisecond latency. Precompute stable graph features on the monthly snapshot, serve the latest approved values online, and treat genuinely fast events such as customer earnings as separate event inputs rather than rebuilding the whole graph on every request.
The conclusion is that point-in-time graph research is a data-engineering product
A quant can write a correct formula for a network feature and still produce an invalid backtest if the historical input state is not reproducible. A supply-chain feature store should preserve point-in-time joins, relationship direction, metric missingness, entity and security mapping, snapshot identity, observation timing, and transformation lineage so the live strategy can consume the same feature definition the backtest actually tested. That infrastructure may feel less exciting than the alpha model, but it is what makes the model's historical evidence auditable.
The market-knowledge timing guide explains why economic truth and observable truth can have different dates. The survivorship-bias guide explains why entity and security histories need to remain point in time.
For relationship definitions and evidence limits, read the Altsets methodology.