World models on GitHub

A pipeline for identifying and characterising applied world-model projects in public GitHub repositories.

World models are still a relatively young area. Most published work focuses on architectures and benchmark results; less is known about how the idea is being used in open-source projects outside major research labs.

This repository contains the code and methodology used to construct a dataset of such projects.

The objective is not simply to collect repositories that mention world models. GitHub search returns a much broader set: implementations of papers, personal experiments, course assignments, link collections, abandoned repositories, unrelated uses of the phrase, mirrors of other projects, as well as projects that actually build or apply a world model.

The pipeline starts with a broad search and progressively converts these results into a structured dataset for analysis by application domain, technical characteristics, and use in science and education.

Research scope

For this study, a world model is treated as a learned model of how the state of an environment changes over time and is used to predict, simulate, plan, or generate subsequent states.

The GitHub analysis addresses three broad questions:

• What do world models look like in practice? What they model, what signals they operate on, what they predict, how those predictions are used, how their components are trained, and whether they build on an existing world model.

• Where are they being applied? Which application domains appear in GitHub projects and how their distribution changes over time.

• How far have they moved into science and education? Which projects apply world models to scientific or educational work, which fields they belong to, what part of the research process they support, and whether any perform a larger research loop autonomously.

The emphasis is therefore on applied projects rather than on counting mentions of the term or compiling a list of world-model papers.

From GitHub search to a research dataset

A GitHub keyword search is the starting point, not the dataset.

The current search retrieves roughly 24,000 repositories. Most do not survive the full pipeline. After removing obvious non-projects, duplicates, repositories that use the phrase in another sense, and projects that do not actually implement or use a world model, roughly 4,500 repositories remain.

The pipeline proceeds through the following stages:

GitHub search
      ↓
deduplication
      ↓
README collection
      ↓
basic cleaning
      ↓
world-model relevance filter
      ↓
application claim extraction
      ↓
technical description
      ↓
domain classification
      ↓
domain discovery / clustering
      ↓
science and education analysis
      ↓
final dataset + descriptive statistics

The pipeline separates retrieval, filtering, and classification. Raw observations are retained before later decisions are applied, allowing filtering and classification choices to be revised without repeating the GitHub collection.

Pipeline

The repository currently contains 17 sequential steps. Each script reads the output of an earlier step and writes a new file.

Some steps run locally, some call Gemini, and several require manual review before the pipeline continues.

model indicates a step that sends repository text to Gemini. manual indicates a step that requires human review or decisions.

01 — Search GitHub

01_search_github_repos.py

Searches GitHub for repositories containing several common variants of world model.

GitHub Search returns at most 1,000 results for a query. To avoid losing repositories above that limit, the script recursively divides the requested date range into smaller windows until each query falls below the cap.

Forks are excluded at query level, so the results contain original repositories only.

The search term and search window associated with each result are retained.

02 — Deduplicate search results

02_dedup_search_results.py

The same repository can appear under several search terms or in overlapping search windows.

This step reduces those observations to one repository record while retaining the terms through which the repository was found.

03 — Fetch READMEs

03_fetch_readmes.py

Downloads the README for each repository.

This is the last stage that requires GitHub access. Downstream processing uses the locally collected files.

README text is necessary because repository names, topics, and short descriptions usually provide too little information to establish whether a world model is actually present or what the project is intended to do.

04 — Basic cleaning

04_clean.py

Removes cases that can be excluded without semantic classification, including archived repositories, repositories with no usable README, repositories in which the search term does not occur in the text, personal profile repositories, link collections, and simulations or games with no learned component at all.

It also identifies repositories that represent the same underlying project under different accounts and retains one record for later analysis.

05 — Prepare text for model analysis

05_prepare_llm_input.py

Prepares README text for the model-based stages.

HTML and unnecessary formatting are removed, and very long READMEs are truncated. Code examples are retained because they often provide useful evidence about what a repository actually does.

06 — Filter for actual world models

06_llm_filter.py — model

This is the main relevance filter.

Rather than asking a single broad question such as “Is this a world-model repository?”, the classification is divided into a sequence of more specific checks.

The step evaluates whether:

1. there is an actual project rather than a discussion or collection of links;
2. the project contains or uses the relevant model;
3. that model is learned from data;
4. it predicts how a state changes over time;
5. the repository predicts something of its own, rather than being a general-purpose framework or toolkit for others to build world models with.

Using a world model developed elsewhere is treated as qualifying, provided it forms a substantive part of the project.

Most false positives are removed at this stage.

07 — Extract the application claim

07_llm_extract_claim.py — model

Produces a short description of what the world model is used for, for example:

warehouse pick-and-place robotics

or

corporate credit-risk forecasting

The output also records whether the application is explicitly stated by the repository authors or inferred from other evidence such as datasets, benchmarks, or examples.

This distinction is useful because many research repositories describe the method in detail without stating an application domain directly.

08 — Extract technical characteristics

08_llm_extract_taxonomy.py — model

Describes the world-model implementation along several dimensions, including:

• what signal or state the model operates on;
• what it predicts;
• how prediction is connected to planning or decision-making;
• how different components are trained;
• whether the project builds on an existing published world model.

These variables make it possible to compare implementations without assigning all projects to a single architectural family.

09 — Classify application domains

09_llm_classify_domain.py — model

Distinguishes projects applied to substantive external domains — such as medicine, finance, science, or education — from projects situated mainly within technical domains in which world models are commonly developed, such as robotics, autonomous vehicles, or game environments.

