Submit · reviewed by a person
Submit a tool
This index is ordered by stack layer rather than popularity, which only means something if the order is deliberate. Every entry was placed by a person who decided where it belonged and why. A submission is a proposal for that decision, not a request to skip it.
Before you submit
- Is it infrastructure — something a production AI system runs on — rather than an application someone uses? That single test excludes most things called AI tools.
- Does it have a situation in which it is the wrong choice? A tool with no such situation has usually not met production yet.
- Is it already listed? If so, a correction is more useful than a submission.
Open a submission issueRequires a GitHub account
The form
Copy this into the issue body. The field names and the fence markers have to survive editing — the bot reads them, and a renamed field arrives empty.
<!-- Lattice submission. Everything below is read by a bot that drafts a pull request — you will not see the pull request yourself, a human reviews it. Edit the values between the fences. Keep the fence markers and the field names exactly as they are; if you change a field name, that field arrives empty. Nothing here is published as-is. A human decides whether the tool is infrastructure, which layer it belongs to, and whether the use/skip lines survive review. --> ### Tool name ``` The product name, as it writes its own name. ``` ### Homepage ``` https:// ``` ### Repository ``` https://github.com/owner/repo Leave as "none" if the project is closed source. ``` ### Which layer do you think it belongs in? ``` 01 Inference & Serving 02 Routing & Gateways 03 Retrieval & Vector Stores 04 Fine-tuning & Training 05 Agent Frameworks 06 Workflow Orchestration 07 Guardrails & Safety 08 Prompt Engineering 09 Evaluation & Observability ``` ### One sentence: why it belongs on this index at all ``` Not "it's a great tool" — what does a production system *run on* because of it? ``` ### Use it when ``` One clause. The situation in which this is the right choice. ``` ### Skip it when ``` One clause. The situation in which it is the wrong choice. This is the harder one, and the more useful one. An entry with a skip line is one a reader can act on; an entry without one is a link. ``` ### Anything the reviewer should know ``` Pricing that changes often, a licence that is unusual, a deployment that is self-hosted in name only — whatever is not obvious from the links above. ```
The nine layers
Pick the one you think it belongs in. Guessing is fine and expected — the reviewer will disagree, and that disagreement is the useful part.
What happens next
- Does submitting get my tool listed?
- Not automatically, and often not at all. A maintainer reads every submission and decides whether it clears the bar described on the methodology page. Most submissions are declined, and the commonest reason is that the tool is an application rather than infrastructure a production system runs on.
- What does the reviewer decide?
- Three things a bot cannot: whether the tool is infrastructure at all, which layer of the stack it belongs to, and whether the use-when and skip-when lines survive scrutiny. The submission carries your sentences as proposals; the index's own judgement is separate and yours to disagree with.
- What happens to my submission?
- It becomes a public GitHub issue on this repository, and then a draft pull request that nobody can merge without a human editing it. If it is declined, the reason is written on the issue. Corrections to existing entries are handled the same way and are treated as more urgent than new submissions.
- Why GitHub issues instead of a form?
- An issue needs no database, no spam protection and no third-party form service, and it keeps the whole conversation searchable and public. The trade is that it requires a GitHub account, which is a real cost for someone who only wants to send one link.
- The skip-when line is the hard one. Why?
- Because it is the line most directories leave out, and leaving it out is what makes a list a list of links. If a tool has no situation in which it is the wrong choice, that is usually a sign the tool has not been used in anger yet, and it belongs in a different index.
Corrections to entries that are already here are treated as more urgent than new submissions — a wrong licence or a wrong deployment model can change an architecture decision. The same issue link works; say which entry in the notes. The bar is written out on the methodology page, including where this index is wrong.