The Dependency Stack Beneath an Open Weight

The subject now is the LLMware supply chain that forms around an open model. The key question is what remains connected after a model’s weights are available: which applications invoke it, which base models and datasets sit upstream, and which operating conditions make the artifact usable. Drawing that graph gives the reader a practical test for independence. If a weight can be copied but its surrounding interfaces, lineage, data, or operating environment cannot be controlled or replaced, the vendor dependency has changed shape rather than disappeared.

LLMware turns a model into a supply-chain node

Conventional software is often described as a stack of code: an application calls libraries, the libraries call other packages, and maintainers release updates that downstream users incorporate. LLMware adds a different kind of component. It is software that embeds or invokes a large language model as a core part of its behavior. The application may call a model locally or through a service, but in either case the model is not just a passive file. It produces the system’s outputs and may carry its own upstream relationships.

The second study identifies three kinds of artifacts in this wider supply chain: open-source software repositories, large language models, and datasets.[2] An application can invoke one or more models. A model can be fine-tuned from a base model, distilled from an earlier system, or linked to a dataset used in training. The model may also be used by many applications at once. These are not merely organizational labels. They are interfaces through which behavior, cost, provenance, and obligations travel.

The study’s public dataset makes the scale of that structure visible. It identifies 12,180 GitHub repositories, 3,988 Hugging Face language models, and 708 datasets connected through the analyzed relationships.[2] The numbers should not be read as a census of every AI application. They show that even a bounded view of public LLMware produces a graph much richer than a conventional list of software packages.

To connect code repositories to models, the researchers searched for actual uses of Hugging Face libraries and extracted model identifiers from calls that load or invoke models. They used 363 API signatures across 23 Python libraries, then applied static analysis to distinguish executable calls from imports, comments, or dead code. The resulting mapping is many-to-many: one repository can depend on several models, and one model can serve several repositories. The researchers validated a random sample of 50 mappings and found them correct under their procedure.[2]

That procedure is important for two reasons. First, it shows what it means to identify a dependency in observable software rather than infer one from a keyword or a repository description. Second, it defines the boundary of the evidence. The graph captures public code that uses the supported library patterns and public model metadata. It does not automatically reveal every remote API, private model, undocumented data source, runtime dependency, or organizational agreement. A visible edge is evidence of a relationship; an invisible edge is not proof that no relationship exists.

The upstream side is reconstructed through model metadata.