Build a Reproducible Point-in-Time Supply Chain Feature Store

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.

A point-in-time supply chain feature store should preserve enough information to reproduce a feature's historical inputs and serve the same definition in production. Saving only the final percentage is insufficient. A customer-concentration feature depends on the relationship universe, directional metric, missing values, company identities, dated security mappings and transformation version used to calculate it.

Consider the displayed Altsets estimate that Nvidia represents 17.62% of Micron revenue. A feature row storing only 17.62 cannot show whether Nvidia was selected from a complete observed customer set, whether unquantified customers were excluded or which snapshot supported the value. If a later entity merge or correction changes that set, recomputing from the latest graph can produce a different historical result under the same feature name.

The architecture should therefore retain immutable references to accepted inputs, distinguish economic time from observation and availability time, and version the transformation. These are proposed controls for a research platform, not a claim that Altsets exposes a ready-made feature-store schema. The dataset supplies dated relationships and estimates; the consuming system must preserve the information state it actually used. The engineering objective is to explain every feature revision and prevent offline training and live serving from silently calculating different objects.

Design one feature's evidence record before building the store

For a feature named top_customer_revenue_share, define what "top" means: the largest available supplier revenue percentage in the accepted customer universe. An unknown share cannot be treated as zero, so the largest measured customer need not be the largest actual customer. Store coverage information alongside the result.

The Micron-Nvidia estimate illustrates the directional requirement. It describes Nvidia's importance to Micron's revenue. A customer cost percentage for the same edge would describe Micron's importance to Nvidia's costs and cannot replace the feature's input. Preserve units as well: a stored percentage and a fractional model input need an explicit transformation rather than a silent scale change.

A recommended lineage record can contain:

These are design requirements, not field names promised by an API. The Altsets documentation describes the retrieval interface. The methodology explains estimates, coverage and historical preservation.

Preserve valid time separately from observable time

A relationship can be economically effective before it is disclosed, ingested or approved for a trading model. Business-history research may ask when the relationship existed; a public-information backtest asks when its accepted evidence became usable. One timestamp cannot necessarily answer both.

Bitemporal storage distinguishes the period a record describes from when the system recorded that version. Source-publication and strategy-availability evidence may require additional fields or references. If those dates are unavailable, record that limitation; an archive date alone is not proof of the public-information state at an earlier decision.

The point-in-time principle is also used by Feast's historical retrieval design: historical training should not receive future feature values. For commercial graphs, the accepted input state must include topology and identity as well as numerical values. A monthly partition regenerated using later discoveries can still leak information despite its historical name.

Store revisions as explainable versions

Altsets methodology describes preserving historical information while allowing technical corrections, entity-resolution improvements or identified errors. A consuming research system should retain the version accepted by the original experiment and distinguish it from any corrected rerun.

That distinction supports a useful audit question: did the feature change because the business relationship changed, because coverage improved, because an alias was merged or because the calculation changed? Saving only the final number makes those explanations indistinguishable. An immutable snapshot reference plus versioned inputs can preserve them without duplicating the entire graph for every row.

Content-addressed snapshots, immutable partitions or stable snapshot identifiers are possible storage designs. The essential property is recoverability of the accepted state, not a particular database or vendor.

Global graph features need broader lineage than one edge

A shared-supplier count changes when portfolio membership or counterparty resolution changes. A centrality score can change when a distant edge changes. A peer-group feature can change when a neighbor acquires a customer. The lineage must therefore reference the graph and mapping versions that determine the aggregation, rather than only the focal company's direct relationships.

Coverage flags belong in those aggregations. A lower measured concentration can reflect a new quantified customer rather than a genuine diversification event. A new supplier can reflect improved evidence rather than a newly formed commercial relationship. Keeping structural presence, metric availability and revision cause separate gives later analysis a way to distinguish those cases.

Serve the same approved definition offline and live

A correct historical join does not prevent production drift. The offline job might use a full approved snapshot while the live service queries a partial result, drops missing values differently or resolves aliases using a newer mapping. The model then sees different semantics for infrastructure reasons.

Use the same transformation specification and accepted coverage policy in both paths. Version the approved materialization and reconcile live outputs to the corresponding offline calculation before switching batches. Precomputed graph state can coexist with faster earnings or market inputs; those events should retain their own observation times rather than silently rematerializing the entire historical graph.

The backtesting join guide addresses admissibility at one decision. This page's storage contract makes those accepted decisions reproducible across experiments and production deployments.

Sources

• Altsets supply chain dataset
• Feast feature store documentation
• Point-In-Time Data Integrity in Quantitative Equity Research

Related research

• Why Public Supply Chain Sources Are Still Hard to Turn Into a Dataset

Methodology

Read the methodology for this research.

Cite this research

Altsets Research. "Build a Reproducible Point-in-Time Supply Chain Feature Store." Published September 18, 2026. https://www.altsets.com/research/point-in-time-supply-chain-feature-store

Copy citationCanonical URLMethodology