Resume stock research from verified data steps
An interrupted research task should resume from the last data step that is still valid for the current question. Save source values, their scope and availability, step outcomes and attempt counts. On recovery, validate the saved inputs against the requested date and valuation contract before reusing them. Reexecute failed or invalid steps and recalculate dependent outputs only when all prerequisites are acceptable.
This guide implements an offline price-to-EPS-to-PE workflow with a JSON checkpoint. It uses synthetic inputs, a supplied forecast year and in-memory source adapters. It does not recover a Vibe session, run a model, restart a real scheduled service or demonstrate CoTrading persistence. Serialization and reloading are executed locally to show that the method does not depend on unrecorded conversational memory.
Define the contract that makes a checkpoint reusable
The first task, T1, concerns AAA, FY2027 diluted EPS, CNY, price date 2026-10-26 and decision time 16:00 UTC+08 on that date. The checkpoint key is a digest of this complete contract. Changing the price date or decision time creates a new task version. A company symbol alone cannot identify a completed valuation because the same company can have many valid valuations for different dates and assumptions.
For each accepted step, save value, company, currency, source identifier, availability timestamp and expiry timestamp. The price step also needs its price date. The forecast step needs its target year and EPS basis. The example’s same-day expiry policy is an intentionally strict fixture rule. In real research, choose freshness limits by field and source; an arbitrary universal expiry would neither establish financial relevance nor match every supplier’s delivery schedule.
Python datetime supports comparisons of aware timestamps. Require availability no later than the decision and expiry no earlier than the decision. Price date must match the requested session, and EPS must match the requested year and dilution convention. A new decision contract should not inherit validity simply because an old value remains present in a cache.
Persist the state needed to explain an interruption
Our checkpoint contains a cache, separate run records and a list of completion identifiers. Each run records its contract, accepted steps, per-step attempts and status. T1 begins after price 24 has been accepted but the first EPS attempt has failed. The price attempt count is one, the EPS attempt count is one, and no PE exists. Serialize the checkpoint with JSON and load it again before resuming.
Python JSON documentation describes this interchange format. Store financial values as strings so decimal interpretation is explicit after loading. The example performs a real encode/decode round trip; it does not implement disk durability, atomic file replacement or crash recovery across a write. A live system needs those additional storage guarantees without changing the validity rules described here.
Finite positive numeric values are required for the supported PE method. Python Decimal supplies arithmetic, with an additional explicit check for NaN and infinities. Invalid values are not reusable accepted steps. Keep rejected payloads in diagnostics if needed, while leaving the accepted numerical cache free of values that cannot support a calculation.
Resume T1 without fetching its valid price again
The recovery function checks the saved price against T1 and reuses it. The EPS source is invoked for the second permitted attempt and returns 1.2. The method calculates 24 / 1.2 = 20 and records completion. Its trace is reuse:price, fetch:eps, calculate:pe-v1. The program also records actual provider calls and asserts that EPS alone was requested during this recovery.
The final record stores a dependency digest covering the accepted step payloads and formula version. Python hashlib provides SHA-256 used to fingerprint that content. A digest can identify changed checkpoint content; it does not authenticate the original data source. Source verification and storage trust remain separate responsibilities, especially when files can be edited outside the recovery code.
if valid(saved_row, kind, contract):
record["steps"][kind] = copy.deepcopy(saved_row)
else:
# Fetch only while the step's attempt budget remains available.
passDownload the complete example. Use Python 3.12+, the standard library and synthetic data, then run python R554.py. The file includes the complete state machine, validation, source fixtures, dependency digest, attempt limits and assertions. No external state or network connection is required.
Make repeated recovery idempotent for a completed contract
Resume T1 again. Before returning a reused completion, the script validates saved dependencies, compares their digest with the recorded digest and checks the stored PE against its inputs. It then returns complete_reused, no step calls and no new completion identifier. A repeat request should not create an additional output or overwrite a completed record simply because the caller retried after losing a response.
The example also changes a saved completed price to 99 without updating the dependency record. Recovery returns checkpoint_invalid, with no accepted PE. This is a local consistency check, not a cryptographic provenance system. An operator should review a malformed or changed checkpoint instead of allowing the completion label to bypass the data checks.
Reject the new-price and expired-EPS combination
T2 uses October 27 with a new decision time. The prior October 26 price no longer satisfies the requested price date, so the source returns a new price of 30. The cached EPS of 1.2 expired at the end of October 26 under the fixture policy. It cannot be reused for T2. The new EPS request deliberately times out, so T2 remains partial with no PE.
The function must not calculate 30 divided by the expired 1.2 and return 25. That would combine a new price with a forecast observation that failed the declared contract. The trace is fetch:price, fetch:eps; the old EPS may remain in historical cache storage, but its presence is not an acceptance decision. Keeping historical data and authorizing its reuse are distinct operations.
On the next recovery, the valid October 27 price of 30 is reused. A corrected source returns new EPS 1.5 on the second EPS attempt, producing PE 20. T1’s completed record remains unchanged, and there are now two distinct completion identifiers. The result is a new dated valuation, not a silent correction to the earlier 24/1.2 calculation.
Bound retries and distinguish what failed
The maximum attempt count is two per step per contract. A copied failure scenario repeats the T2 EPS timeout, consumes the second attempt and then returns retry_budget_exhausted without another source call. The completed T1 run remains available, and T2 has no valuation. A budget prevents a persistent missing forecast from becoming an unbounded loop that produces neither a result nor a reviewable stopping condition.
Treat a timeout differently from a scope mismatch or a nonpositive EPS. Repeating a timeout may be reasonable within the budget; retrying an incompatible year without changing the source query will not solve the problem. A real workflow should route those reasons explicitly. This compact example uses the same attempt ceiling while preserving the reason returned by the failing step.
Hand off the recovery record and invalidate downstream work
The review package includes the contract, serialized checkpoint, accepted source payloads, validity policy, attempts, trace, formula version and completion identifier. A changed upstream input requires a new calculation from its accepted dependencies. A stored PE without a compatible dependency record should remain unavailable. Do not use a previous generated paragraph as the authoritative state of the data workflow.
For live storage or multiple workers, add durable writes, coordination and a reviewed publication policy. Those extensions must preserve the core invariants: valid inputs can be reused, failed prerequisites block dependent results, repeat completion does not multiply outputs, and separate date contracts preserve separate histories. A passing local script demonstrates these boundaries for the supplied fixtures, not a running end-to-end research service.
FAQ
Can the old EPS remain in the checkpoint after expiry?
Yes, as historical data. The recovery function must reject its reuse for a contract that it no longer satisfies.
Does a content hash establish that the forecast is genuine?
No. It detects inconsistency with the saved dependency content; source verification requires separate evidence.