The Collection Pipeline

Every record in this dataset is produced by an automated pipeline that reads the public web. It begins with an institution drawn from the registry and works forward in steps, each one narrowing what the next step looks at. Nothing here is hand-collected, and nothing is inferred from an institution’s size, country, or type: a record exists only because a specific page was found, retrieved, and read.

1. Search the open web for the institution and for evidence of generative-AI activity.
2. Identify the institution’s official website from what that search returned.
3. Search again, restricted to that website, so the institution’s own domain is examined directly rather than only through whatever the open web surfaced.
4. Filter out clearly ineligible addresses: login pages, site maps, search-result pages, link shorteners and similar, which cannot carry evidence.
5. Decide which of the remaining pages are worth reading.
6. Retrieve those pages.
7. Extract structured claims from the retrieved text.
8. Consolidate and check the claims for one institution together.
9. Write the approved output into the published tables.

Steps 1, 3 and 4 are all part of the same discovery work, which is why the pipeline is usually described as having seven numbered stages even though there are nine steps: the discovery stage runs in three parts that are separated by other steps rather than following one another.

Not every run performs all nine steps, and this matters when reading a record. In its current default configuration a collection run stops after step 7 (extraction). Steps 8 and 9, consolidation and writing to the published tables, are run afterwards as separately invoked steps. A complete end-to-end run includes them, but the existence of extracted material for an institution does not by itself mean that institution has been through consolidation or has been written to the published tables. Where the distinction affects how a record should be read, it is recorded in the record’s own provenance rather than left to inference.

Large language models are used inside this pipeline, at four specific steps. We state this plainly rather than leave a reader to discover it: a reader who finds it out for themselves is entitled to read the omission as concealment.

The four model-mediated steps all use the same model and are constrained to return data in a fixed, machine-checked shape. That constraint governs the form of an answer, not its content: a response can be perfectly well-formed and still be a misreading of the page it describes.

The pipeline as a whole should not be described as reproducible, and we do not describe it that way. The rule-based steps are deterministic in a narrow sense (given identical inputs and settings they produce identical output), but their inputs are not stable. Web searches run against an index that changes without notice, and pages are edited, moved and withdrawn. The model-mediated steps add a further, different source of variation. Whether two runs of this pipeline over the same institutions produce the same records is a question we are actively working on and cannot yet answer; see Comparing runs and Validation below.

Discovery currently runs in English. In the configuration the pipeline ships with, the queries issued for every institution are English-language queries, whichever country the institution is in and whatever language it publishes in.

This is a limitation of the current production configuration, not a passing setting. Running discovery in another language is not presently available as an option: it requires a curated, separately approved set of search terms for that language, and adding one is a deliberate research decision rather than a configuration change. The codebase does contain a multilingual term list used by an earlier query strategy, but it is not what the current default configuration uses, and its presence does not make the pipeline’s production behaviour multilingual.

The consequence for a reader is direct and should be weighed before drawing any cross-country comparison. Evidence published only in a language other than English is systematically less likely to be found. Coverage is therefore uneven across countries in a way that reflects our search configuration rather than the underlying distribution of government AI activity. Extending discovery to other languages is active work, and this page will be updated when the production configuration changes.

A record can fail to exist at every step of the process, and the steps fail in different ways. None of these pathways is currently quantified (that is what the validation work described below is for), but all of them are known to be possible, and a reader assessing coverage should have them in view.

• The search never surfaces the page. The evidence exists but the queries did not reach it.
• The wrong site is identified as the institution’s own. Everything that follows then examines the wrong domain.
• The site-restricted search misses the page even when the right domain was identified.
• The eligibility filter removes a relevant address. The rules are deliberately narrow, but they are rules, and a rule can misfire.
• Triage judges a relevant page not worth reading.
• Retrieval fails or returns incomplete content: the page is unreachable, blocked from automated access, or returns too little text to read.
• Extraction does not recognise the evidence on a page that was read successfully.
• Consolidation rejects a record, or a run does not reach the step that would have written it to the published tables.

These pathways compound: an institution whose official site was misidentified early is unlikely to be recovered later, because every subsequent step is working from that mistake.

The opposite failure (a record that exists but should not, or that says something the evidence does not support) has its own distinct pathways. Some involve model judgement and some do not.

• An irrelevant page survives triage and is read as though it were evidence.
• Extraction misreads the page: attributing an activity to the wrong institution, or reading a description of something else as a description of the institution.
• Ordinary automation is recorded as generative AI. A rules-based system, a decision tool or a chatbot built without a language model can be described in language that resembles generative-AI adoption.
• Speculative or conditional language is recorded as confirmed activity. A page discussing what an institution might do, or is consulting on, can be read as a statement of what it does.
• Provenance is incomplete or attached to the wrong evidence, so a record cannot be checked against the page that produced it.
• Consolidation does not catch an unsupported reading when it reconciles several pages for one institution.

It would be convenient to attribute all of these to the model calls, and it would be wrong. A page that reaches extraction because retrieval returned a redirect or a boilerplate landing page is a retrieval failure; a record that survives because several pages repeat one press release is a consolidation limit. The distinction matters because the remedies differ.

In June 2026 a manual audit examined a sample of records against their sources by hand. It identified four recurring kinds of error. That audit examined an earlier version of the collection pipeline, which has since been retired and replaced: the version it studied assembled pre-collected spreadsheets, whereas the current pipeline performs its own search and extraction. Its findings are therefore not measurements of the system described on this page.

• Ordinary automation coded as generative AI.
• Speculative “might adopt” language recorded as confirmed activity.
• A skew in retrieved material toward 2024.
• Missed evidence on non-English-language sites.

