Recompute affected stock research after a financial correction
A financial data correction should invalidate every current stock research result that depends on the changed input before those results are displayed as current again. Trace the numerical dependencies, retain the earlier research version, and rerun only the affected calculations. A repaired source link or a new filing in a folder does not establish that an old screen or valuation was recalculated.
This guide executes a small dependency graph using invented companies and a deliberately simple valuation scenario. It does not detect corrections on the internet, edit a brokerage account or establish a CoTrading automation feature. The corrected value and its source identity must already have been checked. Historical research snapshots remain separate from the updated current view.
Admit a correction with enough identity
Record the issuer, metric, reporting period, unit, original input reference, corrected value, correction identity and supporting source. A new-period observation is not automatically a correction of an earlier period. If a company files a different accounting basis, a definition change may require a new model rather than a replacement number.
The event also states the old value it expects to replace. This protects against applying an amendment to a state that has already moved on. In the fixture, the event expects A’s revenue of 120 and replaces it with 105. A mismatching expected value should stop processing; guessing which prior version was intended can corrupt both the calculation and its audit trail.
Validate the new input before changing active state. The example requires a known input key, a source reference and a finite positive value for this narrowed revenue model. Decimal finite checks provide one numeric check, but do not verify a financial statement. The example does not implement every possible correction, such as a valid negative cash-flow observation in a different model.
Make the numerical dependencies explicit
Use a registry that connects each calculation to the inputs or earlier results it actually reads. The synthetic graph is:
| Result | Direct dependencies | Purpose |
|---|---|---|
| A_growth | A_revenue, A_prior | Revenue growth |
| A_screen | A_growth | Growth at least 10% |
| A_value | A_revenue, margin, discount | Stated cash-flow scenario |
| A_brief | A_screen, A_value | Combined research handoff |
| B_growth | B_revenue, B_prior | B’s growth |
| B_screen | B_growth | B’s screening state |
| B_value | B_revenue, margin, discount | B’s scenario value |
Our A and B inputs refer to the same declared period and currency unit. This is an explicit, small graph in a valid execution order. It is not an automatic dependency extractor for arbitrary notebooks. If a real worksheet also reads corrected revenue to estimate working capital, the registry must include that dependency or the recalculation will be incomplete.
Trace transitive dependencies, not only direct ones. A revenue correction directly affects growth and scenario value; it indirectly affects the screen and the combined brief. Searching for the old number in narrative text cannot reliably discover those relationships, because a calculation may depend on it without printing it.
Keep the valuation assumption separate from the reported fact
The original A revenue is 120 and prior-period revenue is 100. The growth screen therefore sees 20% and includes A. The scenario assumes a constant after-investment cash-flow margin of 10%, a discount rate of 10% and zero growth forever. Its value is revenue × 0.10 / 0.10, initially 120 in the same monetary scale as revenue.
That is a declared scenario, not an accounting identity. Reported revenue does not prove free cash flow equals 10% of revenue. An actual valuation would need supporting operating, tax, investment and working-capital assumptions. No share count is supplied here, so the scenario output is not a per-share price target.
After the verified correction to 105, growth is 5%, below the 10% screen, and the scenario value is 105. The arithmetic isolates the effect of this one input while holding the illustrative margin and discount assumption fixed. It does not measure the real share-price response to a correction or prove an investment conclusion.
Invalidate first, then run the affected queue
The script expands the dependency frontier until no new node is reached. It saves the prior outputs, changes the input version, and marks all four affected results pending with no current value. During this interval, read_current('A_screen') raises an error. An old pass result cannot remain visible as if it already used the corrected revenue.
The essential invalidation step is:
affected, frontier = set(), {changed_input}
while frontier:
newly = {node for node, deps in DEPS.items()
if node not in affected and set(deps) & frontier}
affected |= newly
frontier = newlyThe registry’s execution order then computes growth, screen, scenario value and brief. If a dependency is not current, the downstream result stays blocked. This is stronger than putting a warning next to an old number and continuing to feed it into a ranking or summary.
Preserve the historical version as an actual separate object. Python’s copy documentation explains the distinction relevant to copying nested state. In this fixture the saved history does not change when the active graph changes. This does not establish durable or tamper-resistant storage; production persistence needs its own transaction and access design.
Reproduce the candidate and value changes
Download the complete example, use Python 3.12 or later, and run python R559.py. Its standard-library assertions inspect real evaluated outputs, the invalidation interval and failure branches. The result is:
| Item | Before correction | After successful recomputation |
|---|---|---|
| A growth | 20% | 5% |
| A screen | Pass | Fail |
| A scenario value | 120 | 105 |
| Candidate list | AAA, BBB | BBB |
| B growth and value | About 11.1111%, 200 | Unchanged |
Exactly four A nodes enter the queue. The B results retain their values, states and versions; they are not recalculated. Assertions compare the preserved history with the original outputs and verify the concrete candidate lists. The evidence is a changed computation, not merely a changed document label.
The same correction replay returns an empty affected list and causes no further calculation. A repeated event with changed content is a conflict. This prevents a retry from masquerading as a second financial correction or silently reinterpreting an existing correction identity.
Retain a useful partial failure
The different-mechanism counterexample deliberately fails A_value after growth and screen succeed. The new screening result remains current and false. The valuation has no current value, and the combined brief is blocked_dependency. It must not fall back to the old 120 while presenting the new revenue and screen beside it as one coherent version.
An unaffected B result remains usable. The task need not discard all research merely because one affected calculation failed. However, the final handoff must separate current, pending, failed and dependency-blocked outputs. Resume the failed branch under the same corrected input version, preserving the failed attempt, rather than restoring the pre-correction snapshot as the latest result.
Accept the updated research view
Check the correction identity, expected old value and source first. Then reconstruct the affected closure, compare it with the queue actually executed, and inspect a deliberately unaffected result. Confirm the old snapshot is still retrievable and every current result references the new version where required.
Revisit the dependency registry when model logic changes. A new margin formula might depend on both companies, making a previously local change nonlocal. A method that records those edges honestly is useful even in a spreadsheet. Calling every edit a full rebuild hides the dependency problem; calling every edit local without checking it leaves stale results behind.
Compare the correction with an unchanged control
Keep BBB as a control while correcting AAA. Its growth, screen and scenario values should retain their original version and values. This distinguishes selective recomputation from rebuilding every record and merely obtaining similar numbers. Inspect the archived snapshot separately: updating the current view must not mutate the historical information set that an earlier decision used.
FAQ
Does replacing a source URL complete the recalculation?
No. Establish whether the underlying value changed, invalidate actual numerical dependents and verify their newly executed results.
Should all prior versions be rewritten after a correction?
No. Preserve historical snapshots with their original information sets. Update the current view under an explicit correction version.