How this index is compiled, and where it is wrong.

An entry qualifies if it is infrastructure — something a production AI system runs on — rather than a product a person uses. That single rule is what separates this list from the directories that index applications, and it excludes most of what is called an AI tool.

Reading material, courses and archives sit outside the stack deliberately. They are listed in Learning & Reference, drawn detached from the stack frame, because a paper about attention is not a layer of your system.

Tools are hand-picked, not submitted. There is no submission form that results in an entry. This is a real constraint on coverage, and it is the source of most of what follows in Where this index is wrong.

Sections are ordered as a dependency chain, layer 1 being the substrate everything else runs on. You cannot tune weights before you serve them. You cannot evaluate what you cannot observe. The order is the argument; the categories are a consequence of it.

Most directories in this space have the right categories and no order — which means they cannot answer the question a reader actually has, which is where does this sit relative to what I already run. That question is what Start Here is for.

The nine layers also collapse into three bands. This is a convenience for the palette, but it is a claim too: most production problems live in exactly one band.

A second axis cuts across all of it: specialisation. Layers describe where a tool sits; a role describes what a person is accountable for, and those are not the same partition — a platform engineer owns routing and orchestration and the evals that prove the whole thing works, which crosses all three bands. So roles are assigned separately, deliberately overlap, and no tool carries more than two. A seniority axis (senior, staff, principal) would not work: those people need the same tools, so it would filter to nothing while looking like it worked.

• Band I · Compute — layers 1, 2, covering Inference, Routing. Usually sounds like too slow, too expensive.
• Band II · State — layers 3, 4, covering Retrieval, Training. Usually sounds like wrong answers.
• Band III · Control — layers 5, 6, 7, 8, 9, covering Agents, Workflows, Guardrails, Prompts, Evals. Usually sounds like unreliable, unmeasured.

Every tool carries two sentences, and the second is the one that matters. Not a rating, not a star count, not a score out of ten — a statement of the condition under which you should pick something else.

This is deliberate asymmetry. A directory that only tells you when to use something has no reason to tell you the truth about anything else. The skip when line is what makes the use when line worth reading, and it is the half that essentially nobody else publishes.

Both lines are written to be falsifiable. If a sentence here cannot be checked against a real deployment, it does not ship.

Licence, cost and deployment facts rot, and a confident stale figure is worse than an absent one — it changes architecture. So this index is gated: if any entry’s facts were last confirmed more than six months ago, the build throws and the site does not deploy.

That is a different class of claim from “updated daily”, because it is enforced rather than asserted, and it produces a receipt — the build log. The date on each tool page is the date of a check that demonstrably happened.

Every one of the 112 entries was last confirmed in 2026-09. 73 of them are self-hostable. Every licence is confirmed rather than guessed.

The receipt is public. Every build writes /verification.json — the rule, the date it was enforced, and each entry’s check date and the month it expires. Nothing in it is hand-maintained; it is generated from the same dataset the guard reads. The dataset itself is published as /tools.json for anything that would rather parse than scrape.

The section is the point of the page. A methodology that lists no limitations has not been stress-tested.

• It is small on purpose, which is also small.

  112 entries against directories publishing 50,000, 30,925 and 2,840. Hand-picking is a reason for that and not an apology for it, but the honest consequence is that whole projects will be missing — including good ones. The index is biased toward what is well-documented and English-language-first.

• Nothing here is benchmarked.

  No figure on this site was measured by Lattice. Throughput, recall, latency and cost claims in the comparison tables are reported by vendors or by third parties, read from primary documentation, and were correct when read. Where those sources disagree, the disagreement is not reproduced. Treat every number as a pointer to something you should verify yourself.

• Popularity is not used as a signal at all.

  Ordering by stack depth instead of popularity is the core position and it has a real cost: it is blind to momentum. A tool that is obviously going to be important next year can be absent today, because nobody has written the article explaining why yet.

• The layer model is a simplification.

  Real systems are not nine clean bands. Teams routinely couple layers the index treats as separate, and several entries straddle two. The ordering is a useful default, not a constraint on reality.

• Role assignments are judgement calls, and the overlap is the point.

  Nobody can derive which job owns a tool from the tool itself. An eval framework genuinely belongs to a platform engineer and an applied engineer, which is why roles overlap and the counts on /roles do not sum to 112. The cap of two per tool is enforced at build time precisely because an axis without a cap decays into a synonym for “popular”. Treat the assignment as an opening argument and tell us where it is wrong.

• Coverage is uneven by construction.

  Layers with more public writing about them get better entries, and an entry count is the crude, mechanical proxy for that. By count, Retrieval is the fullest layer and Guardrails is the thinnest. The thin layers are where a vendor’s marketing is most likely to outrun an independent reading; the counts are charted below so this can be checked rather than taken on trust.

• Freshness is not the same as accuracy.

  The six-month gate guarantees someone looked. It does not guarantee they were right, and it cannot detect a tool that was never honest about its licence in the first place.

• There is no ranking, and that is a choice.

  You will not find a “best X” page here. A ranking is a claim that one tool is best for a reader whose constraints are unknown, which is a claim nobody can verify. Where a comparison names one option, it is because the constraints were specific enough to justify it.

Two kinds of correction are treated as urgent. A wrong licence or a wrong deployment model, because either can change an architecture decision. A missing tool that has become load-bearing, because the index’s value is proportional to its coverage of what matters.

Slower to change, honestly: the use-when and skip-when lines, because those are judgements and re-litigating them on request would make them worse. If one is wrong, the argument for why is usually in an essay, and disagreeing with the argument is a better route than asking for the conclusion to be edited.

Corrections and suggestions — and note that a submission only becomes an entry if it clears the same bar as everything already here.