Linear Quote Interpolation: Smooth Retrospective Quotes Without Hiding Future Data

Practical promise. You will be able to reconstruct an interior bid/ask pair, state exactly when it first becomes computable, and prevent that retrospective result from leaking into a point-in-time decision.

A smooth synchronized chart is useful for retrospective inspection. It becomes misleading when the line at 10:00:01 quietly depends on a quote event from 10:00:02. The arithmetic may be correct and the chart may look natural, yet the value did not exist in the system's knowledge at the earlier time.

Linear quote interpolation is therefore two problems, not one:

1. What straight-line bid and ask lie between two quote events?
2. At what time were both endpoint records actually available?

The first question is numerical. The second is point-in-time data engineering. This article keeps them together.

All prices, symbols, venues, and timestamps in the worked examples are synthetic. They teach mechanics and do not describe a historical market event, an executable quote, or a profitable signal.

Event time is not knowledge time

An endpoint needs at least two clocks:

• Event time: when the source says the quote event occurred.
• Availability time: when the process performing this calculation could first use the record after collection and ingestion.

The SEC's Quote Life research methodology, for example, describes records with both exchange-generated and collection-point timestamps. That methodology does not prescribe this algorithm, but it is a primary-source example of why market data may need more than one time coordinate (SEC Quote Life methodology).

The query also has two times:

• Target time: the event-time coordinate whose quote we want to reconstruct.
• Evaluation time: the point-in-time cutoff. A record arriving after this cutoff is unavailable, even if it appears later in the completed dataset.

This distinction prevents hindsight from masquerading as live state.

The calculation

Let $(b_0,a_0)$ be the left bid/ask at event time $t_0$, and let $(b_1,a_1)$ be the right bid/ask at $t_1$. For an interior target $g$, where $t_0<g<t_1$, the interpolation weight is

$$w=\frac{g-t_0}{t_1-t_0}.$$

Interpolate each side of the quote:

$$\widetilde b(g)=(1-w)b_0+wb_1, \qquad \widetilde a(g)=(1-w)a_0+wa_1.$$

This is the standard linear interpolation identity (NIST DLMF, Section 3.3). Because $0<w<1$, the derived spread is a convex combination of endpoint spreads:

$$\widetilde a(g)-\widetilde b(g) =(1-w)(a_0-b_0)+w(a_1-b_1).$$

If both endpoint quotes satisfy $bid\le ask$, the interpolated pair does too. That does not make the pair observable or executable. It only proves a geometric invariant.

A midpoint that is not yet knowable

Consider this synthetic bracket:

The target is halfway through the event-time bracket, so $w=0.5$. The derived bid is 100 and the derived ask is 102.

At an evaluation cutoff of 00:00:01.000, however, the right endpoint will not be available for another 1,120 milliseconds. The correct result is not 100/102. It is right_not_available with null prices. At 00:00:02.120 the same arithmetic becomes computable and the status changes to linear.

Even then, the output carries observable=false. No source published the interpolated pair at the target. The system derived it later from two retained records.

The red knowledge boundary is the lesson: a value can belong at one event-time coordinate and become computable at a later availability-time coordinate.

The policy around the formula

Production behavior depends on boundary policies that the formula does not choose for you. This package makes the following conventions explicit:

The maximum gap is not a universal exchange threshold. It is an engineering choice tied to the source, instrument, session, and downstream task. A long silent interval could contain a halt, outage, empty book, or discontinuous repricing. Drawing through it would manufacture a path.

Regulatory reporting can also have context-specific quote-time, locked-market, and crossed-market policies. As of this article's July 22, 2026 review, the cited SEC Rule 605 FAQs were forthcoming staff guidance scheduled to become effective August 1, 2026, not guidance already in effect. The page states that it represents staff views and has no legal force or effect. Its conventions are not this algorithm's policy and should not be inferred from this generic educational interpolator (forthcoming SEC Rule 605 FAQs).

An auditable algorithm

The implementation sequence is deliberately conservative:

