The panel gives the numbers. This page gives the why — why the study is built from the sources up, how the four moves of the engine feed each other, and why the infrastructure, not a quick result, is the point.
The obvious way to build a "grammar of meaning across traditions" is to ask a large language model what the world's traditions say. That path is fast — and quietly broken. An LLM's picture of religion is its training data's picture: overwhelmingly Western, Anglophone, and recent, weighted toward whatever is most abundant online. Ask it about "the self across traditions" and you get a confident synthesis shaped by that lean — with the gaps invisible.
So this project does the slow thing instead. It builds bottom-up, from primary sources — harvesting the actual texts from each tradition's own archives and scholarship (including the non-Western, non-Anglophone ones most tools never reach), coding them first in each tradition's own vocabulary, and letting patterns emerge from the texts rather than from a model's prior.
The corpus is not an illustration of a thesis; it is the evidence, gathered before the argument.
— Grammar of Meaning · on why it's built this way
This is the whole reason the infrastructure exists. The acquisition engine is built to reach past the easy, English, already-digitized sources — to route a question about (say) St. Paul to African, Latin American, and Japanese scholarship with the same priority as a Princeton journal. The bias-visible tagging is built so the corpus's real skew is shown, not smoothed over. The ground-up coding is built so no imported category pre-decides what a tradition "must" be saying. Take the infrastructure away, and you are back to the model's lean.
The live snapshot — the counts by tradition and family, and the honest skew laid bare — lives on the home page, kept in one place so the numbers can't drift. What matters here is the shape of it. Breadth is not a vanity metric: a cross-tradition pattern can only be trusted if the traditions were gathered independently, in their own terms. And the skew is real and named, not hidden — the corpus leans Abrahamic (a bias inherited from centuries of uneven text-production and digitization, not a choice to foreground any one tradition).
The load-bearing methodological move is to document the skew rather than hide it. Pre-filtering to "balance" the corpus would bury the bias behind a curatorial decision; showing it — and then working deliberately to reach the under-represented archives — is both more honest and more correctable. The "Pending review" and "Other" buckets belong to the same discipline: rows are tagged and kept visible, never force-sorted or dropped. It is the project's CARE commitment made concrete.
The engine turns scattered archives into a corpus you can actually put questions to. Four moves feed each other in order: Acquire → Store → Index → Code. Three of them moved this week (engine status as of July 2, 2026); the fourth is still ahead.
Reading: the four moves are not equal in maturity, and the diagram says so — fern = built & verified, honey = underway, dashed terracotta = the frontier, not yet begun. Everything to the left of Code is the substrate that makes honest coding possible. · Want to watch one idea travel the whole engine? See one idea join the library → (the Tengri walkthrough).
Find and fetch primary sources across ~4,700 catalogued archives, reaching deliberately past the Anglophone default — the Parity Principle: an African journal on a topic fires with the same priority as an American one.
Hold ~9.8M passages durably. This week the corpus moved off a single laptop file into cloud infrastructure — the shift from a personal database to the shared, durable store a decade-scale project needs.
Embed passages so the corpus is searchable by meaning, not just keyword — and, deliberately, index the most-easily-overlooked material first, so marginalized readings are findable rather than buried.
Read each passage and name what it is doing, in the tradition's own vocabulary. This is where scattered texts become analyzable observations — and no cross-tradition patterns have been drawn.
Why are the tests 453 of 457, not all green? Because that is the honest part of the story. Running the full suite — rather than a convenient subset — caught a real production bug: after the cloud cutover, the acquisition cart's database write was broken by a SQL-dialect difference. We found it and fixed it. The four remaining reds are a separate, tracked follow-up (integration tests need isolating from the live database). "Tests pass" is not the same as "fully running," and the funnel below says exactly how far the machine actually reaches today.
The remaining work is operational, not architectural — fire the endpoints that have never run, tag the ones not yet buildable, build the handful of spec'd-not-built scripture archives (a bias-visibility win: MENA and East-Asian scripture). That is throughput, not invention.
The infrastructure is the argument.
— Grammar of Meaning · the longevity case
This is a decade-scale project, not a demo, and the engine is built accordingly. The point is not a clever result next month; it is durability and extensibility — a corpus and a method built to outlast any single thesis, published openly so others can audit, extend, and contest them.
It sits in a deliberate lineage — but adds the thing those forebears mostly withheld: the open methodology and tooling. The how travels, not just the what.
Moving to durable storage, hardening the pipeline with tests, documenting every decision, building the bias-visibility and CARE disciplines in from the start — none of it produces a headline. All of it is what lets the project still be trustworthy and extensible in ten years.
The corpus and the method are published so others can build on them. That is the deliberate trade: infrastructure now, so the findings, when they come, rest on something that holds.
This is a designed callout, not an apology. The whole method is arranged so that when coding does begin, it begins on honest ground: primary sources, read in each tradition's own vocabulary, with the corpus's skew visible rather than smoothed away.
And the question that coding is built to answer is a rhyme: not whether traditions agree, but whether they make the same move underneath their different answers. A rhyme is the same move made in a different voice. That is the frontier — and this page will keep saying exactly that until it is crossed.
More explorations will land here as the engine grows — each a card, not a rewrite of this page.