We publish them because they describe failure modes of the task, not of one implementation, and each remains plausible for the current pipeline. Three of the four map onto known characteristics of the current system: the definitional boundary between automation and generative AI, and between confirmed and speculative activity, is enforced in the extraction and consolidation instructions; discovery applies no date control; and discovery runs in English.

These are the error classes our validation work is designed to measure. They are not a resolved checklist, they are not current error rates, and their appearance here is not evidence that the current pipeline does or does not exhibit them. Whether any of them affects the present system, and to what extent, is an open empirical question.

Search results and retrieved pages are stored locally and reused when the same query or address comes up again. This keeps the pipeline affordable and reduces the load placed on the websites it reads, but it has a consequence a reader comparing outputs should know about.

Two runs over the same institutions may be reading the same stored copies of external material rather than consulting the web afresh. Where that happens, agreement between the runs partly reflects the stored inputs they shared, not only the stability of the pipeline. The reverse holds too: if the stored material has been cleared or has expired, a second run consults a web that has moved on in the meantime, and disagreement can reflect the world changing rather than the pipeline behaving inconsistently.

Any claim about how consistently this pipeline reproduces its own results therefore has to record what stored material was in use at the time. That is a precondition of the stability work now underway, and it is the reason no such claim appears on this page yet.

The pipeline’s output is not free text. Each institution’s findings are consolidated into a fixed, documented structure: a published schema that the model-mediated steps are held to and that the final writing step validates before anything is recorded. Output is organised as three related tables.

Activities

One row for each distinct generative-AI activity identified at an institution: what it is, what kind of tool it involves, how far adoption has progressed, and what governance measures were documented alongside it.

Sources

One row for each page that supports an activity, carrying the address, the title, the date the page was published where available, the date we retrieved it, and an assessment of how authoritative the source is. Some sources are recorded as supporting no particular activity, because they established that no evidence was present, or were too ambiguous to attribute.

Institution summary

One row per institution per run, recording the institution-level finding, counts of the activities and sources behind it, and the confidence and uncertainty flags carried forward from them.

Every row carries provenance: which run produced it, on what date, with which model and which piece of software, and an identifier that links a record to its supporting sources. This is the mechanism by which any record on this site can be traced back to the page it came from and checked. Where a value was supplied by a fallback rather than read from the page, that too is recorded, so an assumed value is distinguishable from an observed one.

Provenance also records which languages the search for that institution actually ran in. That field is derived from the configuration the run actually used rather than being set independently, specifically so it cannot overstate or misdescribe what was searched. A reader assessing whether an institution’s coverage is likely to be complete should read it alongside the record.

The structure records the institution-level finding and the activity-level detail separately, because they answer different questions and can be revised independently. Records are also scoped to the run that produced them: identity that persists across runs belongs to the institution registry, not to these tables.

One way to misread this dataset, and a consequential one, is to treat the absence of a record as a finding. It is not one.

An institution with no recorded activity may be one where any of the pathways above intervened: the page was never surfaced, the wrong website was identified, a relevant address was filtered or a relevant page judged not worth reading, retrieval failed, extraction did not recognise what was there, consolidation rejected the record, or the run never reached the step that writes records. Or it may be an institution where no public evidence of generative-AI activity exists to be found.

Only the last of those is a statement about the institution. The others are statements about the pipeline’s processing. They produce the same visible result (no record) and they are not interchangeable. An institution that has not been examined is not thereby an institution found to be doing nothing, and no analysis should treat an empty result as a zero without first establishing which of those outcomes applies.

The same caution applies to review. Records differ in how far they have been through the pipeline’s own checking steps and any subsequent human review, and that status is recorded rather than implied: how far a run went travels in the record’s provenance, and whether anyone has looked is its evidence state, in the vocabulary the parent methodology page defines. Read a record together with its provenance and its evidence state; neither the presence of a record nor its absence is self-explanatory without them.

Everything above describes how the pipeline works and where it can fail. It does not tell you how often it fails, and we are not in a position to tell you that yet.

The pipeline contains one internal checking step: the consolidation stage reconciles the claims extracted from several pages for a single institution, resolving disagreements between sources and carrying uncertainty forward. That is a consistency check on what extraction produced. It does not compare anything to an independently established answer, and it cannot detect an error that extraction and consolidation share.

Measuring the pipeline against independently established answers is separate work, currently in design. It will estimate, step by step, how often relevant evidence is missed and how often a recorded finding is not supported, by comparing pipeline output against a set of records coded by hand. A comparison against what a straightforward AI-assisted web search would return is planned alongside it. Until that work is complete and its results are approved, this page publishes no figure of any kind about the pipeline’s accuracy, consistency or error rates, and readers should treat any such figure attributed to G3O as unverified.

Records here are evidence-backed outputs of an automated process. They are not verified facts, and they are not a census. Each one asserts that a specific page, retrieved on a specific date, was read as describing a specific activity, and no more than that; the page it came from is recorded so the assertion can be checked.

• Check the provenance before relying on a record. The supporting source is recorded precisely so it can be read.
• Do not read an empty result as a negative finding. See Reading absence above.
• Weigh the language limitation before comparing countries, since discovery currently runs in English.
• Do not interpret a record beyond the evidence and the processing that produced it, including how far through the pipeline the run in question went.
• Keep three questions apart. What institutions exist is answered by the registry; what evidence was found is answered by this pipeline; what has been checked by a person is a separate matter again.

Validation evidence will be added to this page when it is complete and approved. Until then, the honest description of this dataset is that it is a systematic, documented, and inspectable attempt at broad coverage whose error characteristics have not yet been measured.