Rerun affected stock screens after an earnings release
After a company releases earnings, update its reviewed financial fields and rerun the conditions that depend on those fields. Keep other companies and unaffected conditions unchanged. The result should show which release was accepted, which fields changed, which rules actually executed, and whether membership in the candidate list changed. A calendar entry saying earnings are expected today is not evidence that results have been published.
This guide supplies a local event-processing function with synthetic annual earnings data. It does not monitor an exchange, extract arbitrary filings, start Vibe scheduling or invoke a model. The example demonstrates how a reviewed release could drive a focused update. CoTrading’s ability to collect announcements, verify figures or maintain a live screen is not assumed.
Separate a release event from an earnings-calendar reminder
Obtain the actual formal release from the issuer or an authorized disclosure source. Record company identifier, event identifier, publication time, source reference, fiscal period and whether a person or separate process has verified the mapped figures. An expected release date can prompt a check, but it cannot supply a publication timestamp or authorize replacing financial values. Preserve the difference in the event schema.
The SEC’s EDGAR API documentation describes submissions information updated as filings are disseminated. It illustrates why an actual dissemination record differs from a planned calendar date. Our fictional example makes no SEC request and does not use EDGAR as an A-share announcement source. A real A-share workflow needs a separate suitable official disclosure adapter and a verified field mapping.
In the fixture, the event is official_release, verified is the boolean true, and release time is 2026-10-26 at 15:30 UTC+08. The decision time is 16:00 that day. The accepted fields refer to fiscal-year 2026 annual diluted EPS and compatible annual growth, in CNY conventions. This fictional company’s year is already complete; the example does not substitute nine-month EPS into a full-year valuation rule.
Write the dependency map before accepting events
The existing screen has three named conditions. Valuation depends on price and EPS and requires price divided by positive EPS below 20. Growth depends on the annual growth field and requires at least 10%. Liquidity depends on turnover and requires at least 2 in the supplied convention. The map is explicit, so changed fields identify the affected rules mechanically.
Do not infer dependency from the wording of an AI answer. The rule evaluator needs named fields, units and supported operations. If a new rule uses industry rank, peer-group changes may invalidate several companies even when only one company’s raw field changes. Such dependencies need a broader map. The small fixture uses company-local rules only, making a local update valid within its stated scope.
The old accepted snapshot contains AAA at price 18, EPS 1, growth 8% and turnover 3. Its valuation and liquidity pass, but growth fails. BBB has price 16, EPS 1, growth 15% and turnover 3; it passes all conditions. The initial selected list is therefore BBB. These are supplied screen observations, with the earnings period fixed by the screen contract rather than inferred from report labels.
Validate and stage the company update
Reject events that are planned, unverified, dated in the future, mapped to a different fiscal year, currency or dilution basis, or missing a source identifier. Python datetime supports the timezone-aware availability comparison. A string reading "true" is not accepted in place of the actual boolean verification flag. That prevents an accidental text conversion from bypassing this narrow input gate.
The event may update only EPS and growth in this example. Validate every supplied number before deduplication or mutation. Python Decimal can represent infinities and NaN, so the evaluator rejects nonfinite values explicitly. Valuation also requires positive price and EPS. For a loss-making observation, a real workflow needs a declared ineligible or unknown policy rather than letting a negative ratio pass a low-PE rule.
Build a candidate company row and candidate rule results first. Only after all affected calculations pass does the object replace its stored row, update the stored conditions and record the event as consumed. A failure leaves the previous rows, rule results and deduplication state unchanged. This local staging prevents an invalid earnings field from changing half the screen while the function reports a failed attempt.
Execute only the two affected conditions
The verified AAA release updates EPS to 1.2 and growth to 12%. Price remains 18 and turnover remains 3. The new valuation ratio is 15, and growth now passes. Because the changed fields are EPS and growth, the dependency map selects valuation and growth only. Liquidity is reused; BBB’s data and results remain untouched.
The actual call list is AAA:growth, AAA:valuation, in the script’s deterministic sorted order. The accepted list becomes AAA and BBB. The program asserts the call list and compares a deep copy of BBB’s previous data and condition results with the post-update state. This checks the promised limited scope directly, rather than merely inspecting the final list, which could look correct even after unnecessary recomputation.
affected = sorted(
name for name, fields in DEPENDENCIES.items()
if fields & set(event["fields"])
)Download the complete example. It uses Python 3.12+, the standard library and synthetic data. Run python R551.py to reproduce the update, actual calls, unchanged BBB row, duplicate result and blocked events. No listener, scheduler, message sender or trading connection is created.
Distinguish a duplicate from a conflicting revision
Use the pair of company and event identifier as the deduplication key. The same identifier can legitimately occur in separate company namespaces. Store a canonical representation of the reviewed event content with the key. Repeating exactly the same AAA event returns duplicate_suppressed with no rule calls. A same-key event carrying a different EPS raises conflicting_event_id; it does not silently overwrite the accepted release.
An issuer correction may be legitimate, but needs a distinct reviewed correction identity or an explicit version policy. The example refuses to infer revision order from arrival order. Without that policy, a delayed stale payload could undo a newer accepted result. Keep the conflicting evidence for review and avoid consuming the event until it is valid for the intended update.
The demonstration retains deduplication state only inside one process. Concurrent workers and restarts need durable coordination that is outside this file. It is therefore a local event-handling method, not a claim of exactly-once distributed processing. Describe that boundary when transferring the design to an automation system.
Test events that must not update the screen
A scheduled_release event fails before any financial mutation, even if it contains plausible numbers. A publication timestamp on October 27 also fails at the October 26 decision time. A conflicting duplicate and a textual verification flag fail for different reasons. The script snapshots the complete local state before each invalid attempt and asserts that the state remains unchanged afterward.
These counterexamples test event eligibility rather than arithmetic. The finite-value tests add another mechanism: a formally shaped event with invalid numeric content is still rejected. Keeping separate reasons helps route the problem to the correct source. A calendar error needs release confirmation, a numeric error needs field review, and a genuine correction needs a version decision.
Preserve the update record and define wider invalidation
Retain source event, accepted fields, prior values, affected conditions, actual calls and old versus new membership. When prices later change, invalidate valuation through its price dependency; an earnings event should not pretend it also refreshed the price. When a rule or accounting basis changes, reconsider all rows affected by that contract, not only the company in the latest event. The dependency map makes these consequences reviewable before automation is enabled.
FAQ
Can an estimated earnings date trigger the financial update?
It can trigger a check for publication, but cannot stand in for a verified release and reviewed figures.
Should every stock be recalculated after one release?
Only if its rule dependencies require it. This fixture uses company-local conditions and tests that BBB remains untouched.