Our September 11, 2026 technical note described a conflict between a local dividend cache and a company's annual filing. The cache contained eight records under LSI for 2011 and 2012. The company we were investigating was LSI Corporation, the semiconductor business. Its filing said it had paid no cash dividends in those years.
The audit rejected those records for the LSI calculation. It produced no return index from them.
This post explains that decision. It revisits the published investigation, rather than reporting a new experiment or a later resolution of the mismatch.
The conflict came before the calculation
A cash dividend is a payment to shareholders. If a return calculation includes dividends, each payment needs to belong to the security being measured. A mathematically correct calculation can still be wrong if it starts with another security's events.
The public source in this case was LSI Corporation's 2013 annual filing, Note 5. It states:
No cash dividend was paid in 2012 or 2011.
The saved records conflicted with that statement. A matching ticker did not resolve the disagreement. The question was whether those events belonged to this company and security during the dates being studied.
The published note also described a comparison with previously retained rejected records. The bytes matched. That established that the audit was looking at the same inputs; it did not make those inputs financially correct.
Why the audit stopped
The investigation did not establish where the records came from. The problem could have occurred during retrieval, symbol matching, local storage, or another stage. Ticker reuse was a possible explanation in general, but the audit did not prove it caused this mismatch. It did not identify another issuer as the source either.
Assigning the records to another company would have required evidence we did not have in that investigation. Silently substituting zero-valued events would also have concealed the fact that the audit had not constructed and validated a replacement history.
The recorded outcome was a rejection of the affected calculation. The note reports that the audit left the original cache unchanged, preserving the inputs for further investigation. There was no corrected return series or measured improvement in strategy performance to report.
A check to make before trusting a backtest
For someone building a historical return calculation, this case suggests a useful starting question: what evidence connects each event to the security being tested?
Keep the source identifier and the date range of the mapping. Check conflicting records against evidence about the issuer. Preserve enough information to explain why an input was accepted or rejected. When the conflict remains unresolved, make the affected result unavailable instead of letting it appear to be verified.
This was a bounded case. It did not measure an error rate for the data provider or establish that the rest of the cache was correct. Its lesson concerns the order of the work: establish which security an event belongs to before calculating what that event did to returns.
The technical note explains the identity requirements in more detail. Its public evidence summary records the historical audit outcome. The underlying vendor records and private audit files are not public, so those links do not provide a complete reproduction package.
This commentary was checked against the published note, its surviving review receipt, the public summary, and the linked filing. The original audit files were not available for a new inspection. AI tools assisted with drafting and editorial review. This article adds no new backtest or research execution.