When you download an open-source LLM, you think you know its lineage. The model card says: fine-tuned from Llama, trained on open datasets. It looks crystal clear.
But if you keep asking: how was that dataset built? What model filtered it? What was that filter model trained on? Does that base model's training data have copyright disputes? — after a few layers of questions, you find the dependency chain nests like Russian dolls, and the documentation for each layer lives in a different place.
Researchers at UC Berkeley and the Allen Institute for AI call this problem invisible dependencies, and built an agent system called ModSleuth to trace them.
The Problem: Dependency Graphs Are Fragmented
Modern LLM training pipelines are not a straight line but a complex graph:
- Data generation: using GPT-4 to produce training data
- Data filtering: using another model to select high-quality samples
- Evaluation: using a third model as a judge
- Alignment: via DPO/RLHF, where the reward model is yet another separate model
- Multi-hop license obligations. Model A uses data generated by model B, which was fine-tuned from model C, which has a non-commercial license. Model A is actually bound by C's license — but this three-hop relationship is completely invisible in A's documentation.
- Train-evaluation coupling. Some models have hidden dependencies between training data and evaluation benchmarks — the evaluation model or data indirectly participated in constructing the training data, risking contaminated results.
- Release vs. reality mismatch. Documented model versions often differ from what the code actually uses — "documentation drift" is common in fast-moving projects but rarely noticed.
- Model-mediated data selection. Training data isn't hand-picked but filtered by another model, embedding the filter model's preferences and biases into the selection process — invisible from the final dataset's description.
Every stage can introduce new model dependencies, scattered across papers, GitHub repos, HuggingFace model cards, and technical reports. Worse, these documents often disagree — the model card says Llama-2, the code actually uses Llama-2-chat; a technical report cites dataset v1, but v2 was actually used.
Human tracing is no longer feasible: the recursive depth and heterogeneity far exceed what manual auditing can handle.
How ModSleuth Works: A Three-Tier Detective
Stage 1: Evidence collection. Given a target model (e.g., OLMo 2), ModSleuth gathers relevant documents from all public sources — papers, model cards, GitHub repos, HuggingFace pages. It doesn't just search; it uses LLMs to understand content and extract dependency-relevant information.
Stage 2: Entity discovery and disambiguation. The hardest part. "Llama-2", "Llama 2", "llama2", "meta-llama/Llama-2-7b" may be the same model — or different versions. ModSleuth must resolve these references across documents, using version numbers, repo paths, and release dates as context.
Stage 3: Dependency construction and reconciliation. All evidence is aggregated into a dependency graph. The key innovation is an operation-centered representation: instead of saying "A depends on B", it says "A's data-filtering operation used B", distinguishing types of dependency relations.
ModSleuth then recursively expands — repeating the process for every upstream dependency until the graph converges.
Findings: 1,060 Source-Verified Dependencies
ModSleuth audited four public LLMs — OLMo 2, Amber, Phi-1.5, and OpenELM — recovering 1,060 dependency relations backed by source-code evidence. Key findings:
Why It Matters
Transparency is not a luxury. As the LLM ecosystem grows more complex, "who does my model depend on" matters for license compliance, safety evaluation, and bias provenance. ModSleuth shows manual tracing is unrealistic; automated auditing is necessary.
The software supply-chain analogy. Like library dependencies in software, models nest layer by layer. The software industry developed SBOM (Software Bill of Materials); AI needs an analogous MBOM (Model Bill of Materials).
Auditing the auditor. ModSleuth uses LLMs to audit, and LLMs themselves have dependencies — a meta-problem. But the authors note every recovered dependency is backed by source code evidence, not LLM hallucination, providing verifiability.
Limitations
ModSleuth can only trace dependencies documented in public sources. If a model used undisclosed internal models (common in commercial models), ModSleuth cannot see it. Entity disambiguation also retains errors — identical names in different documents may refer to different artifacts.
Still, as a first step, ModSleuth reveals an overlooked reality: modern LLM dependency graphs are far more complex than we assume, and current transparency practices fall far short.
---
Paper: https://arxiv.org/abs/2606.12385 Code: https://github.com/cal-data-audit/modsleuth Demo: https://modsleuth.cal-data-audit.org Institutions: UC Berkeley, Allen Institute for AI