On 16 June 2023 the company now called World Kinect moved its ticker from `INT` to `WKC`. Look up `WKC` directly in the Quantverse price warehouse, the table of daily bars (a bar is one day's prices and volume for one symbol), and the rows begin on that day. Everything earlier sits under `INT`, which the warehouse's 2026 rows show taken up by a different issuer (observed 19 September 2026). A literal lookup returns three years of `WKC` history, and an `INT` history that stops in 2023 and resumes as something else.

Neither answer is wrong about the table. Both are wrong about the company. Rather than rewrite the warehouse, the prices endpoint reassembles the series at query time from a **symbol lineage**: the ordered, non-overlapping eras of the symbols one security traded under. This post follows one request, `GET /v1/securities/WKC/prices`, through four decisions: identity, rename evidence, stitching across the seam, and what the response lets you check.

## Why the bars are not re-keyed

When measured on 19 September 2026 the warehouse held 48.6 million daily bars for about 36,000 US tickers back to January 2004, each keyed to the symbol in force that day. One corporate-actions feed was backfilled with history re-keyed to the current symbol, so World Kinect's dividends were stored back to 2004 under `WKC`, while the old symbol kept receiving the same events. On 16 September 2026, 59 of `INT`'s 90 dividends also existed under `WKC` with matching ex-date, sequence and amount; a naive union would apply them twice. Re-keying also cannot serve a reused symbol, where one row key would belong to two unrelated holders. So the bars stay where they traded, and identity is resolved per request.

## Decision one: which security does the ticker name?

Every ticker-scoped request takes an `as_of` date, defaulting to today, and its first job is identity: which security did this symbol name then? The strongest evidence is the SEC's EDGAR ticker records, each a stint: an observed interval during which one entity held one symbol. When exactly one in-scope entity's stint covers `as_of`, that entity is preferred. `WKC` today resolves to World Kinect; `INT` as of 2020 to the same entity. `META` as of 8 June 2022 resolves to the Roundhill fund that held the symbol; one day later, to Meta Platforms, which had traded as `FB` until then.

When the stints name no holder, or several, the resolver falls back to the platform's own listing records, most recently listed first, and takes the first; among listings starting on the same day that order is undefined. `BNC` had three such tied holders on 8 October 2026, and the pick decides whether the request succeeds or fails. Identity is a ranking, not a refusal.

## Decision two: what counts as evidence of a rename

Two sources describe renames; neither is complete alone.

**Explicit ticker-change events** from a commercial vendor record `old → new` on a date. Authoritative where present, their coverage starts in June 2023, so the 2022 `FB → META` rename has no event.

**EDGAR stints** reach much further back, but a stint's end is often the date a crawl last saw the symbol, not the date it stopped trading. World Kinect's `INT` stint runs to 8 March 2026, overlapping `WKC` by nearly three years.

Each catches what the other misses. Meta's stints hand over cleanly, `FB` ending on 8 June 2022 and `META` starting the next day, so the builder infers that rename from succession. World Kinect's stints overlap, so the explicit event supplies the boundary, and its date wins: the `INT` era ends on 15 June 2023.

## Decision three: what the builder refuses to guess

The hard part is not linking symbols. It is declining to. An EDGAR entity is not a trading line: a fund trust is one entity holding hundreds of funds under their own symbols. The iShares Trust had 1,631 stints across 601 symbols (regression fixture, 8 October 2026).

An earlier builder inferred a rename from any two stints of one entity that abutted within seven days, and inside a trust unrelated siblings abut by accident. The documented failure mode: `IVV` was served `AGT → AOA → ACWF → IVV` history, bars and dividends included. The code correction was committed on 8 October 2026.

A stint succession is inferred only when all of the following hold:

- the entity's complete EDGAR history never shows two symbols trading at once (a shared boundary day is a handover) and none of its stints is malformed;
- one symbol's tenure ends and another's begins within seven days;
- each is the other's only candidate;
- no explicit event already leaves the one or enters the other.

An explicit event is always eligible, and eras are keyed by tenure rather than symbol, so Fiserv's recorded `FISV → FI → FISV` is three eras, not a cycle.

When the queried lineage's evidence contradicts itself, the builder does not repair it. Two successors, a cycle, boundaries out of order, an ambiguous succession, a rename no tenure could have held, or more than 32 eras make that lineage invalid, and the request is served as `503 ERR_UNAVAILABLE` on the splits, dividends and prices routes. A partial chain would merely look right. Nine symbols were in that state on 8 October 2026; the count is not stable.

## Decision four: stitching across the seam

For `WKC` today the lineage is two eras: `INT` from its first recorded stint in 2004 through 15 June 2023, then `WKC` from 16 June 2023, open-ended. A page is served with one warehouse query per era, cut to the era's dates and the requested window, in order until the page fills. Every bar carries the symbol in force on its date, so 15 June 2023 is labelled `INT` and the next bar `WKC`.

Corporate events are gathered the same way, era by era, which disarms the duplicates. A 2010 distribution keyed to `WKC` never qualifies, since in 2010 the security traded as `INT`. Where two copies of one event both qualify, a fixed preference keeps one: more reporting sources, then the era covering the date, then the latest observation. Each World Kinect dividend enters the multiplicative adjustment once.

Adjustment is opt-in.

- `none`, the default, serves the warehouse values unchanged.
- `splits` divides prices and multiplies share volume by every split ratio for splits executing strictly after the bar's date; the bar on the execution date already trades on the new basis.
- `splits_dividends` also multiplies every bar strictly before an ex-date by `1 − D / previous close`, where `D` is the sum of that ex-date's USD distributions (one factor per ex-date and currency) and the previous close is the unadjusted close of the last bar before the ex-date anywhere in the lineage. If that bar belongs to the `INT` era, as for a hypothetical ex-date on the first `WKC` trading day, the factor anchors on an `INT` close.

Figures are illustrative: a bar closes at 100, the next day is the ex-date of a 2.00 dividend, so the factor is 0.98, and an earlier bar that closed at 90 is served as 88.20. Only events dated on or before `as_of` apply, so a request as of 2020 is never reshaped by a 2023 event.

A separate `known_as_of` pin filters events by a knowledge date: the first observation for events seen since the platform's knowledge epoch of 12 September 2026, and an approximation for earlier backfilled history (declaration date, else ex-date, for dividends; execution date for splits). The pin governs visibility, not values: a dividend first observed in 2027 stays out of a series pinned at 2026, but an already visible event is served with its current, possibly restated, figures.

## What you can check from the response

The response returns neither the factor schedule, the reference closes nor the evidence behind each era.

- `security` carries the resolved entity's stable public id and name; for a fund, that is the issuing trust. `lineage` lists the eras queried. Both are `null` when no entity resolved and the literal symbol was served.
- `splits_applied`, `dividends_applied` and `dividends_skipped` are counts, one per split and one per dividend factor; a factor is skipped when it is not in USD, has no bar before its ex-date, or would be zero or negative. If an adjusted series has quietly become splits-only, the counts say so; rebuilding the factors takes the corporate-action rows and the unadjusted closes, each served by its own endpoint.
- Each corporate-action row carries its symbol, its `known_since` date, first and last observation times, how many reporting sources carried it, and whether they disagree. That count is corroboration, not provenance: it does not show the sources were independent.
- The factor schedule depends only on the lineage, `as_of`, `known_as_of` and the adjustment, never on the page, so a paginated walk over unchanged data returns what a single request would; the pin is a filter, not a snapshot.

## What it does not do

The lineage is served as currently known: stints and rename events carry no usable knowledge time, so `known_as_of` cannot un-know a rename. Bars and corporate actions are current-state, served with their corrected values whatever the pin says. The market-wide sweeps take no `as_of` and no lineage, and still contain the cross-symbol duplicates the ticker routes remove.

The evidence for a rename is never complete, and identity is ranked before a lineage is validated. The rule is to say so, rather than serve a series that merely looks continuous.