1. Validate identifiers, timestamps, finite prices, and $bid\le ask$.
2. Partition by instrument, venue, and session.
3. Sort by event time and reject duplicate event times.
4. Find an exact quote or the nearest interior endpoints.
5. Enforce no-extrapolation and maximum-gap policies.
6. Compare each endpoint's availability time with the evaluation cutoff.
7. Only then calculate bid and ask.
8. Return value, status, reason, endpoint lineage, first-knowable time, and wait.

Doing the availability check after the arithmetic is not automatically wrong, but it makes accidental leakage easier: an already-computed number can escape through logging, caching, plotting, or downstream joins. Failing closed before calculation keeps the unsafe state visibly null.

Use the lab to cross the boundary

Open the interactive knowledge-time lab. Its opening state is already informative: the target, both event-time endpoints, and the future right endpoint's availability marker are visible.

Use Step to advance the evaluation clock. Before 2.120 seconds, the target is red and blocked. On the step where the right record arrives, the target changes to a purple derived marker and the panel states “first knowable now.” Use Back to cross that boundary in reverse. Reset always returns to the same target-time state.

The scenario selector compares three cases:

• Canonical delay: valid bracket, future endpoint not yet available.
• Gap too wide: both endpoints eventually arrive, but policy still rejects the four-second bridge.
• Locked endpoints: bid equals ask at both endpoints and remains locked under interpolation.

The lab's dashed line is a retrospective construction. It is never labeled as a stream of observed quotes.

Implementation and parity

The Python implementation and TypeScript implementation use the same input fields, statuses, and shared fixture. Their outputs preserve:

• endpoint event and availability timestamps;
• first_knowable_at;
• wait_ms when a record is unavailable;
• interpolated versus observable;
• inclusive maximum-gap behavior;
• null prices for blocked or unavailable results.

Tests cover midpoint arithmetic, point-in-time blocking, exact-arrival equality, wide gaps, no extrapolation, missing partitions, locked and crossed states, nonfinite values, duplicate event times, clock reversal, and timestamp syntax. Test agreement proves that both implementations follow the package contract. It does not prove that interpolation is economically useful.

When linear interpolation is appropriate

It can be useful for a retrospective display, a controlled resampling study, or a sensitivity analysis where the delayed nature of the result is explicit. It can also help compare how a downstream calculation changes under different synchronization conventions.

It is not a live quote generator. It should not be used at target time in a backtest, execution benchmark, or signal unless the system deliberately delays the decision until both endpoint records are available—and even then the value is derived, not executable.

Nonsynchronous observations are not merely a plotting inconvenience. Original research on covariance estimation shows that asynchronous sampling requires methodological treatment rather than an assumed neutral synchronization step (Hayashi and Yoshida, 2005).

Why there is no historical quote-gap story here

A credible historical example needs more than two prices and exchange event times. It needs redistributable primary records, source identity, collection or availability timestamps, correction history, session state, and license terms. Without availability evidence, a completed historical file cannot prove what a reader could have known at the original target time.

For that reason, this article does not turn licensed provider data or a hindsight reconstruction into a factual market story. A future historical case should show the right endpoint absent at the original cutoff and present at a documented later collection time. Until that evidence can be published, the explicitly synthetic example is more honest and more reproducible.

Practical checklist

• Keep event time and availability time as separate fields.
• Partition before selecting endpoints.
• Reject ambiguous, crossed, missing, and nonfinite inputs.
• Set and record an inclusive maximum-gap policy.
• Never extrapolate unless a separately named model explicitly permits it.
• Emit null before both endpoints are available.
• Mark derived values as observable=false.
• Preserve endpoint lineage and the first-knowable timestamp.
• Test the same fixture in every implementation language.
• Treat a smooth chart as a visualization, not proof of a tradable quote.

Summary and next topic

Linear quote interpolation is a retrospective straight line with a delayed knowledge boundary. The arithmetic uses the left and right event-time endpoints. Point-in-time safety uses their availability times. The result first becomes computable only when both records are known, and it never becomes an observed quote merely because the calculation is valid.

Continue with Refresh-Time Sampling, which replaces single-series interpolation with a multistream clock that waits until every required stream has refreshed.