---
title: Stanford Foundation-Model Ecosystem Graph
url: https://www.emergentmind.com/topics/stanford-foundation-model-ecosystem-graph
type: topic
---

# Stanford Foundation-Model Ecosystem Graph

The Stanford Foundation-Model Ecosystem Graph is a Stanford Center for Research on Foundation Models (CRFM) documentation framework and public resource for representing the sociotechnical ecosystem around foundation models rather than only the models themselves. Introduced in “Ecosystem Graphs: The Social Footprint of Foundation Models,” it treats datasets, models, and applications as interdependent assets connected by directed dependencies and enriched by per-asset metadata, with the stated aim of supplying a minimum transparency standard for stakeholders ranging from researchers and auditors to policymakers [2303.15772]. Its conceptual backdrop is the Stanford-origin account of foundation models as broadly pretrained, widely adaptable systems whose leverage and homogenization make downstream dependencies socially consequential [2108.07258].

## 1. Origins and institutional setting

The resource was created primarily through Stanford, especially the Stanford Center for Research on Foundation Models, with support also acknowledged from Stanford HAI. It was introduced by Rishi Bommasani, Dilara Soylu, Thomas I. Liao, Kathleen A. Creel, and Percy Liang, and was presented not merely as a one-off visualization but as public infrastructure for transparency about foundation models and their broader societal footprint [2303.15772].

In practical terms, the Stanford Foundation-Model Ecosystem Graph has both a conceptual and an operational form. The paper points to a live public site at **https://crfm.stanford.edu/ecosystem-graphs** and to an open repository at **https://github.com/stanford-crfm/ecosystem-graphs**. This dual form matters because the project was explicitly framed as a documentation system: the website provides public inspection, while the repository preserves schema, data, and version history [2303.15772].

The motivating claim is that the impacts of models such as GPT-4, PaLM, or Stable Diffusion cannot be understood by inspecting model internals alone. Datasets shape training, organizations shape disclosure and control, APIs and applications determine who encounters benefits and harms, and deployment choices determine whether failures can be detected or contested. In that framing, a model-only lens is inadequate because products and applications mediate much of actual social impact, while upstream dependencies structure the flow of resources, money, power, and risk [2303.15772].

## 2. Formal schema and asset-centric design

The framework is deliberately lightweight. The paper states that each asset \(a \in A\) has a type \(T(a) \in \{dataset, model, application\}\), each asset \(a\) has a set of dependencies \(D(a) \subset A\), and each asset \(a\) is annotated with properties \(p(a)\), stored in that asset’s ecosystem card. No more elaborate tuple definition, ontology logic, or symbolic update calculus is provided; the formalism is intentionally minimal [2303.15772].

An asset is the fundamental node-like object in the graph. The primary asset categories are datasets, models, and applications. Organizations are also tracked, but not as the main node type in the formal section. Instead, organizations appear principally as metadata—especially through the organization field on assets—and are then used to reason about inter-organizational relations induced by asset dependencies. This makes the representation asset-centric rather than organization-centric, an intentional design choice that the paper contrasts with more institution-centered approaches [2303.15772].

The operational representation is more pragmatic than the formal schema alone suggests. The paper notes that nodes do not always correspond one-to-one to a single atomic artifact; in practice, they may correspond to sets of closely related assets, such as multiple model sizes within a family. GPT-3 is the canonical example: the graph may represent the family as one node even though the original paper introduced multiple sizes. This compression is justified as a legibility tradeoff, though it necessarily sacrifices some fidelity [2303.15772].

A common misconception is therefore that the Stanford graph is either a strict organizational map or a fully formalized graph-theoretic ontology. It is neither. It is a typed, asset-centered dependency graph augmented by documentation cards, designed to be useful under conditions of incomplete disclosure rather than to enforce a complete ontological theory [2303.15772].

## 3. Dependencies and the sociotechnical ecosystem

A dependency is a directed edge from an asset to the upstream assets required to build it. The paper’s baseline cases are technical: a model depends on training data, an application depends on a model, and an adapted model depends on a base model plus fine-tuning data. Examples given in the paper include **LAION-5B** as a dependency for **Stable Diffusion**, **Stable Diffusion** as a dependency for **Stable Diffusion Reimagine**, the **GPT-4 API** powering **Microsoft 365 Copilot**, **Microsoft 365 Copilot** integrating into **Microsoft Word**, **Jurassic-1 dataset** training **Jurassic-1**, and **BLOOM** fine-tuned on **xP3** producing **BLOOMZ** [2303.15772].

