Query date: 2026-07-27. Every number below came from a live run_sql /
describe_dataset / search_* call against FactIQ during this session, not
from the README or marketing copy. Where a query errored, the error is quoted
verbatim rather than smoothed over.
Form 4 (insider transactions): CONFIRMED ABSENT. Form 13F (institutional holdings): CONFIRMED ABSENT.
Evidence: SELECT form_type, COUNT(*) FROM filings GROUP BY form_type against
the sec schema's raw filings table returns exactly nine form types —
8-K, 10-Q, 10-K, 20-F, 40-F, 10-K/A, 10-Q/A, 20-F/A, 40-F/A — no 4, 3,
5, or 13F row anywhere. search_datasets for "Form 4", "insider",
"13F", and "institutional holdings" returns zero SEC-filing matches (the
"institutional holdings" query surfaces unrelated series — Treasury TIC
foreign holdings, IMF reserves — nothing resembling a 13F).
| Form | Companies | Filings | Earliest | Latest | Notes |
|---|---|---|---|---|---|
| 10-K | 1,126 | 11,411 | 1994-04-01 | 2026-07-24 | + 10-K/A: 329 companies, 584 filings |
| 10-Q | 1,132 | 34,058 | 1994-02-11 | 2026-07-24 | + 10-Q/A: 205 companies, 358 filings |
| 8-K | 1,131 | 43,322 | 2004-08-31 | 2026-07-24 | not a standalone dataset — feeds sec_guidance/sec_kpi only |
| 20-F | 215 | 3,024 | 1996-07-05 | 2026-07-20 | foreign issuers; + 20-F/A: 119 companies |
| 40-F | 58 | 890 | 2002-02-15 | 2026-06-22 | Canadian issuers; + 40-F/A: 35 companies |
Dataset-level ticker coverage: sec_10k/sec_10q ≈1,123–1,131 tickers,
sec_20f 195, sec_40f 51, sec_guidance 884 (sparse — only filings with a
concrete numeric target), sec_kpi 485 (only companies disclosing
physical/operational metrics).
Latency: near-real-time. Most recent 10-Q/8-K/10-K filings are dated 2026-07-24, three days before this survey.
Verdict: "SEC filings data" means XBRL financial-statement content from 10-K/10-Q/8-K/20-F/40-F families for ~950 large-cap (>$10B market cap) issuers. It does not cover insider transactions or institutional 13F holdings at all — anything built on those must use an external source.
| Schema | Series count | Coverage window | Update latency | Frequencies | Notable detail |
|---|---|---|---|---|---|
| BLS | 1,663,402 | 1913-01 → 2026-06 | ~1 month | annual, monthly, quarterly, semiannual, weekly (+ inconsistent casing) | Dataset-level last_release_date metadata (e.g. Oct 2025 for CPI) is stale relative to actual series data — trust series.end_time, not the metadata field. |
| Census | 4,949,249 | 1970-01 → 2026-06 | ~1 month schema-wide | annual, monthly, quarterly (+ dup casing) | 334 datasets, but us_census_hs alone is 4,944,079 series — 99.9% of the schema. |
Census — us_census_hs (HS trade) |
4,944,079 | 2013-01 → 2026-04 | ~3 months | monthly | Confirmed both HS6 and HS10 present via dimensions.hs_level; quantity (_qty) series exist only at 10-digit, per catalog docs. |
| BEA | 74,067 | 1901-01 → 2026-05 | ~2 months | Q, A, QNSA, QSA, monthly (+ text codes) | NIPA table alone: 8,204 series across 252 tables. |
| EIA | 1,172,069 | 1859-01 → 2050-01 (misleading) | Highly dataset-dependent | annual, daily, hourly, monthly, quarterly, weekly | The 2050 max comes entirely from ieo (Annual Energy Outlook projections), not real data. Actual sub-dataset lag: eba/nuc_status near-real-time (through 2026-07-27/28), ng/pet ~1 week, elec/total ~2 months, coal ~7 months, seds ~2.5 years, emiss ~5 years. |
| ERS (USDA) | 21,989 | 1996-01 → 2023-01 | ~3.5 years — stale | biannual only | Only one dataset in the whole schema (ers_arms). |
| BTS | 203,934 | 1947-01 → 2025-09 | ~10 months | Annual, Daily, Monthly, Quarterly, Weekly (+ dup casing) | 290 datasets, many under cryptic data.gov-style codes (e.g. navd-gpqa) — codes must be discovered via search_datasets, guessed codes like t100 404. |
| Schema | Series count | Coverage window | Frequency | Commodity granularity |
|---|---|---|---|---|
china (NBS macro) |
55,821 | 2000-01 → 2026-06 | quarter, year, month | n/a (macro indicators) |
china_customs (GACC) |
2,881,940 | 2015-01 → 2026-06 | Monthly | HS6 and HS8 confirmed via dimensions.hs_level |
mospi |
499,934 | 1950-01 → 2036-01* | annual, monthly, quarterly (mixed casing) | n/a |
rbi |
297,319 | 1900-01 → 2026-12 | 13 distinct frequency codes incl. daily, fortnightly, event, irregular | n/a |
india_trade (DGCI&S) |
720,650 | 2018-01 → 2026-05 | Monthly | HS6 and HS8 confirmed |
korea_trade (KCS) |
827,811 | 2015-01 → 2026-06 | Monthly only | HS6 (international) + HS10 (Korea national) |
* mospi's 2036 max is almost certainly forward-dated targets/projections embedded in the series, not actual future observations — flagged, not resolved, in this survey.
Korea 10-day / 20-day provisional export releases: CONFIRMED ABSENT.
search_series for "10-day", "20-day", "preliminary", "advance" all return
zero matches; "provisional" returns 14 matches but every one is a false
positive from HS commodity-description text ("cucumbers... provisionally
preserved"), not a release-timing series. SELECT DISTINCT frequency FROM
series for korea_trade returns only Monthly. describe_dataset's full
text makes no mention of dekad/10-day/20-day releases. FactIQ carries only
the final monthly KCS release — the early-read signal that makes Korea trade
useful as a global-cycle nowcast is not present.
Sampled DE, FR, IT, NL (large), EE, MT (small) — all confirmed non-trivial, not empty schema shells:
| Reporter | Series (≈) | Coverage window | Latency |
|---|---|---|---|
| DE | 5,634,765 | 2002-01 → 2026-05 | ~2 months |
| FR | 5,020,051 | 2002-01 → 2026-05 | ~2 months |
| IT | 4,615,711 | 2002-01 → 2026-05 | ~2 months |
| NL | 5,120,279 | 2002-01 → 2026-05 | ~2 months |
| EE | 1,370,370 | 2002-01 → 2026-05 | ~2 months |
| MT | 753,678 (exact count) | 2002-01 → 2026-05 | ~2 months |
CN8-level granularity is genuine — eu_comext_lookup.product_codes returns
populated hs2/hs4/hs6/cn8 columns, and constructed series ids return real
value/quantity/supplementary-unit data (spot-checked DE→FR, CN8 61091000:
292 months, 2002-01→2026-04, €3.10B cumulative / 134M kg / 748M units).
One documentation gap for anyone building series ids by hand: the
{trade_type} token in eu_comext_{M|X}_{reporter}_{partner}_{trade_type}_
p1_cn8_{code}_{eur|kg|su} is not literally M/X as the tool docs suggest —
it's te (extra-EU partner) or ti (intra-EU partner). Guessing te for an
intra-EU pair (e.g. DE→FR) silently returns zero rows.
| Signal | Present | Spatial granularity | Temporal granularity | Latency | Coverage |
|---|---|---|---|---|---|
| Fire detections | Yes | country / bbox / grid footprint | daily | ~3 hours (VIIRS) | global, 2012→present |
| NO2 / SO2 / CO / aerosol | Yes | country / state / bbox | daily or monthly | ~3 days | global, 2018→present (Sentinel-5P) |
| Rainfall (CHIRPS) | Yes, with a hard latency wall | country/bbox | daily | final product lags 3–6 weeks — confirmed live: a request through 2026-07-26 returned only data through 2026-06-30, with an explicit in-band note | 50°S–50°N, 1981→present |
| Nighttime lights | Yes (satellite schema) |
country and confirmed sub-national (31 China provinces individually resolvable) | monthly | ~3 months | Asia-focused (China, India, ASEAN, Korea, Japan, Taiwan) |
| Shipping / port activity | Yes (portwatch schema, 3 datasets) |
28 named chokepoints, 2,065 ports/180 countries, 196 countries | daily | days to ~1 week | global |
| Reservoir / lake levels | Yes, but incomplete for the intended use case | named water bodies only, no bbox/province query | ~10–27 day revisit (altimetry) | 1992→present, 94 countries | see below |
Yunnan reservoir check — partial. Dianchi (Kunming, Yunnan) is present
and returns real readings (35 points, 2026-07-12 = 1887.29m). But none of the
specific hydropower reservoirs that actually drive Yunnan's dry-season
aluminium-curtailment story — Xiaowan, Nuozhadu, Manwan, Dachaoshan,
Gongguoqiao, Jinghong, Wudongde, Baihetan, Ludila, Ahai — return any match.
The dataset has no province/state dimension, so there's no bbox fallback
either; it's a name-based lookup against whatever Hydroweb happens to track.
Conclusion: the Yunnan aluminium-curtailment lead indicator as originally
conceived (reservoir levels) is not buildable from this data as-is.
Nighttime lights (province-level, confirmed working) or NO2/SO2 near known
smelter sites are the closer available proxy — Domain A will need to be
scoped around that substitution, not around reservoir levels directly.
Update (2026-08-03): FactIQ's team, replying to the vintage questions below, independently flagged night lights, port activity, and fires as data they've "just released" — the same three signals this survey found and tested a day earlier. Treat this as confirmation these are intentional, current, supported products (not an edge case this survey happened to stumble on), which strengthens the case for using night lights as Domain A's primary industrial-activity proxy rather than a fallback.
search_earnings_transcripts(search_target='coverage') is paginated (50
tickers/call, alphabetical, no total-count field), but the first page (A–AMP)
alone shows 50 distinct tickers — density implies broad, S&P-500-scale
coverage rather than a narrow mega-cap slice. Depth varies by ticker: some
names carry only one quarter (AA, AAL: FY2026Q1 only), well-covered names
carry four (AAPL, ABBV, ABT, ADI, AMAT, AMD, AMGN: FY2025Q2/Q3 →
FY2026Q1/Q2) — i.e. roughly a rolling 4-quarter window for the names FactIQ
tracks most closely.
Latency is not uniform. AAPL's FY2026Q1 claims (calendar_date:
2026-01-29) line up almost exactly with Apple's real January earnings call.
But FY2026Q2 claims are dated 2026-07-02 — roughly two months after
Apple's real-world late-April/early-May call for that quarter. Same source,
same company, two very different lags. Treat per-quarter latency as
unverified until checked for the specific ticker/quarter a domain pipeline
depends on.
GLOBAL_QUOTE, TIME_SERIES_DAILY, FX_DAILY, and BRENT all returned a latest timestamp of 2026-07-27 — today, at the time of the survey. This reads as same-day/near-real-time, not multi-day-lagged; intraday latency (minutes vs. hours) wasn't verified since daily bars don't expose it. Covers equities, FX, and commodity futures (spot claims not separately verified).
LIMIT 200 against bls.data_points
returned "truncated": true, matched 200 rows, but the response text says
"Showing 50 of 200 rows" — confirms the documented 50-row ceiling holds
even when a query explicitly asks for more. Aggregate in SQL; don't try to
page through raw rows.429: Too many requests. Please wait a moment before asking another
question. errors; sequential retries after a short pause succeeded every
time, and a later 6-call rapid sequence hit no throttling at all. Treat it
as a short burst window, not a hard per-minute quota — the harvester
(Phase 3) should be sequential with backoff, per the original spec.relation "data_points" does not exist. But a valid query
against a nonexistent series_id value does not error — it silently
returns "row_count": 0 with no warning. This is a real trap for anything
downstream (the harvester, the vintage probe) that assumes an error means
"missing" and a 200-with-zero-rows means "confirmed zero" — they can mean
the same thing here. Every consumer of run_sql in this project must
explicitly check row_count rather than only catching exceptions.emiss is ~5 years stale
while eba/nuc_status are near-real-time; treating the schema as
uniformly fresh would be wrong.run_sql in this project, and worth raising directly with the FactIQ team
alongside the vintage question.Password required.