lookahead-safetylisted

# Lookahead Safety The single most common bug in quant research with LLMs: using data that was not yet known at the moment you claim to have known it. This skill defines the rules to keep historical analysis honest. ## The core rule **The known-date is the date a piece of information was PUBLISHED, not the date the information is ABOUT.** - A 10-K covering fiscal year 2023 may be filed in March 2024. In January 2024, that 10-K **did not exist**. - An S-3 effective on 2024-04-15 was unknown on 2024-04-14. - An XBRL `SharesOutstanding` datapoint with `period_end: 2023-12-31` is known only after the filing that contains it is published. When asked to compute or recommend anything `as of` a date `D`, only data where `filing_date <= D` is admissible. ## Field-by-field reference for SEC data | Field | Use as known-date? | Notes | |-------|---------------------|-------| | `filing_date` / `acceptedDate` | ✅ YES | The publication moment | | `period_end` / `periodOfReport` | ❌ NEVER | The accounting period the data covers | | `effectiveDate` (S-3, etc.) | ✅ YES | When the registration becomes usable | | `reportDate` on XBRL facts | ❌ NO | Period covered, not publication | | `accepted` timestamp | ✅ YES | Most precise — use when intra-day matters | ## Common traps 1. **The XBRL trap.** `companyfacts.json` returns datapoints keyed by `period_end`. Naively iterating these as a time series leaks future information — the datapoint with `period_end: 2023-12-31` was first