Data gaps
When an agent reaches for data that does not exist — a discontinued statistics table, a source never wired in, an enrichment that silently comes back empty — it logs a public gap here instead of the failure just disappearing. The register is public and updates as gaps are discovered and closed.
This is not a promise that everything eventually gets fixed. It is an honest list of what the evidence base is missing right now, and exactly which findings and predictions that blocks.
Now
Know the dataset, table, or API that is missing below? Send us a source pointer through the feedback button or the questions channel on the Participate page — no account, no form.
Where Norway’s freedom-of-information act (offentleglova) applies, you can file the request right away — via einnsyn.no or directly to the authority — and publish the answer yourself or share it with us. See the Participate page for how access requests work in Norway.
Later
Submitting the closed gap — evidence and all — straight into the arena, with shared credit and standing (spec 6.1: a closed gap earns a flat, direction-neutral standing bonus), waits on a named controller under GDPR article 13 — the contact address (kontakt@folkefakta.no) is already published. Until then we read what you send us manually, through the feedback button.
The register
Open gaps sort to the top. Every entry carries a source reference you can check yourself — the file, the line, or the query that proves the gap is real.
What is missing
financial_impact_nok (a free-text column on ai_labels, set by the AI analyzer) is filled in for 290 of 2972 cases (2026-08-08), but only 182 of those — 6.1% of all cases — contain an actual numeric amount. The rest are qualitative phrasings like "Not specified in the case documents", "Under 100 million" or "Estimated several billion kroner", which cannot be summed or compared programmatically.
Why it matters
Any finding or comparison that needs to sum or rank the financial impact of cases — for instance "these ten cases cost the most" or a cross-case spending trail — has real numeric grounding for fewer than 1 in 15 cases. For most of the remainder the problem is not only our own extraction: the source document (the proposition) often states no concrete amount at all.
Blocks
Point us to a structured public source for per-case or per-proposal cost estimates — for instance the ministries' economic-consequence assessments in the proposition text, or the state budget's key-figures appendix — or help us identify which of the 290 cases with a free-text value actually contain a numeric amount our own extraction missed.
Take part
Send us a source pointer, or file the access request yourself and share the answer. Submitting the closed gap straight into the arena opens once a named responsible editor is appointed.
Source — check it yourself
SELECT count(*) FROM ai_labels WHERE content_type='sak' AND financial_impact_nok IS NOT NULL (290 of 2412 ai_labels rows, 2972 total cases); of those 290, 182 match a numeric-amount pattern (/\d{4,}|\d+[ .,]*(mill|milliard|kr)/i) = 182/2972 = 6.1% of all cases
What is missing
TOPIC_TO_INDICATOR_PREFIXES in scripts/pipeline/lib/enrichment-runner.js (lines 44-51) and the near-identical TOPIC_TO_INDICATORS in scripts/pipeline/match-evidence.js (lines 41-47) query outcome_indicators for four prefix families — fhi_ (health), nav_aap (labor), students_ (education), kostra_elder and kostra_kindergarten (elderly/childcare) — but no service ever writes rows with these codes. A database query (2026-08-08) confirms outcome_indicators holds only three distinct indicator_code values at all: nav_disability, nav_sick_leave and nav_unemployment. FHI data is in fact fetched by scripts/pipeline/enrich-outcomes.js, but stored somewhere entirely different — ai_labels.extended.fhi_data per case (88 cases had this as of 2026-08-08) — never as outcome_indicators rows with an fhi_ prefix.
Why it matters
Any lookup for health-, labor-, education-, elderly- or childcare-related outcome indicators through these four prefixes silently returns empty, with no error — exactly the pattern spec section 6.1 names: "Silent empty results in enrichment code are converted into gap entries." It weakens two independent code paths at once: fetchIndicators() in enrichment-runner.js (the evidence pack handed to the analyzer for every case) and match-evidence.js's candidate generation for promise_evidence — both always come back empty for these four sectors, no matter how many cases or promises are processed.
Blocks
Point us to the concrete FHI, NAV or SSB/KOSTRA datasets these prefixes were meant to represent (fhi_: FHI public-health norm figures/municipal health profiles; nav_aap: NAV's statistics on work-assessment allowance; students_: SSB's student/pupil counts as a running time series; kostra_elder / kostra_kindergarten: KOSTRA key figures for elder care and kindergartens) — or write an enrichment service that actually writes these codes into outcome_indicators, following the pattern in services/nav-sync/index.js.
Source — check it yourself
scripts/pipeline/lib/enrichment-runner.js lines 44-51; scripts/pipeline/match-evidence.js lines 41-47; SELECT DISTINCT indicator_code FROM outcome_indicators (returns only nav_disability, nav_sick_leave, nav_unemployment); SELECT count(*) FROM ai_labels WHERE content_type='sak' AND extended->'fhi_data' IS NOT NULL (88 rows, 2026-08-08)
What is missing
scripts/pipeline/lib/ssb-mappings.js removed its municipal-economy mapping (SSB table 12362, "net operating result") on 2026-04-08: the table turned out to be wrong (detailed municipal expenditure by function, not a single aggregate) and the query also used the wrong variable codes. The replacement candidates 12367 and 11816 are named in the source comment but never verified or wired in. Cases tagged with municipal economy get no automatic SSB context sentence at all.
Why it matters
Cases about municipal finances, property tax, municipal mergers and similar get no SSB-anchored cost context in the analysis, unlike almost every other economic topic mapped in the same file (state budget, GDP, wages and CPI are all mapped and working). Both case pages and future findings lack a municipal-economy reference point exactly where most other economic topics have one.
Blocks
Confirm the correct SSB table ID and PxWeb variable codes for municipalities' net operating result (candidates 12367 and 11816 are named but unverified, in scripts/pipeline/lib/ssb-mappings.js lines 378-384) — test the query against data.ssb.no/api/v0/no/table/<id> and report back which table actually returns the right aggregate.
Source — check it yourself
scripts/pipeline/lib/ssb-mappings.js lines 378-384 (comment block: "NOTE 2026-04-08: table 12362 was the WRONG table ... No replacement for now")
What is missing
SSB's table 10540 ("Registered fully unemployed") was discontinued in November 2020. outcome_indicators therefore holds only two data points for indicator_code nav_unemployment: one row from table 10540 at period 2020-11 (frozen since discontinuation), and one fresh row from the AKU successor table 13760 at period 2026-06, fetched 2026-08-07 when services/nav-sync/index.js was rewritten to use the successor series. Between December 2020 and May 2026 there is no monthly series at all, and the two rows do not even measure the same thing: 10540 was NAV's administrative registration count, 13760 is the AKU labour-force-survey unemployment rate — two different definitions under one indicator_code, with no documented break point in the data itself.
Why it matters
Any finding or prediction meant to show unemployment over time — for instance to test a 2021 party promise to cut unemployment — has no data for the entire 2021-2025 period. The new AKU series closes ongoing tracking from June 2026 onward, but does not bridge the history, and changes definitions mid-series.
Blocks
Point us to NAV's own open statistics for registered fully unemployed (NAV took over publishing this series when SSB discontinued table 10540 in 2020), with a link to the right dataset or API, or to a complete monthly AKU series back to 2021 from SSB — so we can build a real historical backfill instead of the two isolated points that exist today.
Source — check it yourself
SELECT indicator_code, period_start, metadata->>'ssb_table' FROM outcome_indicators WHERE indicator_code = 'nav_unemployment' ORDER BY period_start; services/nav-sync/index.js lines 24-42 (INDICATORS[0] comment)