AmpliGraph pins its whole install envelope to one TensorFlow release and announces version 2.0 on top of 2.2

The install envelope is pinned at both ends by one framework release

The dependency list explains itself in comments, which is better than most projects manage.

The framework is pinned to a single minor version, from 2.15 up to but not including 2.16, and the comment says why: 2.15 is the last release of the second generation of the higher-level API. The numeric library underneath is held below its second major version, with a comment saying that is required by the same framework release.

The Python requirement is `>=3.9,<3.12`, and the classifier list matches, naming exactly three minor versions. So the supported set is closed at both ends: three Python versions and one framework minor version.

There is a separate extra for GPU work that pulls the framework's own accelerator bundle, so a CUDA install is opt-in rather than automatic. The remaining dependencies are ordinary, with lower bounds going back years and no upper caps: a machine learning toolkit, a progress bar, a dataframe library, a table formatter, a YAML parser, an RDF library, a scientific stack, a graph library and a plotting library.

That is a package you can install cleanly in a virtual environment and cannot install into an environment that has already moved past that framework generation. For a library published in 2019 and still receiving releases in 2026, that is the trade it has made.

The status badge watches a branch the install instructions tell you to avoid

Three places name a branch, and they do not agree.

The repository's default branch is develop. The installation instructions for the development version tell you to clone, check out develop, and run a single sync command:

git clone https://github.com/Accenture/AmpliGraph.git
cd AmpliGraph
 git checkout develop
uv sync

And the build status badge in the readme points at a continuous-integration status page for the main branch.

So the badge reports on a branch that the project's own instructions treat as secondary, while the branch a developer is told to install from has no badge. A green status badge on this readme is not evidence about the code you would get from the documented source install.

There is a second cause. The tree contains a directory for one continuous-integration system and a pipeline definition file for another, so there are two CI configurations in the repository, and nothing in the readme says which one gates a merge.

Documentation has the same shape of drift. One badge points at a hosted documentation service under one subdomain, the description and the body of the readme point at a different subdomain, and the link in the documentation section uses plain HTTP while the badge uses HTTPS.

The benchmark table explains why its numbers are lower than the published ones

This is the part of the readme that most deserves credit, and it is worth reading closely.

The table reports filtered mean reciprocal rank for five embedding models across five standard benchmarks, with a row for the best published result above them. Footnotes attach to that row, and they resolve to two papers: a 2018 conference paper on canonical tensor decomposition for knowledge base completion, and a 2017 preprint titled around baselines striking back.

So the reference row is sourced, not asserted.

Then a second note, and this is the important one: the results assign the worst rank to a positive when there is a tie, described as the most conservative approach, with the observation that some published work may instead assign the best rank. In other words, the table is telling you that some of the gap between its numbers and the literature may be a measurement convention rather than a model.

Read the columns, and the project does not come first everywhere. The literature row is the bolded winner on three of the five benchmarks. The library's own models win two: one of the complex-valued models on WordNet with reciprocal relations at 0.51 against 0.48, and the rotation-based model on WordNet without relations at 0.95, matching the literature's best.

Discontinued models sit in the same table as current ones

Two of the rows are labelled with the version that implemented them, both from the 1.4 line, and the text above the table says versions before 2.0 also include those two models while 2.0 discontinued support for some obsolete models.

So the table benchmarks three implementations the current release cannot run, against six rows it can, with nothing in the layout to say which is which except a version suffix in the row label. There is no separator, no dimmed row, no footnote marker.

The numbers are not wrong. The 1.4 results are what the project measured for its earlier models and they are worth seeing, because the earlier convolutional models score worse than the current ones on the newer benchmarks and better on the older knowledge base one. But a reader scanning for the best number in a column can easily pick a row describing software they cannot install.

There is a smaller inconsistency in the same area. The modules section lists four embedding models with a note that more are coming, and the rotation-based model that wins one of the five benchmark columns is not among them.

One module exists only to keep the previous major version's API working

The library describes itself as a suite with five submodules, and one of them is not about machine learning.

