This is our credibility page — a concrete, honest account of how Acumix turns proprietary, continuously-collected data into point-in-time panels that a quant or fundamental desk can trust in a backtest. No look-ahead, no personal data, mapped to the tickers you trade.
Every datapoint we ship carries two timestamps. The observation_date is when the fact was true in the world. The knowledge_date is when that fact first became knowable to us — the earliest moment it could have entered a trading decision. A backtest reading the panel as of a given date sees only rows whose knowledge_date is on or before that date, so a signal never leaks information from the future.
Panels are append-only and never restated. When a value is revised, we do not overwrite the original — we append the corrected observation with a new knowledge_date. The historical record of "what we believed, and when" is preserved intact. That is what makes the history a genuine point-in-time series rather than a survivorship-flattered snapshot.
A panel is a fixed universe of entities tracked through time — a set of venues, stores, SKUs or merchants defined by a stable rule, not by whoever happens to be alive today. Once an entity enters the panel it stays in it, even after it goes dark.
Dead entities are kept, because the death is the signal. A restaurant that leaves a delivery platform, a store that stops stocking a category, a listing that disappears — each is a real datapoint about supply and churn. Silently dropping them would bias every level and every trend upward. Instead we retain the entity with an explicit end state, so a churn or attrition index measures what actually happened rather than what survived.
Because the universe is fixed and additions are effective-dated, the panel does not suffer the classic survivorship distortion where today's winners are back-projected as though they were always present.
We do not sell raw records. Each panel is a set of aggregated indices engineered to proxy a KPI the market cares about, computed the same way every period so the series is internally comparable. The core families:
Every index is documented in the accompanying data dictionary: the entity universe it is built on, the normalization, and the exact window. Nothing is a black box — a desk can see precisely what each number measures before it goes into a model.
Honest about proxies. Review-velocity and availability-decay are proxies, not reported figures — we present them as leading indicators with a documented relationship to the underlying KPI, and we state the limitations. That is exactly the framing a diligence process expects.
Raw entities — a venue, a store, a SKU, a merchant — mean nothing to a portfolio until they are tied to a security. We maintain a security master that maps each entity to its listed parent, with effective dates on every link.
Effective dating is what makes the mapping point-in-time correct. When a brand is acquired, spun out, or re-parented, the ownership edge changes on the date it actually changed — so a historical panel attributes each entity to whoever owned it at that time, not to today's owner. A restaurant brand that moved between platform operators, or a retail banner that changed hands, is credited correctly across the whole history.
The output is a panel keyed by the ticker you trade — UBER, HD, ABNB, DHER.DE, MELI — with the entity-level detail rolled up beneath it and never exposed as personal data.
// effective-dated ownership edge entity_id: "venue_88213" entity_type: "delivery_merchant" parent: "Delivery Hero SE" ticker: "DHER.DE" effective_from: 2024-02-01 effective_to: null // current prior_parent: "—" pii: none
Live collection gives us the present. To make the panels backtestable we pair them with a reconstructed multi-year history — several years of prior observations rebuilt so each carries a defensible knowledge_date reflecting when the underlying fact was genuinely knowable, not when we happened to reconstruct it.
That depth matters. A signal is only investable if you can show how it behaved across enough periods — through different demand regimes and at least a few reporting cycles — to have confidence it is not noise. Our history is built to give a quant team that sample from day one, then extended forward by the live weekly and daily panels so the series stays continuous into the current print.
Where history is reconstructed rather than collected live, we say so explicitly and document the source and its limitations. The point-in-time discipline is the same for the historical rows as for the live ones: append-only, dual-dated, never back-filled with hindsight.
| observation_date | knowledge_date | ticker | metric | value | unit |
|---|---|---|---|---|---|
| 2026-06-30 | 2026-07-04 | UBER | menu_price_index | 104.7 | index (2023=100) |
| 2026-06-30 | 2026-07-04 | DHER.DE | merchant_supply_index | 98.3 | index (2023=100) |
| 2026-06-30 | 2026-07-05 | DASH | review_velocity | 1.42 | rev / active venue / wk |
| 2026-06-30 | 2026-07-03 | HD | in_stock_rate | 93.6 | % of catalog |
| 2026-06-30 | 2026-07-06 | ABNB | occupancy_proxy | 71.4 | % booked |
| 2026-06-30 | 2026-07-04 | MELI | seller_supply_index | 108.7 | index (2023=100) |
Panels are delivered in whatever your stack already reads, so evaluation needs no bespoke integration. Same schema and same point-in-time semantics across every channel — only the transport changes.
Flat, versioned point-in-time files. The simplest way to load a panel straight into a backtest.
Columnar, typed and compressed for large histories — efficient to query at panel scale.
A live secure data share into your warehouse — panels arrive as governed tables, no file handling.
Query panels by ticker, metric and as-of date — pull the exact point-in-time slice a model needs on demand.
We'll send a point-in-time sample with its data dictionary so your team can validate the methodology directly, on a ticker you know.