This step does not impose the final domain taxonomy. It assigns each repository to one of the two branches, and determines which projects continue to the domain-discovery stages that follow.

10 — Canonicalise application phrases

10_canonicalize_domain.py — manual

Application descriptions often mix the subject being modelled with the method used on it.

For domain discovery, methodological terms are removed where appropriate so that closely related applications do not become separate topics merely because one repository describes itself in terms of simulation and another in terms of forecasting.

The distinction between substantive and methodological terms is made by inspecting recurring phrases in the corpus.

This stage is applied to the external-domain branch identified in step 09.

11 — Discover domain clusters

11_leiden_clustering.py — manual

Transforms the canonicalised application phrases into embeddings, constructs a similarity graph, and applies Leiden community detection.

The resulting clusters are inspected and named manually.

Application-domain categories are therefore derived from patterns in the repository corpus rather than defined entirely in advance.

Clustering is applied to the external-domain branch only. The technical branches — robotics, autonomous vehicles, game environments, software infrastructure — are not subdivided into topics at this stage.

12 — Screen for scientific applications

12_llm_science_screen.py — model

Runs a broad screening stage to identify repositories that may be applied to real scientific work.

A clear no is excluded from the science branch. yes and unclear cases proceed to the next stage.

13 — Classify scientific applications

13_llm_science_classify.py — model

Re-evaluates the remaining repositories with a stronger model and adds a more detailed description of their scientific use.

The resulting variables include:

• scientific field;
• the part of the research process being supported;
• whether the system performs an extended or autonomous research loop.

The last of these is treated as a shortlist for manual review rather than a finding in itself.

14 — Assemble results

14_assemble_results.py — manual

Combines the outputs of the preceding stages and applies decisions that require corpus-level inspection rather than classification of individual repositories.

These include the final names of discovered domain clusters, treatment of named base models, and duplicate projects identified across the dataset.

15 — Build the final table

15_build_final_table.py

Produces the analysis-ready repository-level table with the final variables and column names.

16 — Build descriptive statistics

16_build_excel_stats.py

Creates an Excel workbook summarising the main characteristics of the corpus.

For each variable, it reports counts, changes by year, and the share represented by each category within a year.

17 — Build the funnel report

17_build_funnel_report.py

Records how many repositories are removed at each stage and reconciles the initial search results with the final analytical dataset.

This makes the effect of each filtering stage explicit.

Classification approach

There is no established taxonomy covering the full range of application domains and technical characteristics required for this study.

The classifications used here were therefore developed iteratively from two sources:

1. the existing literature on world models;
2. repeated inspection of the GitHub corpus.

Application domains are not defined entirely in advance. Application claims are first extracted at a relatively fine level, then normalised and clustered. Broader categories are assigned after inspection of the resulting groups.

A similar principle is followed elsewhere in the pipeline where possible: evidence is extracted first, while higher-level classification decisions are made separately.

Where the available repository text does not support an answer, the corresponding variable retains an explicit unknown or unsupported value rather than forcing a classification.

Outputs

Intermediate files are retained separately so that individual stages can be inspected or rerun without repeating the full pipeline.

The final outputs include:

• a repository-level results table;
• extracted application claims;
• technical characteristics of the world-model implementation;
• application-domain classifications;
• science and education classifications;
• descriptive statistics by year;
• a filtering funnel from the initial search to the final dataset.

Running the pipeline

Create a virtual environment:

python -m venv .venv

Install the required packages:

.venv/bin/pip install \
    pandas \
    numpy \
    pydantic \
    python-dotenv \
    requests \
    tqdm \
    google-genai \
    sentence-transformers \
    scikit-learn \
    igraph \
    leidenalg \
    openpyxl

Create a .env file in the project root:

GITHUB_TOKEN=...
GOOGLE_API_KEY=...

GITHUB_TOKEN is required for the GitHub collection steps. GOOGLE_API_KEY is required for the Gemini-based steps.

Run the scripts in numerical order:

.venv/bin/python 01_search_github_repos.py

Each step reads the output of an earlier stage and writes its own output.

The model-based steps are resumable. Results are appended to a progress file as they are produced, and completed records are skipped when a script is restarted.

Data

This repository contains the code and methodology, not the collected corpus.

The raw corpus is currently about 13 GB, largely because it includes downloaded repository pages and README content. It can be recreated by running the collection pipeline with GitHub access.

The corpus represents a snapshot of a changing platform; the code documents the procedure used to construct that snapshot.

Limitations

This dataset should not be interpreted as a complete inventory of world-model activity.

First, it is a keyword-retrieved GitHub corpus. A project that implements the relevant idea but does not use one of the search terms cannot be identified by this pipeline.

Second, classification is limited by the information made public by repository authors. If a README does not provide enough evidence to establish an application, technical characteristic, or scientific use, the pipeline cannot classify it reliably.

Third, the study records the existence and stated purpose of projects, not their quality. A small prototype and a mature, actively maintained library may both enter the corpus. Inclusion does not imply that a system works as claimed, reproduces published results, or has been adopted in practice.

Finally, several taxonomies used here are study-specific. They were developed from the literature and the corpus rather than taken from an established standard. Borderline cases therefore remain, and uncertainty is retained where the available evidence does not support a clear classification.

Research context

This GitHub dataset is part of a broader study of weak signals of emerging AI technologies.

World models are used as a pilot case to examine whether traces in open technical ecosystems can indicate where an emerging technology is spreading, what applications are appearing around it, and which uses become visible before they are well represented in more established sources.

The results of the world-model analysis will be reported separately in a research paper.