One example is small, clean, intent-only — try to regenerate the code from the docs alone. One is a complete, working project — the whole chain from design through tests to code, public and clonable. And one is real, long-running, and messier than any pedagogical example could honestly be. Three lenses; they answer different questions.
A deliberately small fictional project. HLD, a handful of LLDs, EARS specs — no implementation. The challenge: hand the docs to a fresh agent and ask it to build the system. Run it twice and you may get two languages — when docs are the source of truth, code is output.
examples/urlshort/
Ships in the repo alongside the plugins.
A real, public project built with LID end-to-end: an HLD, eleven LLDs, 350 EARS specs, and the tests and code that cite them. A CI gate makes the linkage mechanical — the build fails unless every spec is cited by at least one test and every citation resolves to a defined spec. The linkage the home page describes, enforced in public.
Start with the README's guided tour — five files, read in order, from one design doc down to the CI gate that binds it.
A working project that has used LID for months. The LLDs are striated — multiple generations, uneven coherence, the honest shape any living system acquires. A stress test for cascade discipline, and evidence of how LID ages under real conditions.
The live product is at threadkeeper.app. Internal design docs aren't public, but the shape of the project shows LID at work over time.