Previous-Tick Interpolation: A Causal Carry with an Expiry Clock

Practical promise. Build a common-time view from irregular observations without borrowing an event or correction that was not yet knowable, and make every expired carry visibly missing.

Two instruments can update milliseconds apart while a calculation still asks for values at exactly 14:30:01.000. Previous-tick carry-forward answers with the latest eligible observation. The word "eligible" does most of the work.

An event must be old enough to belong to the target grid, its stored revision must already be available at the claimed query time, and the selected source must still be within a declared expiry limit. If any of those tests fail, a plausible number is less useful than an explained missing value.

This method is often called previous-tick interpolation. That name is conventional, but potentially misleading: it does not estimate a value between two observed endpoints. It holds one recorded value forward as a step function.

Why one timestamp is not enough

Suppose a quote says its event time was 14:30:00.700 but the record does not become usable until 14:30:01.200. At a query cutoff of 14:30:01.000, its event belongs to the past but its information does not. Selecting it would be future-knowledge leakage.

A correction exposes the same issue. A revision can refer to an old event time and arrive seconds, minutes, or days later. Recomputing an old grid after that arrival can produce a valid revised vintage. It cannot make the correction knowable in the original vintage.

Keep four instants separate:

The package requires $q \ge g$. A live snapshot normally uses $q=g$. A later batch can use $q>g$, but its output is a later vintage and must be versioned as such.

The two eligibility gates

Represent each source record as $r=(e_r,a_r,k_r,x_r)$: event time, availability time, revision, and value. For instrument $i$, grid $g$, and query cutoff $q$, form the candidate set

$$\mathcal{C}_i(g,q)=\{r:e_r\le g \text{ and } a_r\le q\}.$$

The first inequality prevents future-event backfill. The second prevents a late arrival or correction from leaking into a vintage that predates it.

From the candidates, choose the greatest event time. If multiple available revisions share that event time, choose the greatest revision:

$$r^*=\operatorname*{arg\,max}_{r\in\mathcal{C}_i(g,q)}(e_r,k_r).$$

This package validates that higher revision numbers have later availability times. A contradictory history is rejected rather than silently reordered.

The diagram has three missing outcomes because they mean different things. Before the first event there is no history. A known replay corpus may show that an event existed but was not yet available. A selected event can also exist and be knowable but be too old for the declared use.

Expiry is part of the algorithm

Let source age be $\Delta=g-e_{r^*}$ and let $L$ be the maximum permitted age. This implementation emits

$$y_i(g,q)= \begin{cases} x_{r^*}, & \Delta \le L,\\ \text{missing}, & \Delta > L. \end{cases}$$

Equality passes. One millisecond beyond the limit expires. The stale output keeps the source event time, availability time, revision, and age, but its value is null so downstream code cannot accidentally treat it as usable.

max_staleness_ms is mandatory and finite in the reference implementation. There is no universal correct threshold: it depends on the feed, instrument, session, downstream decision, and clock quality. Requiring the caller to choose and record a value prevents an invisible unlimited carry from becoming a default.

Walk through an original and a corrected vintage

The canonical fixture is synthetic and uses $L=1{,}500$ ms.

1. Instrument A has value 100.0 at event 14:30:00.100. Revision 0 becomes available at 14:30:00.180.
2. At grid/query 14:30:01.000, the source is 900 ms old. It is carried as 100.0.
3. Revision 1 changes that old event to 99.8 and becomes available at 14:30:01.400.
4. The same grid evaluated with query cutoff 14:30:02.000 returns 99.8. That is a later corrected vintage, not a rewrite of what was known at 14:30:01.000.
5. At grid/query 14:30:02.000, the source age is 1,900 ms. The status is stale; the value is missing and the revision 1 lineage remains visible.
6. A 100.4 event at 14:30:02.200 is available at 02.260. At 14:30:03.000 it is 800 ms old and is carried.

Instrument B adds a delayed-arrival case. Its 14:30:00.700 event is not available until 14:30:01.200. The 14:30:01.000 live vintage cannot use it. A later query cutoff can.

What to notice in the static diagram: the correction moves only the knowledge cutoff, not the event. The expiry decision still measures grid time against event time. Availability decides whether a revision is knowable; staleness decides whether its source is still usable.

The output is a value plus an audit trail

Returning only the number hides the most important distinctions. Each sample contains:

• grid_time and query_time;
• value, which is null for missing or stale states;
• source_event_time and source_available_time;
• source_revision;
• staleness_ms; and
• a status: exact, carried, stale, no_history, or not_yet_available.

not_yet_available is a replay diagnostic. A live consumer sees only that no eligible available record exists; it cannot know from silence alone that a late event will arrive later.