The paper repeatedly emphasizes that technical dependencies induce social and organizational dependencies. The graph directly encodes asset-to-asset technical relations, but these relations reveal organizational dependence because the organizations controlling those assets are attached as metadata. The paper’s canonical example is that Microsoft depends on OpenAI because Bing depends on GPT-4. This does not mean the graph mechanically resolves legal or normative questions of responsibility; rather, it surfaces dependency-mediated asymmetries in control, revenue, access, and monitoring capacity [2303.15772].

The authors also identify recurring graph motifs. The canonical pipeline is dataset \(\rightarrow\) model \(\rightarrow\) application. Adaptation appears when a base model plus another dataset yields a derivative model. Application layering appears in chains such as GPT-4 API \(\rightarrow\) Microsoft 365 Copilot \(\rightarrow\) Microsoft Word. Application dependence can also run in the opposite functional direction, as in Google Search supporting Sparrow through retrieval, illustrating that applications are not always sinks [2303.15772].

The March 16, 2023 snapshot documented in the paper had the following composition:

| Category | Count |
|---|---:|
| Assets | 262 |
| Datasets | 64 |
| Models | 128 |
| Applications | 70 |
| Organizations | 63 |
| Dependencies | 356 |
| Metadata entries | 3850 |

These counts establish that the graph was not hypothetical but a concrete curated resource at publication time [2303.15772].

The paper highlights several high-degree hubs. **The Pile** appears as a central training dataset used across institutions including EleutherAI, Meta, Microsoft, Stanford, Tsinghua, and Yandex. **P3** appears as an instruction-tuning hub. **PaLM** appears as a central internal Google model connected to PaLM-E, PaLM-SayCan, Flan-U-PaLM, Minerva, and Med-PaLM. **ChatGPT API** appears as a deployment hub enabling downstream products across many sectors. A more specialized example is Google’s music-related subgraph, where **Noise2Music**, **AudioLM**, **MusicLM**, **SoundStream**, **MuLan**, **MusicCaps**, **LaMDA**, and **PaLM** reveal non-obvious links between music generation and broader language-model infrastructure [2303.15772].

## 4. Ecosystem cards, interfaces, and implementation

The metadata layer is the ecosystem card, explicitly inspired by datasheets, data statements, and model cards. The paper states that the card is intended to centralize useful information and point to sources rather than duplicate all underlying documentation. General properties across all asset types are **name**, **organization**, **description**, **created date**, **url**, **dependencies**, **quality control**, **access**, **license**, **intended uses**, **prohibited uses**, **monitoring**, and **feedback**. Dataset-specific fields add **datasheet**, **modality**, **size**, **sample**, **analysis**, **included**, and **excluded**. Model-specific fields add **model card**, **modality**, **size**, **analysis**, **training emissions**, **training time**, and **training hardware**. Application-specific fields add **output space**, **adaptation**, **terms of service**, **monthly active users**, **user distribution**, and **failures** [2303.15772].

The GPT-3 ecosystem card shown in the paper illustrates the intended granularity. It records **OpenAI** as the organization, **Jun 10, 2020** as created date, **Text (English)** as modality, **175B parameters (dense model)** for the Davinci model, **GPT-3 dataset** as dependency, **552.1 tCO2e** training emissions, **3640 petaflop/s-days** training time, **Azure** as training hardware, **Limited** access, and that GPT-3 is “exclusively licensed to OpenAI and Microsoft.” It also includes intended uses, prohibited uses, monitoring, and feedback [2303.15772].

On the public site, CRFM provides multiple interfaces. The paper states that users can access a **graph view** for zooming and subgraph inspection, an **interactive table view** for search, metadata filtering, field inclusion and exclusion, sorting by columns such as organization or type, and **export to CSV**, along with per-asset ecosystem cards accessible from either graph or table. Each ecosystem card links both to upstream dependencies and downstream dependents [2303.15772].

The backend is implemented as a collection of **YAML files** following a pre-specified schema matching the card fields. Dependencies listed in YAML are used to construct the graph, and if a dependency is named without a full card, a **stub node** is created. Contributions can be submitted by pull request and are reviewed by a verified maintainer. This gives the resource a documentation workflow closer to a moderated public knowledge base than to a static infographic [2303.15772].

