explain_provenance

com.twmarketdata/tw-market-data · Verify this server

Where did this number come from, and when could anyone have known it? (WP-6) ★ THIS IS THE GROUNDING TOOL. Every other tool's answer is supposed to be expandable through this one: given a ticker, a field and a date, it names the dataset that serves that field, the knowledge column, and WHICH as_of rule applies on that date. Use it whenever you are about to state a number as fact. ★ IT DOES NOT OVERLAP WITH THE OTHER TWO PROVENANCE TOOLS, and they are not substitutes: `get_inclusion_proof(dataset, row_key)` proves a ROW was in a published snapshot (Merkle). `cite_this(dataset, as_of)` produces a citation for a DATASET. `explain_provenance(ticker, field, date)` answers WHERE A CELL came from and WHEN it was knowable. Nothing else answered that. ★ FOUR VERDICTS, and `partial` is not `resolved`: resolved dataset, knowledge axis, as_of rule AND the official endpoint. partial ⚠️ the first three, but NOT the official endpoint — no dataset declares a per-cell endpoint today. "When was it knowable" and "which official endpoint produced it" are different questions; conflating them is exactly the vagueness this tool exists to remove. ambiguous_field ⚠️ the field lives in several datasets. Every candidate is listed and NONE is picked for you: picking one would hand you a confident wrong answer. Re-ask with `dataset=`. unknown_field no served dataset declares that field. This is "we do not have that column", NOT "no data found" — a different next step for you. ★ READ `limitations`. It says when the knowability date is DERIVED (statutory deadline, a conservative upper bound) rather than observed, and whether the rule came from declarations or from the live schema. A declared capability is not the same as a working one. Args: ticker: the security, e.g. '2330'. field: the column you are about to quote, e.g. 'close', 'revenue'. date: the date your claim is about (YYYY-MM-DD). dataset: pin the answer to one dataset when the field is ambiguous.