Waywyrd

Waywyrd is my current venture, and the clearest example of how I think AI should be used: narrowly, honestly, and in service of a practice rather than as the product itself.

Most rune apps are either shallow fortune cookies or walls of text that blur what the historical record says with what someone invented last decade. I wanted a practice tool that respects the source material, feels like holding real stones, and uses a model to read a cast in context without making things up about the lore.

It also had to be small, private and fair by design: shared the way good things are, friend to friend; usable offline; a firm line that an admin can never read anyone's journal; and never a charge for a reading.

I designed and built the whole thing: research, brand, UI, data model and AI layer.

• Three strands of research. Before building, I researched three strands and reconciled them into one corpus: rune lore (the rune poems, Tacitus, the inscriptions), sky lore (the Norse calendar, moon and day-gods) and stone lore (northern stone tradition and archaeology). Every correspondence carries a provenance label (attested, reconstructed or modern) plus a confidence code, and where the design prototype disagreed with the research, the research won, with each decision recorded.
• A reading in three dimensions. A cast is read against all three at once: the stone drawn, the night's sky threads (day-god, moon phase, half-month) and the lore behind each. That gives the model a structured, sourced context rather than a vague prompt, and gives me a controlled environment to evaluate models in.
• A multi-model gateway. Every model call goes through one gateway with a provider layer: Claude on Amazon Bedrock today, and open-weight models through Ollama (cloud or local) on the same interface. Per-model capabilities, a price table and one active model, switched in admin. The lore corpus sits in a byte-stable system block so it caches, and user text only ever goes in the user message.
• Four ways to the well. Cast with me takes a question, and the well suggests a spread and the order to turn the stones. I've already cast logs stones thrown by hand. One stone draws a single rune for the day. Look back searches past readings by question or rune.
• A ritual, not a chatbot. Breaths before the cast, stones that scatter with physics into centre, edge and off-cloth zones, and a reveal where each stone flips, carves its rune stroke by stroke, then lights in ember. The reading arrives as a short counsel first, with the full reading stone by stone behind it, and always names the model that wrote it.
• Lots on the white cloth. Tacitus' method as he describes it: twenty-four lots scattered, three taken up, and the asker, not the model, judges the answer. A "no" locks the question until midnight, enforced on the server.
• The journal. Kept readings gather with their stones and threads, and members add notes over time on what happened and whether it bore out.
• Lore you can see. Seven stone sets, including Lore stones where each rune gets its researched stone in its own material, and a reference where every rune opens to its poems, its stone and its sky.
• Bindrunes and altars. A bindrune designer whose analyser finds runes hidden in the joined strokes (the same analyser checked the brand mark), and an altar wizard that goes from an intention to suggested runes, the best evening to work, and a drafted invocation.
• The hearth. No reading is ever charged for. Following the old custom of honouring a reader with hospitality and gifts, members may give to the app's keeping, asked at most once a season. A gift brings recognition and invitations to share, never higher limits or anything that reaches a reading.
• Friends invite friends. Growth is by single-use invitations with tracked lineage, and giving is what grants more of them.
• Private by default. Supabase Auth with row-level security, and an offline shell with an IndexedDB queue for journal and altar edits.

What "tuned to purpose" looks like in practice. The model gets a narrow job (a few grounded sentences about one stone and one night), a researched corpus it can't wander outside of, and a UI that shows its sources and names the model on every reading. Members choose, before their first draw, whether modern lore is shown at all.

It is also built for comparing models, not marrying one. Claude runs the rollout; next I'm evaluating other models, open-weight ones included, on two questions: how well they interpret a cast, and how well they adapt to a tightly controlled context. The three-strand corpus is what makes that comparison fair, because every model reads the same sourced material.

And it shows product judgment beyond the model: prompt caching as an architecture decision, access rules enforced in the database rather than UI code, a one-viewport layout rule with a checker, and a giving model designed so that generosity never touches the answers.