## 5. Curation methodology, transparency functions, and accountability

The graph is built through manual curation from heterogeneous public sources, including academic papers, model cards and datasheets, blog posts and press releases, news articles and journalism, venture capital indices, and other public documentation. Asset discovery is acknowledged as ad hoc and difficult, and the authors explicitly discuss “dark matter”: assets that clearly exist but are effectively undocumented, with GPT-4’s training data as the major example [2303.15772].

Because exhaustive coverage is infeasible, the paper states that curation prioritizes assets that are **socially salient**, have **outsized impact**, or **represent a broader class**. The authors acknowledge that these criteria are subjective and say they intentionally tend to over-include rather than under-include. They also define four distinct missing-data states: **none** when annotators searched and could not find the information, **unknown** when the information must exist but is not publicly available, **empty string** when annotators chose not to annotate, generally due to time constraints, and **N/A** when a property is not applicable. This treatment of missingness is central because opacity is itself treated as an object-level finding [2303.15772].

The transparency functions described in the paper are broad. For developers, the graph helps identify upstream assets, competitors, and emerging demand. For application builders, it supports comparison of models not only by benchmark performance but by ecosystem uptake, access conditions, and licensing constraints. For end users, it can reveal what a product depends on and what feedback or recourse channels exist. For researchers, it links deployed applications back to upstream technical work. For economists, it helps characterize realized ecosystem structure and inter-firm relations. For auditors and policymakers, it provides a supply-chain-style map for prioritizing central, opaque, failure-prone, or highly consequential nodes [2303.15772].

Several use cases concern accountability and risk propagation directly. The paper asks, for example, who downstream would need to know if **LAION-5B** were found to be data-poisoned, which downstream products would be affected if the **ChatGPT API** went down, and how homogeneous failures might propagate when many applications depend on a highly central asset. In that sense, the graph is explicitly linked to reasoning about algorithmic monocultures, license and compliance analysis through fields such as **license**, **access**, and **analysis**, and environmental accounting through **training emissions**, **training time**, and **training hardware** [2303.15772].

## 6. Limitations, misconceptions, and subsequent reuse

The paper is frank about limitations. Coverage is incomplete, especially for closed and commercial systems. Asset discovery is manual and “somewhat ad hoc.” Dependencies are often uncertain or underdisclosed. Metadata may be sparse, uneven, or outdated as products change rapidly. Grouping multiple assets into a single node can obscure distinctions. Maintenance is difficult because the ecosystem changes quickly; the paper notes that the week of March 13, 2023 alone saw over a dozen GPT-4-dependent products announced. Organizations may also have incentives to publicize success while withholding failures, operational details, or commercially sensitive dependencies [2303.15772].

Several interpretive cautions follow from those limitations. The paper directly supports the claim that asset-level dependencies can induce social and organizational relationships, but it does not claim that graph structure alone settles questions of blame, legal responsibility, or governance. Likewise, the graph’s formalism is precise but intentionally modest: it is a schema for assets, dependencies, and cards, not an exhaustive symbolic model of the ecosystem [2303.15772].

Later work reused the Stanford Foundation-Model Ecosystem Graph in a somewhat different analytical role. “Emergent evaluation hubs in a decentralizing large language model ecosystem” treats the Stanford graph, at a **2025-03-01** snapshot, as one of two curated proxies for the AI ecosystem. In that paper, a **monthly crawler** aggregates releases mentioned in **arXiv preprints**, **model cards**, **Hugging Face pages**, **GitHub tags**, and **company blogs**, merges aliases and checkpoints, and verifies external links. After removing **17** records with ambiguous launch dates, the authors retain **418 distinct models** released between **January 2018** and **28 February 2025**. That paper explicitly notes that the Stanford resource is operationalized less as an analyzed knowledge graph than as a curated metadata registry for the model-production layer of the ecosystem [2510.01286].

That later use clarifies both the durability and the flexibility of the Stanford resource. In its original formulation, it was a sociotechnical dependency graph with ecosystem cards and supply-chain ambitions. In later ecosystem analysis, it also functioned as a longitudinal registry for releases, licensing, modalities, documentation, and organizational diversity. This suggests a continuing dual identity: both a graph for tracing dependencies and a transparency infrastructure for structured ecosystem observation [2303.15772]

Source: https://www.emergentmind.com/topics/stanford-foundation-model-ecosystem-graph