The compatibility submodule extends the current APIs to those of the previous major version, for users already familiar with them. That is a whole module whose only job is to make an interface from two years earlier keep working, carried in the current release.

It is a defensible choice and an expensive one. Every function in that module is code that exists only to translate, and it must be kept working across every breaking change the new API makes. For a library on version 2.2 whose immediate predecessor line stopped releasing in 2024, that is a permanent maintenance cost for a shrinking population of users.

The other four modules are the ones you would expect. Dataset helpers for loading knowledge graphs. The models themselves. Evaluation, described as metrics and protocols to assess predictive power. And discovery, described as high-level convenience APIs for finding new facts, clustering entities and predicting near duplicates, which is the module that turns a model into something you can query without writing the scoring yourself.

Two runtime dependencies are pinned to exact old versions

Thirteen runtime dependencies, eleven with open ranges, and two with no range at all.

One is a command-line argument parser pinned to a single release with an equality sign. The other is a validation library pinned the same way. Both exact pins sit among lower bounds that go back to releases from 2017 and 2018, which is inconsistent: if you are going to trust a floor from 2017, an exact pin from the same era is a different kind of statement.

The documentation extra is where the pinning is heaviest, and it is defensible. Sphinx and its bibtex extension are each pinned exactly, the docutils version has an upper bound, a theme and a bibliography tool have exact pins, and the build requirement caps setuptools below a specific major. Documentation toolchains break in ways that runtime ones do not, so pinning them is normal.

The extras are otherwise tidy: a GPU extra, a test extra with a floor on the test runner, a lint extra, and a development extra that simply combines the test and lint ones. That last pattern is the clearest sign the packaging has been tidied deliberately rather than accumulated.

The headline section announces 2.0 while the release is 2.2

The most prominent block in the document is a notice that version 2.0.0 is now available, describing the second-generation framework backend, the Keras-style APIs, and the changed input and output pipeline, with support for some obsolete models discontinued and a pointer to the changelog for the full list.

The release that install gives you is 2.2.0. So the headline block is two minor versions behind the software, and it is the section a reader is most likely to act on.

The release timeline explains why. A 2.0.1 in July 2023, a 2.1.0 in February 2024, and then nothing for eighteen months until 2.2.0 in July 2026. The last recorded change to the repository is dated 2026-08-06.

The two installation paths report their versions honestly, which is more than the headline does. A release install reports two point two point zero. A development checkout of the branch reports a development string instead, so at least the version in your interpreter tells you which of the two you have.

The suggested citation is dated 2019 and the section opens by asking for a star

The citation section opens with a sentence about starring the project, followed by a link to the stargazers page, and only then does the citation itself appear.

The citation is a BibTeX entry with nine author names, the library title, and a month and year of March 2019, pointing at a DOI. The same DOI is in the badge at the top of the document.

Two problems with that. The month and year are pinned to 2019 while the current release is from July 2026, so a citation copied today attributes a 2026 version to 2019. And the DOI is a concept-level identifier from a general-purpose archive, which by design always resolves to the newest version rather than to the one you used, so a reader following it gets something that is not what you ran.

There is also an omission worth noting. The search terms that lead people to this library are largely the name of a different one, a knowledge graph embedding library that is not mentioned anywhere in the document. So the readme benchmarks its models against published papers rather than against the alternative a reader is probably comparing it to.

Editorial conclusion

AmpliGraph is worth evaluating if knowledge graph completion is the task you actually have, and the benchmark table is a genuine strength rather than a weakness, because it states the tie-handling convention that makes its numbers lower than published ones and cites the papers for the baselines. Three things to settle first. The dependency set is held inside one framework generation, with the framework pinned to a single release and the array library held below its second major, so check what else in your environment wants those. The supported Python range stops at 3.11. And the readme's own status badge watches a different branch from the one its installation instructions tell you to check out, so do not read a green badge as evidence about the code you would get from a source install.

Frequently asked questions

Official sources

1. Accenture/AmpliGraph on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases