How to Backtest Supply-Chain Signals Without Look-Ahead Bias
August 29, 2026
Altsets
Research by Altsets Research
Use historical network topology, historical relationship metrics, publication lags, and defined rebalancing rules instead of applying today's supply-chain graph to past dates.
Data used:Altsets Supply Chain Intelligence: 90k+ entities, 400k+ relationships, 20+ years of history.
Key findings
- A valid supply-chain backtest must snapshot the historical relationship universe as well as historical prices, otherwise future supplier-customer edges can leak into the past.
- Altsets relationship queries support historical as-of dates, allowing topology and metrics to be resolved at the intended research date rather than reconstructed from the current graph.
A supply-chain backtest is only credible if every relationship and metric used by the strategy was observable at the historical test date. That sounds obvious, but it is easy to violate. A current supply-chain graph can contain relationships discovered later, revised metrics, renamed companies, and links that did not exist in the historical snapshot. Using today's graph to simulate a strategy in an earlier year creates look-ahead bias.
Altsets supports historical relationship queries at a requested asOf date. The repo's API documentation includes a historical example for 2025-12-28. That capability matters more for a backtest than almost any individual relationship value.
The core rule
If a strategy is being tested on December 28, 2025, the relationship universe should come from the point-in-time state observable on or before December 28, 2025. Do not begin with today's supplier list and simply attach old prices. The network itself can change.
Customers appear and disappear. Suppliers change. Relationship metrics move.
Company identities and aliases can also evolve. The graph has to be historical too.
Why current relationships create leakage
Imagine a current graph shows a strong relationship between Company A and Company B. You build a strategy that buys A whenever B reports strong demand. If the A-B relationship was not observable until 2026, using it to generate a 2025 trade is data leakage.
The price series may be perfectly historical while the relationship feature is from the future. The backtest will look cleaner than a strategy an investor could actually have run.
Snapshot the topology before the metrics
A robust process should first resolve the historical network. For each test date:
- resolve the companies using identifiers valid at that point;
- query supplier and customer relationships as of the test date;
- record which edges exist;
- only then retrieve the historical economic metrics for those edges.
This prevents a current relationship from entering the old universe just because a historical metric happens to be available somewhere in the database.
Treat first-seen and last-seen dates as research constraints
The repo's relationship-serving layer carries fields for first and last observed relationship periods. Those fields can help determine whether a relationship belongs in a historical research universe. A relationship outside its observed period should not be silently carried backward.
Likewise, a relationship that disappeared should not automatically remain active in later test periods. The exact inclusion rule should be documented and applied consistently.
Use the same information lag a real investor had
Point-in-time relationships are necessary but not sufficient. A backtest should also model publication lag. If a relationship estimate is derived from a filing released on March 15, it should not become available to the strategy on March 1.
The same applies to earnings, presentations, shipping data, or other source material. A strict process uses the date the information became observable, not merely the fiscal period it describes.
Historical metrics should not be forward-filled without a rule
Missing data creates another source of accidental hindsight. Suppose supplier revenue percentage is available in one month but missing in the next. A backtest should not automatically carry the value forward indefinitely unless the strategy explicitly defines that behavior.
Possible rules include use only values available at the test date, carry forward for a fixed maximum window, require a fresh observation, and exclude the relationship when the required metric is missing. The rule matters less than applying it consistently.
Rebalance on defined dates
Relationship data can update monthly while prices update continuously. A backtest should decide when the network is allowed to change. For example: month-end rebalancing, earnings-date rebalancing, quarterly rebalancing, and event-triggered rebalancing. Using a relationship update immediately after it becomes available in some periods but waiting until month-end in others creates inconsistent timing.
A simple point-in-time research design
Consider a strategy that ranks suppliers by exposure to a major customer. A clean design could be: choose a historical month-end, query the network as of that date, retrieve supplier-revenue percentages observable by that date, rank suppliers, form the basket, hold until the next scheduled rebalance, and repeat using the next historical snapshot. The current values of those relationships are irrelevant to the historical ranking. They can be used later to understand how the network evolved, not to rewrite the old signal.
Why this matters for supply-chain strategies specifically
Supply-chain data is relational. That creates more leakage paths than a simple price series. A backtest can accidentally use future information through future company aliases, future supplier-customer edges, revised relationship magnitudes, future network depth, later-discovered counterparties, current sector or country classifications, and current data-cleaning rules. Point-in-time storage is therefore part of the strategy methodology, not just a database feature.
A repeatable anti-leakage checklist
- Fix the historical test date.
- Query topology as of that date.
- Require metrics observable by that date.
- Respect first-seen and last-seen periods.
- Apply publication lags.
- Define missing-value behavior.
- Define rebalance timing.
- Store the exact relationship universe used for each test date.
- Never replace historical network states with today's graph.
- Keep data revisions auditable.
The economic-basket guide explains one relationship-defined basket construction. This article defines what has to change before that idea becomes a legitimate historical backtest.
For the underlying point-in-time methodology, read the Altsets supply-chain data methodology. Browse Supply-Chain Data Use Cases for other research methods.