What is AI here, what isn't, and what we won't show you.

Our content is AI-generated. Here is exactly what that means.

Forum Atlas is an industry-intelligence platform covering 12 commercial sectors. Its briefs and forecasts are generated by AI systems — a multi-agent ensemble that retrieves source documents, synthesizes analysis, and validates every claim. They are not written by human analysts. We disclose this plainly and in machine-readable form because you deserve to know, and because the EU AI Act (Article 50, applicable from August 2, 2026) requires providers to disclose AI-generated text published to inform the public. Two things are not AI-generated: the underlying source documents (third-party publications we cite verbatim) and the outcome data used to score forecasts.

Every analytical claim in a brief carries a citation you can audit — a verbatim extract from a named source document, with its URL and publication date. If the machine can't prove a sentence against a source, the sentence does not ship.

Validation fails closed — and it does fail.

After synthesis, a separate validator model checks every claim against the retrieved source text. A claim that can't be matched to a verbatim substring fails. A brief that fails validation is withheld from validated presentation: it renders as “insufficient evidence,” never as confident analysis. We publish the failure rate because a validation gate that never fails is not a gate.

Live counts from our public showcase workspace — the same workspace behind the accuracy scoreboard. Full pipeline detail: methodology · citation discipline.

The corpus number, split honestly.

One headline document count would flatter us, so here are two. The curated intelligence corpus is what analysts would recognize as coverage: sector-scoped feeds — government, corporate disclosure, trade press, academic and more — chosen source by source. The bulk reference corpora are catalogues we mirror wholesale for lookup and enrichment rather than read as signal: vulnerability and exploit registries (CVE, NVD, OSV, Exploit-DB, CISA KEV, EPSS), regulatory filing archives (SEC EDGAR), and machine-readable reference catalogues — package registries, model catalogues, satellite element sets, network, vehicle and charging-station directories. They are records, not signals — our own desk feed excludes them — and counting them as “intelligence coverage” would be misleading. There is no judgement call in the split: a source is bulk when it is flagged bulk_reference in our source catalogue, and the complete list of those sources is printed below.

Bulk reference breakdown — all 20 bulk sources, largest first: OSV.dev 182,399 · MITRE CVE 110,429 · Exploit-DB 46,679 · NIST NVD (weekly lane) 24,724 · NIST NVD (real-time lane) 17,320 · SEC EDGAR 14,799 · VulDB Recent 9,745 · crates.io API 6,494 · Open Charge Map 5,345 · Artifact Hub Helm 3,355 · MITRE CVE Program (cvelistV5) 3,285 · Hex.pm Elixir Erlang 2,545 · Hugging Face Trending Models 2,320 · CISA KEV JSON API 1,622 · PeeringDB API 1,325 · Epoch AI Models DB 1,035 · CelesTrak GP API 982 · Allego 737 · FIRST EPSS 43 · NHTSA vPIC API 26. Those 20 sum to 435,209, the bulk reference figure above — the list is complete, not a top slice. The two NIST NVD lanes ingest the same upstream registry on different cadences; both are counted here.

Counted at September 16, 2026 at 01:15 UTC by the production database rollup that produced these three figures, refreshed every 15 minutes. That is the rollup's own timestamp, not this page's render time.

The source number, split the same way.

Sources tracked is our catalogue: every live feed we have identified, wired, and monitor — the size of the collection apparatus. Sources producing is the subset that has actually delivered at least one document into the corpus — the honest capacity figure. The gap is real and we publish it: it is mostly feeds that are catalogued and scheduled but have not yet yielded a document, plus a small deliberately dormant reserve (paywalled and login-gated feeds we have chosen not to access yet) and a handful retired in place.

Breakdown of the non-producing remainder: 7,854 catalogued but no document yet · 678 deliberately dormant (access-gated or no ingest lane) · 24 retired in place · 300 hold no live document today · 0 in a lifecycle state this page does not name. Those five and the producing figure sum to the catalogue exactly. Counted by the same 15-minute database rollup as the corpus figures above, and carrying its timestamp.

The figure above is derived from the definition beside it. Our internal lifecycle column — the one every alarm we run reads — is a second, disagreeing measurement, and we publish it rather than substitute it: it marks 8,618 sources with a producing status, of which 300 hold no live document today, while 4 sources it marks otherwise do hold one. The column is moved by a one-way trigger that lights a source on its first document and never darkens it again, so it runs ahead of the corpus rather than with it.

Forecast accountability: the scoreboard is empty, and that's the point.

Every forecast is timestamped and immutable at generation. A forecast is scored only if it was bound, at issue, to a named public series and an explicit threshold that can settle it; the resolver then records what that series shows and publishes the Brier score, win or lose. Forecasts issued without such a binding are counted on the record but can never be scored, and /accuracy says how many of each there are. As of this page render, 173 forecasts are on the record and 11 have resolved. We could hide the empty column until the numbers look good. Instead the scoreboard is public from day one — an honest empty scoreboard beats a fake one. Nothing on this page is a claim that the forecasts are accurate; that is what the scoreboard is for.

The generation pipeline fails too, and we publish that as well: 224 forecast runs attempted, 51 failed to generate — a 22.8% generation-failure rate. A run that never produced a forecast is not on the record above — the 173 figure is the completed cohort, and this line is what it was drawn from.

We also run a shadow book against open prediction markets: each of those forecasts is sealed as a SHA-256 commitment before the market settles and revealed afterward, so outsiders can verify we never edited a call. The public commit–reveal ledger — every sealed commitment, and every reveal as settlements land — lives at /ledger (machine-readable: /ledger.json).

Watch it fill in at /accuracy.

When we get it wrong.

• Written severity ladder. Production incidents are classified SEV-1 (site down, data breach, corpus-wide corruption) through SEV-4 (cosmetic), with response targets per level. When in doubt, we classify higher — and re-litigate in the postmortem, never during the incident.
• Detection is automated. Public golden paths are probed every 30 minutes; error monitoring is release-tagged; performance health gates are checked before heavy workloads re-enable.
• Blameless postmortems. SEV-1 incidents get a written postmortem within 48 hours, published in the repository at docs/atlas/postmortems/. Every postmortem must name at least one automated check against the failure — either a check that now exists and runs, or, where the check has to be built, exactly what it must measure and what must be true before it can. A gate derives the list of incidents this applies to from our own alarm labels and escalation severities, and fails when a postmortem is missing or names no check.
• Corrections fail closed. Citation rows are append-only — we don't silently rewrite published evidence. A brief that fails validation is withheld, not patched. Stale published statistics are treated as an incident class of their own: every count on this page is queried at generation and stamped with the time it was counted, and when a query is unavailable the page prints a dated floor labelled as one rather than an unmarked number of unknown age. We have shipped that failure — a corpus block that served July floors under a “queried live” header for a month, because the query silently exceeded its own time budget — and the fix was to make the query fit and to make the timestamp come from the data.
• Tell us. Found an error in a brief, a citation, or a number on this site? Contact us — corrections and data-subject requests both route to a human.

Machine-readable disclosures: /.well-known/ai-disclosure.json (site-level) and per-brief provenance manifests at /api/briefs/{id}/manifest.