Implementation outline

The Python and TypeScript versions use the same explicit procedure:

1. validate a mandatory nonnegative integer expiry;
2. validate all four clocks and request identity;
3. reject nonfinite values, impossible availability order, and inconsistent revision histories;
4. partition records by instrument;
5. apply event and availability cutoffs for each request;
6. select latest event and latest available revision; and
7. apply expiry without discarding rejected-source lineage.

The reference code prioritizes readability over asymptotic optimization. A streaming system can maintain indexes or monotone cursors, but changing the data structure must not change the two eligibility gates or the boundary rule.

• Python implementation
• TypeScript implementation
• Shared exact fixture

Explore the stale-versus-missing boundary

Open the interactive previous-tick lab. It starts with a complete synthetic preview, so the lesson is visible before the first click. Choose one of three 10-record scenarios:

• Steady stream: carries remain mostly fresh.
• Long gap: a legitimate source ages through the expiry boundary and turns missing.
• Late correction: an old event first arrives late and is then revised; neither version appears before its availability time.

Use Back and Step to move the query cutoff. Change the expiry to compare an old but still usable carry with an expired missing value. Play and Pause use the same deterministic transition as Step, and Reset restores the same informative starting state.

Tests that catch plausible-looking errors

The shared fixture and edge tests verify:

• a pre-first grid never backfills from a future event;
• an old event with a later availability time remains unavailable;
• a correction changes only later query vintages;
• age equal to the limit passes and the next millisecond expires;
• stale output is null but retains source lineage;
• exact event-time equality is classified correctly;
• impossible clocks, nonfinite values, duplicate revisions, and inconsistent revision order are rejected; and
• input observation order does not affect output.

Passing those checks proves implementation agreement with this contract. It does not prove that a chosen expiry is economically optimal or that any output predicts a return.

Gaps are observations, not explanations

A silent interval might reflect an illiquid instrument, a stable quote, a halt, a closed session, packet loss, or a delayed source. Carry-forward cannot identify the cause. It can only report its last eligible source and apply the declared expiry.

Do not automatically carry across a session boundary. The current official NYSE trading-hours calendar illustrates why holidays and early closes are venue rules rather than weekday assumptions. A production caller must partition or reset with the applicable venue and calendar version.

Corrections require versioned outputs

When revision 1 arrives, revision 0 remains the correct source for queries that predate revision 1's availability. Two operational patterns preserve this:

• store results by both grid and query vintage; or
• issue an explicit restatement that links the old output, new output, source revision, and algorithm version.

Overwriting history without a vintage erases the distinction between "happened then" and "became known later."

What the method can distort

Previous-tick panels can make asynchronous series look simultaneous. That convenience does not remove nonsynchronous-sampling effects. Hayashi and Yoshida's original covariance work addresses temporal overlap directly; it is not evidence that a carried rectangular panel is an unbiased covariance input.

The carry is also not a forecast, fair-value estimate, or proof of executability. A value can be legally selected under the data contract and still be operationally inappropriate for a trade, valuation, risk limit, or regulatory report.

Why the worked case is synthetic

A historical sparse quote sequence would be useful only if readers could trace its event and availability clocks and the source permitted redistribution. It would also need a documented venue, feed, session, quote side, and expiry rule.

This article deliberately does not present a licensed provider extract as public fact. Its examples are deterministic synthetic records that teach the mechanics without implying a historical market claim. A real-world case remains a medium-priority enhancement for a later evidence round.

Production checklist

• Pin venue, source, quote side, currency, scale, precision, calendar, and corporate-action policy.
• Store event time and first-usable availability time separately.
• Version corrections and downstream restatements.
• Require and monitor a finite expiry limit.
• Keep stale-source lineage even though the output value is missing.
• Reset or partition at authoritative session boundaries.
• Monitor rates of no_history, not_yet_available, and stale by source.
• Re-run cross-language parity after every contract change.
• Treat synthetic examples as mechanics validation, not market evidence.

Summary and next topic

Previous-tick carry-forward is causal only under two cutoffs: event time must not exceed the grid, and availability time must not exceed the query cutoff. The selected source then has to pass an explicit expiry clock. Pre-history, late knowledge, and stale history stay missing for different, visible reasons.

Continue with Linear Quote Interpolation, where the future right endpoint makes retrospective knowledge even more explicit.

Primary references and visual asset map

Source roles and limitations are recorded in REFERENCES.md. The timestamp representation follows RFC 3339; nonsynchronous-sampling context comes from the original Hayashi-Yoshida paper; and venue sessions must use an authoritative calendar. The four-clock contract, status names, revision rules, and mandatory expiry are this package's declared implementation choices.