Tracing AI Model Licenses with a Graph Database: Inside the Pedigree Tool

The License Blind Spot Behind Model Fine-Tuning

Fine-tuning an open-source model looks like purely technical work, but license obligations propagate all the way down the model lineage. Meta's Llama 3.2 license requires users to provide notices, adopt an acceptable use policy, and follow naming rules—yet a model fine-tuned from it may list only MIT on its model card. You have to view the two pages side by side to spot the gap. This kind of information disconnect is common in real AI supply chains, and the chains often run more than two layers deep.

A preprint titled Don't Trust the Label specifically examines how licenses get "whitewashed" in AI supply chains. The authors note that no tool currently exists to automatically audit licenses across an entire chain. Most existing scanners look at only one model at a time—exactly the gap Pedigree tries to fill.

The "contagious" nature of license obligations (license propagation) is key to understanding the problem. Open-source model licenses are usually not simple grants but bundles of obligations: the Llama 3.2 Community License requires downstream distributors to retain attribution notices, include "Llama" in the model name and attach the "Built with Llama" mark, adopt an acceptable use policy, and obtain an additional license for users with more than 700 million monthly active users. When someone fine-tunes the model and redistributes it, these obligations should in theory carry over to the derivative work. But the license field itself is just a string—the Hub does not automatically verify whether a child model actually fulfills its parent's license obligations, nor does it enforce inheritance. So the "MIT" label may simply be what the publisher typed in, unrelated to the obligations the model should actually bear. This disconnect between the field and the obligations is the structural reason supply-chain license "whitewashing" can happen.

How Pedigree Works

Given a model ID in the form org/name, Pedigree reads public metadata on the Hugging Face Hub—licenses, base models, declared training datasets—and writes it into a FalkorDB graph database. It then traverses upward along the lineage, comparing each child model's declared license against the obligations required by its parent's license, item by item.

Each flag shows the path it traversed and links back to the original page for human review. The author emphasizes that a flag only means "worth a look" and does not constitute legal advice. This restraint is necessary: all an automated tool can do is surface hidden gaps—judgment still requires a human.

Missing Data Doesn't Mean No Problem

The tool has one clear design principle: any missing or unreadable information counts as risk, never as a pass. A tool that stays silent when a read fails looks cleanest precisely when it knows the least. In the first live test, one small chat model listed four training datasets; cerebras/SlimPajama-627B returned a 404 in the browser, so Pedigree flagged it as "unavailable" and declared everything on it unverifiable. Another dataset's license was listed as "other," and the tool reported that faithfully rather than treating it as acceptable.

The base_model field in Hugging Face Hub metadata is the starting point for lineage tracing, but it is not reliable. The field is filled in manually by the model publisher, can point to any model ID, and can be left blank; even when filled in, it only means "claims to be based on this model"—the Hub does not verify it. Pedigree relies on this declaration to traverse upward, which means that if a publisher at some intermediate layer omits or misstates the base model, the entire lineage breaks, and the tool can only see the portion within the declared scope. Likewise, the datasets and license fields are self-reported. It is important to understand this: Pedigree audits the declared lineage, not the actual training provenance; it can expose contradictions at the declaration level, but it cannot prove a model's true training ancestry.

What the Sample Data Reveals

The author surveyed the 60 most-downloaded Llama-3.2-1B fine-tuned models: 48 declared licenses carrying the same obligations as the parent model, 6 declared Apache-2.0 or MIT, 3 had licenses that could not be evaluated, and 3 declared no license at all.

The 6 models were not named—each is merely a lead for human verification, and a flag itself implies no intent. The sample was selected by download count, not randomly, so it does not represent the Hub as a whole. The point of these numbers is not accusation but demonstration: "license field disconnected from parent obligations" is a phenomenon that can be systematically observed.

Why a Graph Database Is the Right Choice

In Pedigree's data model, models, datasets, licenses, and obligations are all nodes; edges record who derives from whom, who trained on what data, and which license carries which obligations. A flag is essentially a Cypher query: traverse up to six levels of lineage, looking for obligations the parent license carries that the child license lacks.

The graph structure here is not just a storage choice—it directly constitutes the flag's explanation: the traversed path is the evidence presented to the reader. Without the graph, a flag would be nothing but an unsupported assertion.

Each time a user saves a decision, the system generates a separate private graph and stores a snapshot of the lineage at that moment. When reviewing later, taking a new snapshot for comparison makes it possible to pinpoint exactly which license changed at which link. When re-checking a model, old parent links are deleted first—model cards change, and the graph should not retain relationships the publisher has already removed.

Cypher is the graph query language introduced by Neo4j, and FalkorDB is compatible with its syntax. It expresses "walking along relationships" through pattern matching: for example, MATCH (child:Model)-[:DERIVED_FROM*1..6]->(parent:Model) means starting from a child model, walking up to six hops along DERIVED_FROM edges to find ancestor models, then matching their respective license and obligation nodes to find obligations the parent has but the child lacks. Compared with repeated recursive JOINs in a relational database, a graph query returns the "path" itself as a first-class result, and every node and edge on the path can be pulled out directly for display. This is the technical foundation that lets Pedigree bind a flag to a readable chain of evidence: a flag is not a boolean judgment but a specific path hit by a query.

Pitfalls and Unverified Boundaries

Deployment was not smooth. Docker initially reported that the engine was not running; after fixing that, it refused to pull the FalkorDB image, citing an unsupported TLS protocol version—yet curl to the Docker server directly worked fine. Pulling only succeeded after shutting down WSL and logging out of Docker. On the environment side, the author's machine had Python 3.15 and 3.12 installed and chose 3.12, because 3.15 was too new and some packages might not have matching builds—though the author admits not actually testing whether 3.15 would fail.

A more important boundary: only the rules and license text for Llama 3 and Llama 3.2 have been compared. Rules for other licenses are marked unverified, and the corresponding flags are only leads. The Hub only knows what publishers declare, and declarations may be missing or wrong.

On privacy design, Pedigree reads only public metadata, requires no personal information, and has no account system; the browser stores a random ID, review records live in a private graph under that ID, a Forget button deletes the entire graph, and no tokens are stored in the repository.

The meaning of "unverified rules" needs to be understood precisely. Pedigree's comparison logic depends on a manually curated mapping: which specific obligations a given license text corresponds to. The author has compared only the Llama 3 and Llama 3.2 license texts line by line, producing a trustworthy obligation list; for other licenses (such as Apache-2.0, MIT, and various "other" custom terms), the tool either lacks complete rules or has rules that have not been verified against the text. Flags produced in this case only indicate that "some inconsistency exists between the child model's declared license and the parent's obligations"—they do not guarantee the judgment is accurate; there may be false negatives, or false positives due to incomplete rules. Such flags should therefore be treated as "leads," not "conclusions," and must not be used as a basis for legal judgment.

Positioning and Limitations

Compared with serious academic work, Pedigree is a small tool. Don't Trust the Label (arXiv 2607.20300) describes license problems in AI supply chains, and AI Supply Chain Galaxy (arXiv 2606.16292) is a visual analysis system for license compliance. Pedigree's increment is that every flag comes with a readable path, plus a place to save decisions and observe changes.

Worth noting is the author's candor—an AI assistant drafted most of the initial code, but the database setup, the execution of every command, testing against live Hugging Face data, and all trade-off decisions were done by the author. This disclosure itself is a practice worth emulating in today's AI-assisted development projects.

The code is open-sourced on GitHub (triixdev/Pedigree). For teams that need to handle model compliance, it is more of a starting point: make license gaps in the lineage visible, then leave the judgment to humans.