Contributing

Thanks for your interest in adding to the Cellular Agriculture AI Library. This repository is a curated collection of papers, software, datasets, and other resources at the intersection of cellular agriculture and AI. We welcome suggestions from researchers, engineers, students, and anyone working in or learning about the field.

Two ways to contribute

You don’t need to know Git to suggest a resource.

Option 1, Open an issue (no Git required)

Pick the template that fits and fill it out:

• Suggest a paper: for peer-reviewed papers and preprints. Asks for DOI, AI methods, and research areas.
• Suggest software, a dataset, or other resource: for entries that would go in Software.md, the Datasets/ directory, Databases.md, or OtherResources.md.
• Propose a new research area: for a new column in the Papers.md matrix.
• Report an issue with an entry: for something already in the library that is wrong, rather than something missing.

A maintainer will incorporate accepted suggestions. This is the right path if you’re not comfortable with pull requests or just want to flag something quickly.

Correcting an entry that is already here

Every catalogued item carries a permanent id (paper:214, sw:cellpose, db:string, ds:chickengtex-portal), and on the documentation site the entry cards on the Papers, Software, Databases and Datasets pages each have a Report an issue link that carries their own id to the report page. Starting from there is worth the click: a correction naming the id points at exactly one entry, where one describing a page is a search before it is a fix. That page also offers email and Slack routes for anyone without a GitHub account.

Rows in a dataset page’s ## Complete data inventory table are listed rather than carded, so they have no such link. Quote the accession and the page instead, and a curator can find the row from that.

Letting your AI agent draft the suggestion

If you work in Claude Code, the caail-contribute plugin fills in the paper and resource forms above for you. When you’re reading a paper or evaluating a tool, it checks whether CAAIL already indexes it, and if not it composes a prefilled issue link from what it read. You review and submit it yourself; it never files anything on your behalf. Corrections to entries that are already here stay a manual job, via the report page linked above.

claude plugin marketplace add tucca-cellag/caail
claude plugin install caail-contribute@caail

It’s a separate install from the caail query plugin, so you can take either one alone. A file named .caail-no-contribute in the directory you started Claude in silences it there. (The directory you started in, not the repository root: the plugin gives up its shell access while it runs, so it has no way to resolve a repo root, and an opt-out it could not find would be worse than none.)

Option 2, Open a pull request

Faster to merge, and you get authorship credit in the Git history. Branch from main (e.g. feat/papers-cosenza-2024, docs/add-bioprocess-section), apply the change directly, and open the PR back against main. The format guides below tell you exactly what to edit.

Adding a paper to Papers.md

