Corpus Coverage

What these numbers are, and are not

A count of the corpus is not a claim about the corpus. The honesty statements below travel with the data itself, in boundary-statements.json, and are quoted here word for word rather than summarised:

So read the figures as a corpus inventory. They say how many deployments the record covers and how heavily each one is cited. They do not say that any parameter was measured in the field, that a simulation was fitted to a deployment, or that a governance choice was shown to work somewhere. Where the bundle cannot support a figure this dashboard would otherwise show, the figure is left out and named at the bottom of the page.

What the snapshot carries

Each collection, counted from the file itself rather than read off the sync record. The sync record states its own counts too, and audit:pan-coverage compares the two on every run, so a partial sync cannot pass unnoticed.

• orgs145
• domains24
• caps5
• lever_direction_orderings145
• simulation_findings3
• boundary_statements4

Deployments by sector

Sector tokens are upstream's own, shown unedited. The counts sum to 160 rather than 145 because 15 deployments sit in more than one sector; the order is by count, so the long tail is the corpus as it actually stands, not a selection.

• public_benefits42
• caseworker_copilot20
• child_welfare20
• housing12
• behavioral_health11
• content_moderation5
• industrial_qa5
• clinical_decision_support4
• contact_centres4
• criminal_legal4
• environmental_climate4
• security_fraud4
• software_engineering4
• benefits_navigation3
• clinical_documentation3
• education3
• hiring_employment3
• lending_credit3
• housing_homelessness2
• logistics_scheduling2
• gerontology1
• public_facing_chat1

By organization size band

The size band each deployment's host organization carries in the bundle.

• large66
• giant54
• medium21
• small4

Grounding citations by source tier

The org library carries 1,064 citations across 9 source tiers, resolving to 1,023 distinct reference keys and 1,037 distinct URLs. Per deployment the count runs from 1 to 33, with a median of 8; no deployment is carried without a citation.

• Government280
• Academic181
• Investigative165
• Trade press140
• Advocacy110
• Vendor98
• Reference47
• Government evaluation38
• news5

Domain grounding 109

The domain document cites its own sources, separately from the deployments.

• Peer-reviewed29
• Investigative23
• Advocacy20
• Government14
• Trade press13
• Regulatory5
• Industry3
• Data1
• Vendor1

Empirical ceilings 18

The caps document's citations, which is where the benchmark and detection-accuracy literature sits.

• Preprint9
• Peer-reviewed4
• Industry evaluation2
• Frontier lab1
• Industry1
• note1

The parameter surface, and how it is marked

The deployments carry 1,812 parameter-bearing entries between them — models, operator classes, memory stores and the pathways between them. Of those, 1,811 carry the estimated flag, 0 are marked as not estimated, and 1 carries no flag either way. 1,812 carry a source note saying what the value was drawn from.

That distribution is the honest headline of this page, and it points the other way from the counts above. A large, densely cited corpus of deployments is still, at the level of individual numbers, a corpus of authored modeling choices informed by those citations. The flag is the bundle's own marker for exactly that, and it is set on effectively the whole surface.

• models162
• users275
• stores192
• edges1,183

Domain grounding

Alongside the deployments, the snapshot carries 24 domain entries describing 95 documented uses of AI in those fields, plus 16candidate deployments named but not yet encoded. The status each use carries is the document's own: a withdrawn system is kept, not dropped, because a system that was pulled is part of the record.

• deployed66
• piloted15
• withdrawn13
• planned1

What this page does not show

4 figures a coverage dashboard should carry are missing, and each one is missing for the same kind of reason: the bundle does not export the field they would be counted from. They are named here rather than approximated, because an approximated provenance figure is worse than an absent one. The audit re-probes each gap on every run and fails the day the field arrives, so none of these can outlive its reason.

• Citation freshnessnot shown

  Because a citation in the bundle carries a reference string, a URL, a tier and a key. It carries no retrieval or publication date, so how recently the corpus was checked against its sources cannot be counted here.

  Needs, from PAN: a per-citation retrieval date on the bundle's source objects.

• A growth curvenot shown

  Because the snapshot is one dated export, not a series. Nothing in it records what the corpus held at an earlier sync, so growth over time cannot be drawn from it.

  Needs, from PAN: a retained series of per-sync counts, or a first-seen date per org, exported through the bundle.

• A provenance-ladder breakdownnot shown

  Because the bundle annotates a parameter with a free-text source note and the binary estimated flag counted above. It does not carry PAN's four-rung ladder, so a measured / calibrated / baseline / assumed split cannot be counted here.

  Needs, from PAN: a per-parameter ladder rung on the bundle's model, user, store and edge entries.

• Jurisdiction spreadnot shown

  Because jurisdiction is one prose sentence per org, written at whichever granularity the record supports — a country here, a county or a city there. Bucketing those strings would report an artifact of the parsing rather than a fact about the corpus.

  Needs, from PAN: a structured jurisdiction field alongside the prose one.

The growth gap, while it stands, is worth spelling out. A curve needs at least two dated counts, and this snapshot is one: reconstructing earlier points from commit history or from prose elsewhere in the repository would put a trend line on the page that the data behind it cannot answer for. So the page states the corpus at one pinned date, and says which date.