bgavran/Category_Theory_Machine_Learning: A Paper Index, Not a Library
List of papers studying machine learning through the lens of category theory
At a glance
- What is it?
- This repository is a curated bibliography of papers that apply category theory to machine learning, organised by subfield. It ships no code you can install and no benchmark you can run, so it is useful as a reading route and useless as a dependency.
- Who is it for?
- Adopt this list if you are a researcher or graduate student who already knows basic category theory and needs to find the papers connecting it to deep learning, equivariance, graph neural networks or sheaf methods. Do not adopt it if you are looking for a Python library, a pip-installable package or a runnable baseline; the repository is a Markdown bibliography and the README describes it as a list of papers.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 49 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What a paper index solves that a search engine does not
The README states the project's purpose directly: it aims to list all of the relevant papers, grouped by fields, on category theory applied to machine learning. That is a narrower job than it sounds. Searching arXiv for category theory and neural networks returns a mix of foundational work, applications, and papers that use the word categorical in an unrelated sense. A maintained index does the filtering once and keeps the result in a single file, so a reader can see the shape of a subfield instead of reconstructing it from search results.
The intended reader is someone who already has a reason to care about the connection. The README links to a separate repository, Category_Theory_Resources, for an introduction to the ideas themselves, which is a signal that this list assumes prior background rather than teaching it. If you cannot read a phrase like monoidal category or functor without stopping, the list will not help you. If you can, it saves hours of citation chasing.
The grouping is the substance. Papers are sorted into theses, general deep learning, and narrower headings such as Equivariance and Graph Neural Networks. The README also notes that some papers appear in multiple fields, which is honest about the fact that a single paper can be both a sheaf theory paper and a graph neural network paper.
How the repository is organised on disk
The repository is a Markdown document plus one image. The README embeds ct_intersection_ml.png, a diagram of the intersection between the two fields, and the rest of the file is nested bullet lists of links. There is no package structure described in the material, no setup.py or pyproject.toml mentioned, and no tests. The primary language is listed as Python, but nothing in the README shows Python code, a module, or an importable name. Treat the language field as metadata about the owner's other work rather than a description of this repository's contents.
Because the content is plain Markdown, the data flow is trivial: a contributor edits the README, opens a pull request, and the list changes. The README explicitly invites this, saying that papers may be missing and that contributions or suggestions are welcome via pull request or issue. There is no database, no generated site, and no build step. That means the list's accuracy depends entirely on human review of pull requests, and there is no automated check that a link still resolves.
One consequence is worth stating plainly. The repository has no releases, per the supplied metadata, and the README does not describe a versioning scheme. If you cite this list in a paper, cite the commit you read, not the repository name, because the content is a moving target.
Reading the headings as a map of the field
The top-level split tells you where the work has concentrated. Theses come first, including a survey titled Towards a Categorical Foundation of Deep Learning and a thesis on category-theoretic data structures for learning polynomial circuits. Putting theses at the top is a reasonable editorial choice: a thesis usually contains the background a newcomer needs, which the README itself does not provide.
General deep learning is the largest block and contains the entries most often cited in this area, such as Categorical Foundations of Gradient-Based Learning and Backprop as Functor. Below that, the Equivariance section collects work connecting group representation theory to network architecture, and the Graph Neural Networks section collects sheaf-based and diffusion-based approaches. The presence of a sheaf cluster inside the GNN heading is the clearest signal of a live research direction rather than a historical one.
The README is truncated in the supplied material, so I cannot say how many headings exist in total or what the later ones are. If your interest is in an area that would sort alphabetically or thematically after graph neural networks, check the live file before assuming it is absent.
How you actually use it, and what you cannot do with it
There is no installation step. You clone the repository and open README.md, or you read it in the browser on the default branch, master. The only commands the material supports are the standard ones for getting a copy:
git clone https://github.com/bgavran/Category_Theory_Machine_Learning.git
After that, the workflow is reading, not running. There is no configuration file, no environment variable, and no command-line entry point described anywhere in the README. Anyone who arrives expecting to pip install something and train a model will find nothing to install.
If you want to contribute, the README names the mechanism: create a pull request or open an issue. There is no contribution guide quoted in the material, no style rule for how entries should be formatted, and no stated policy on what counts as relevant. In practice that means a contributor has to infer the format from the existing bullets, which are consistently a bracketed title followed by a link. That is a low bar to clear, and also a reason the list can drift in quality over time.
The image file is the only asset. If you want the diagram for a slide deck, ct_intersection_ml.png is the file to look for at the repository root, but the licence question below applies to reuse.
The gaps that matter: no licence, no releases, no code
The supplied metadata lists the licence as unknown, and the README does not state one. For a bibliography this is not a trivial omission. A list of links to papers is a compilation, and whether you may copy it into your own course notes or internal wiki depends on the terms the author chose. Absent a licence file at the repository root, you should assume no permission has been granted and link to the repository instead of copying its contents. That is a practical caution, not legal advice; if reuse matters to you, ask the maintainer through an issue.
The second gap is staleness. The last push recorded in the metadata is 2026-07-29, which tells you the repository was touched recently, but it does not tell you which sections were touched. A single added link at the bottom refreshes the timestamp without updating the theses list. There is no changelog in the material, so you cannot tell from the outside which parts are current.
The third gap is the absence of releases. There is no tagged snapshot to cite, which matters if you are writing something that needs a stable reference. The workaround is to cite a specific commit hash, which the material does not provide but which any Git host will show you.
Finally, this is the wrong tool if you need to evaluate a method. A list entry gives you a title and a link. It does not tell you whether the paper's construction has been implemented, whether it scales, or whether anyone has reproduced it. For that you need the papers themselves and their code, which this repository does not track.
Compared with a survey paper on the same topic
The obvious alternative is a survey, and the README itself lists several, including Category Theory in Machine Learning and Towards a Categorical Foundation of Deep Learning. The difference in approach is structural. A survey is written once by authors who commit to a narrative: they define the shared vocabulary, explain why one construction generalises another, and state which open problems they consider important. It is a finished argument with a date on it.
This repository is the opposite. It is a flat index with no narrative, no definitions, and no claim about which papers matter more than others. That makes it broader and more current than any single survey, because adding a link costs nothing, but it also means the reader has to supply the connections. Two papers sitting under the same heading may use incompatible notation, and nothing in the README will warn you.
The right way to use both is sequential. Take a survey from the theses or general section to get the vocabulary and the mental model, then use the index to find what has appeared since. If you only read the index, you get a reading list without a spine. If you only read the survey, you miss everything published after it.
Maintenance cost and who should keep it
The maintenance burden here is editorial, not technical. There is no dependency to upgrade, no CI pipeline to fix, and no API that can break. What decays is link health and coverage. arXiv identifiers are stable, but the README also links to university PDFs and event pages, and those move. The entry pointing at a SyCo event PDF and the one pointing at an Oxford ACT preproceedings page are exactly the kind of URLs that rot when a department reorganises its site.
For a user, the cost of relying on this list is the cost of verifying entries yourself. Before citing a paper you found here, open the link. Before assuming a subfield is covered, check whether the section exists in the current README rather than in your memory of it.
For a maintainer, the cost is judgement. The README's own admission that papers may be missing is honest, but the harder problem is deciding what to exclude. A list that accepts everything becomes a search result again, which defeats the purpose. The sections that work are the narrow ones, where the boundary is visible: Equivariance and Graph Neural Networks are defined well enough that a contributor can tell whether a paper belongs. A section called General Deep Learning has no such boundary, and it shows in the length of that block.
If you are deciding whether to depend on this repository, the answer turns on what you need. For a literature review, a seminar syllabus, or a starting point before reading a survey, it does the job. For anything that has to execute, it does not, and no amount of reading the README will change that.
Editorial conclusion
Adopt this list if you are a researcher or graduate student who already knows basic category theory and needs to find the papers connecting it to deep learning, equivariance, graph neural networks or sheaf methods. Do not adopt it if you are looking for a Python library, a pip-installable package or a runnable baseline; the repository is a Markdown bibliography and the README describes it as a list of papers. Before relying on it, open the README and check two things: whether the section you care about has been updated recently, and whether the licence file exists at the repository root, because the supplied material does not name a license and that determines whether you can reuse the list itself in your own documentation.
Community notes