How the structured catalog is maintained. The matrix + references in Papers.md, the entries in Software.md / Databases.md, and the Datasets/*.md inventory tables are generated from an in-repo SQLite database (issue #78); the committed Markdown is the rendered output. You can still contribute exactly as described below: open an issue, or open a PR editing the Markdown, and a maintainer lands it through the DB so the ids and cross-references stay consistent. (Editorial prose in those files is hand-authored as normal.) Maintainers: see the caail-db-authoring skill for the DB workflow.

First decide which kind of paper you’re adding, the file has two homes for entries:

• Primary research (a paper applying a specific AI method to a specific cell-ag problem) → goes in the matrix + ## References section. Most papers go here.
• Review, perspective, position paper, or commentary (a paper surveying the field or opining on it rather than applying one method) → goes in the ## Reviews & Perspectives section only, with no matrix cell. See “Adding a review or perspective paper” below.

Primary research

The matrix and the ## References list must be kept in sync:

1. Pick the next ID. Scan both the ## References list and the ## Reviews & Perspectives section for the highest existing <a id="N"> number and use N+1 (the two sections share one numeric counter). Reference IDs are permanent: please don’t renumber existing entries, since the matrix cells (and any external links) point at them by ID.

2. Append the reference at the end of the ## References section in APA style:

   <a id="42">42</a> Author, A. B., & Coauthor, C. D. (2024). Title of the paper. *Journal Name, 12*(3), 456–478. https://doi.org/10.xxxx/yyyy

   • Use APA style, with the journal name italicized (*…*) and the DOI as a full https://doi.org/... link.
   • List all authors, don’t abbreviate to “et al.” in the reference list.

3. Add any trailing blockquotes the paper needs. If it has associated code:

   > **Code**: https://github.com/<owner>/<repo>

   If the publisher has issued a post-publication notice that leaves the paper standing (a correction, erratum, corrigendum, addendum or expression of concern), record that under its own DOI in the same way, whether or not the paper also has code. Label it with the publisher’s own word for the notice, whatever that is, never a generic one: an expression of concern filed under Correction tells the reader an error was fixed when nothing was. A retraction is not covered here, because it raises the separate question of whether the paper keeps its matrix cells at all; propose it in the issue rather than recording it as a blockquote.

   Where a paper has both, each blockquote is separated from the next by a blank line:

   > **Code**: https://github.com/<owner>/<repo>
   
   > **Correction**: https://doi.org/<correction-doi>

   The blank line matters: GitHub renders two adjacent > lines as one run-on line, and GitHub is where these are read. Note that the notice reaches GitHub but not the entry’s card on the site, because the parser keeps only the Code and Data labels (tucca-cellag/caail#202).

   As the callout at the top of this section says, the reference, its matrix cells and these trailing blockquotes are all regenerated from the database, so editing the Markdown here proposes an entry rather than landing one: a maintainer re-enters it through the DB. The easiest way to propose one is to write the entry out in the issue or the PR description. That is all a maintainer needs, and it keeps CI meaningful. If you do edit the Markdown, CI’s DB-to-Markdown sync guard will fail, because the generated file now disagrees with the database. That is expected rather than a mistake on your part, but it leaves the branch red, and a real problem pushed to it afterwards is then hard to tell apart from the expected failure.

4. Add the paper to every applicable matrix cell. For each AI method (row) and research area (column) the paper covers, add [42](#42) to the corresponding cell, comma-separated with any existing entries:

   | [Bayesian Optimization](...) | [2](#2),[3](#3),[42](#42) | ... |

   The matrix rows are the AI/ML methods currently in Papers.md: from classical ML (Bayesian Optimization, Deep Learning, GNN, …) through the foundation-model and agentic families. Each row label links to its definition in Taxonomy.md; the live set is whatever Papers.md contains. Pick the row(s) that match; if none fit, add one (step 5).

   Current matrix columns (research areas): Media Optimization, Cellular Engineering, Bioprocess & Scale-Up, Scaffolding, Sensory Prediction, Metabolic Modeling, Food Safety Prediction, AI Tooling / Methodology.

5. If the paper uses an AI method that isn’t yet a row, add a new row. The row label should link to the Wikipedia article for that method (so the link stays stable):

   | [Reinforcement Learning](https://en.wikipedia.org/wiki/Reinforcement_learning) | | | [42](#42) | | |

6. If the paper covers a research area that isn’t yet a column, see “Adding a new research area” below.

7. The AI Tooling / Methodology column is for papers about general-purpose AI methods or agent frameworks that don’t yet have a specific cell-ag application (e.g. a paper introducing a biomedical AI agent that could be applied to media optimization). When a follow-up paper applies one of these tools to a specific area, it goes in that area’s column instead.

Before opening the PR, double-check that every matrix [N](#N) you added resolves to a reference entry, and that your new reference is reachable from at least one matrix cell.

Cite the methods section, not the abstract. A placement is a claim about what a paper did, and papers routinely name one method in the abstract while the methods section names three. Tell us which section you read from and, where the paper’s own naming is unhelpful, quote the heading. Curation Methodology describes how a maintainer verifies a placement and what makes some papers harder than others.

Adding a review or perspective paper

Reviews, position papers, and commentaries don’t participate in the matrix. Add them to the ## Reviews & Perspectives section instead:

1. Pick the next ID (same counter as primary references, see step 1 above).

2. Append the reference at the end of the ## Reviews & Perspectives section, in the same APA format as primary references:

   <a id="43">43</a> Author, A. B. (2024). Title of the review. *Journal, vol*(issue), pp. https://doi.org/...

3. Do not add a matrix cell: reviews stay out of the matrix.

If you’re unsure whether a paper is “primary research” or “review/perspective,” err on the side of the matrix when the paper has a clear single contribution (new method, new application) and on the side of Reviews & Perspectives when it surveys multiple methods or zooms out to the field as a whole.

Adding software, datasets, or other resources

Software.md and Databases.md

Use the existing hierarchical structure. Each entry is an H3 link, followed by a one-paragraph summary:

## <Application area>
Short framing paragraph (optional if the section already exists).

### [<Tool or database name>](<canonical URL>)

Summary: One to three sentences describing what it is and, importantly, *how it applies to cellular agriculture*, not just what it does in general.

• For software, link to the project’s GitHub repo (or canonical home if not on GitHub).
• For databases, link to the database’s primary canonical home (UniProt, KEGG, ChEMBL, etc.).
• Group new entries under an existing section if one fits. If none does, add a new ## section.

The Datasets/ directory

Datasets/ is a directory of per-species pages, not a flat file, see Datasets/CLAUDE.md for the full per-page schema. To add a data resource:

• Pick the page. A species-specific data deposit (e.g. a bovine RNA-seq study) goes on its species page (Datasets/Cow.md, Datasets/Pig.md, …). Cross-species human pretraining corpora and reference GEMs go on Datasets/HumanReference.md; the CHO GEM family on Datasets/CHOReference.md; AI/ML benchmark datasets on Datasets/Benchmarks.md. If no species page exists for your species, propose a new one (mirror an existing sparse stub like Datasets/Goat.md) and add it to the index table in Datasets/README.md.
• Add a row to the page’s “Complete data inventory” table (Study (linked title), data type, tissue, a short description, dataset size, and area of research. If the deposit fits an existing thematic cluster on that page, mention it in the cluster prose too. A sparse stub page (e.g. Datasets/Goat.md) has no table yet) its “Complete data inventory” section is a placeholder note; when you add the first deposit, replace that note with a table by copying the column headers from a populated page such as Datasets/Cow.md.
• Link the canonical accession: the NCBI SRA/GEO/PRIDE, Mendeley Data, or Hugging Face landing page. If the source has no usable accession (data on request, supplementary-table-only), keep the entry with an explicit note rather than dropping it.

Picking between Datasets/, Databases.md, and OtherResources.md. CAAIL distinguishes between fixed train-on artifacts and living query/lookup resources:

1. Train-on artifacts → the Datasets/ directory. ML pretraining corpora, perturbation atlases, downloadable benchmark datasets, individual GEM model artifacts, per-species sequencing deposits.
2. Query / lookup resources → Databases.md. Repositories, ontologies, spectral libraries, structure / compound / pathway databases.
3. “Database” in the name, or any directory / registry / tracker → Databases.md: even when the content is people, companies, or regulation rather than scientific data.
4. Funding → Funding.md. Funding organizations (that fund the field) and funding opportunities (grant programs, research-portfolio mechanisms).
5. Non-funding ecosystem initiatives → OtherResources.md. Research centers, consortia, and convening initiatives that conduct or coordinate (rather than fund) cell-ag work.
6. Borderline cases → dual-listed. Resources that are genuinely both software and database (e.g. GNPS) get a full entry in their primary-home file and a short cross-referenced entry in the other.

Benchmark placement (Paper + Dataset + Database triangle). AI/ML benchmarks have a distinct artifact shape: a paper, a downloadable eval dataset, and (sometimes) a live leaderboard. Place each aspect in its appropriate file:

• Paper describing the benchmark → Papers.md with a > **Code**: blockquote anchoring the project’s canonical home.
• The data (questions / scenarios / spectra / sequences) + any bundled scoring code shipped with the data → Datasets/Benchmarks.md. The bundled scoring code is not a separate Software.md entry, it’s part of the dataset distribution.
• Live leaderboard or continuously-updated results tracker → Databases.md under “Benchmark Leaderboards & Results Trackers” (per rule 3, trackers belong in Databases.md).
• Separately-installable evaluation framework that brings its own data (e.g. a framework that scores models against externally-hosted data the framework does not itself distribute) → Software.md. CausalBench is the existing example: it’s a benchmarking framework, not a bundled-data benchmark, so it lives in Software.md and has no Datasets/ entry.

All entries cross-link via the established Companion to [Papers.md ref #N] convention.

Educational & contextual material: Talks.md, Primers/, ReferenceWorks.md, AwesomeLists.md, Funding.md, and OtherResources.md

Each is a bulleted list under category headings:

* [<Title>](<URL>)

Pick the file by medium and intent:

• Lectures, talks, and webinars → Talks.md (e.g. conference talks, the Broad Institute MIA series). The site renders Talks.md as inline players on /talks/, so prefer canonical YouTube watch URLs.
• Newcomer onboarding material → the Primers/ directory: field-overview videos, intro primers, learning playlists, and cellular-agriculture courses (newcomer entry points). Cell-ag orientation goes in Primers/CellAg.md; AI/ML learning material goes in Primers/AI.md. These render at /primers/cell-ag/ and /primers/ai/ with videos and playlists embedded inline, so prefer canonical YouTube watch / playlist URLs; internal cross-links to the rest of the library use repo-relative paths (e.g. ../Papers.md, ../ReferenceWorks.md).
• Reference textbooks and multi-volume reference works → ReferenceWorks.md: the foundational cell-ag textbook and the Encyclopedia of Meat Sciences, with DOI-resolvable chapter indexes.
• Curated bibliographies and “awesome lists” (community GitHub indexes) → AwesomeLists.md: rendered as searchable cards with GitHub star / last-updated metrics on /awesome-lists/.
• Funding organizations and funding opportunities → Funding.md (see rules 4–5 above).
• Journal editorials, opinion, and non-funding ecosystem initiatives → OtherResources.md: field commentary and the research centers, consortia, and convening efforts of the adjacent cell-ag universe.

If you’re adding a kind of resource that doesn’t fit an existing ## section in the chosen file, create a new ## section rather than mixing it into an existing list.

Adding a new research area

A research area is a column in the Papers.md matrix, backed by a deep-dive page under ResearchAreas/. To add one:

1. Create ResearchAreas/<AreaName>.md (PascalCase, no spaces, e.g. ProteinDesign.md). The file should give a short overview of why the area matters to cellular agriculture and what computational/AI techniques are being applied to it. Existing files like MediaOptimization.md are good models.

2. Define the column in Taxonomy.md and add it to the Papers.md matrix with the header linked to that definition, not to the deep-dive page. Taxonomy.md is the trusted scope for every row and column; the ResearchAreas/ page is an editorial companion.

   | | ... | [Protein Design](./Taxonomy.md#protein-design) | ... |

3. Register the page for the site in site/src/content/caail-pages.ts (group research-areas, with its own meta description). This is not optional: caail-pages.test.ts asserts every file in ResearchAreas/ has a map entry, so a page without one fails CI.

4. Link your new area from the README’s “What’s Inside” section if it stands as a primary entry point. (Not every research area needs to, small/exploratory areas can live only inside Papers.md.)

5. Backfill matrix cells for any existing references that also apply to your new area.

Adding a deep-dive page for an AI/ML method

The matrix has two axes, and they have separate homes. A research area is a column, written up under ResearchAreas/; an AI/ML method is a row, written up under Methods/. A method page goes in Methods/, never in ResearchAreas/.

That is a hard rule with a mechanical reason: counts.json’s researchAreas figure is derived by counting the *.md files in ResearchAreas/, and the homepage labels that number “Research Areas”. A method page placed there would silently inflate a public statistic that says it is counting something else.

1. Create Methods/<MethodName>.md (PascalCase, no spaces, e.g. BenchmarksEvaluation.md), naming the matrix row it covers. The shape the row pages share is a scope boundary against the rows it is confusable with, then one ## section per matrix column the row occupies, then adjacent-method and further-reading footers; Methods/GNN.md is a short example of it. Methods/BenchmarksEvaluation.md predates that convention and is organized by benchmark family instead, so copy it only if your row genuinely groups that way.
2. Do not add a matrix row for it. A page describes a row that already exists; adding a row is a separate, deliberate change that needs its Taxonomy.md definition in the same commit.
3. Register it for the site in site/src/content/caail-pages.ts (group methods, with its own meta description). The sidebar entry, the route and the link-rewriting guard all derive from that map. As with a research-area page this is not optional: caail-pages.test.ts asserts every file in Methods/ has a map entry, so a page without one fails CI.

What is optional is whether a row has a page at all: a row is never blocked on one being written, and a new row may land with its Taxonomy.md definition and no page. The three steps above are not optional once you decide to write one.

Citation style

We use APA throughout Papers.md. In short: author last name, initials, year, title, italicized journal/venue, volume(issue), pages, DOI.

Author, A. B., Coauthor, C. D., & Third, E. F. (2024). Title of the paper. *Journal Name, 12*(3), 456–478. https://doi.org/10.xxxx/yyyy

• Italicize journal/publication names with *…*.
• DOI as a full https://doi.org/... link (not dx.doi.org, not a bare DOI string).
• List all authors in the reference; the [N] matrix anchor serves as the in-text abbreviation.

Pull request checklist

Before opening a PR, please confirm:

• Your branch is off the latest main and uses a <type>/<slug> name (e.g. feat/papers-..., docs/...).
• All new links resolve (no 404s).
• For Papers.md changes: every new reference is reachable from at least one matrix cell, and every new matrix [N](#N) resolves to a reference.
• No existing reference IDs were renumbered.
• Commit messages follow Conventional Commits (Angular flavor), e.g. feat(papers): add Cosenza 2024 multi-fidelity BO paper.
• The PR description mentions which research area(s) and AI method(s) the change covers, so reviewers can spot-check the matrix updates.

Licensing of contributions

This repository is licensed under the MIT License. By submitting a contribution (pull request, issue, or other form), you agree that your contribution is offered under the same license, and you confirm that you have the right to do so. We don’t host copyrighted abstracts or full text: please link to the canonical source instead, since third-party content stays under its original license regardless of CAAIL’s.

Questions

If you’re not sure whether a resource fits, how to categorize it, or how to format an entry, open an issue using one of the templates above and a maintainer will help. We’d rather guide you than have you not contribute.

Suggestions are also accepted in Slack, without opening an issue. Resource suggestions go in #feature-requests and questions in the relevant question channel; a maintainer will move an item to GitHub once it is ready to become a change. Community.md lists the channels and the join link. Slack, the issue tracker, and code review are all governed by our Code of Conduct.