DEV Community: Blaise Labs

From Spec-Driven to Faith-Driven Development

Blaise Labs — Sat, 31 Oct 2026 14:49:06 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

I have a small tool called specdeck that keeps a project's rules as requirements, each with a statement, a reason and a check. Here's one from an example shop project.

- id: rules.decimal-money
  statement: Money amounts shall be Decimal values, with no float anywhere in the shop package.
  rationale: A float total once made a refund one cent short and the accounts would not reconcile.

For this week's challenge I added one layer on top. It takes the reason behind each rule and goes looking for it in a spiritual text you choose. When an agent then puts a float in the money code, this is what comes out.

specdeck: rule rules.decimal-money broken
  "Ye shall do no unrighteousness in judgment, in meteyard, in weight, or in measure." (Leviticus 19:35)
FAILED tests/test_rules.py::test_money_never_touches_float

I know how that sounds. It's a little funny, and I think that's fine. But the verse is also correct. Somebody really did care about short measures thousands of years ago.

What I Built

specdeck-spirit is a fork of specdeck. Everything specdeck does still works, and there's a new command on top.

specdeck spirit fetch quran-pickthall
specdeck spirit align --text quran-pickthall
specdeck spirit show
specdeck spirit keep rules.decimal-money
specdeck spirit read

For each reason in your spec and for the project's purpose, it proposes a passage, says how the passage bears on the reason, and suggests what to read further. You keep the ones that mean something to you and reject the rest. Passages you keep show up under the rule in AGENTS.md and CLAUDE.md, so the next agent session sees them too, and under the rule when it breaks.

It comes with ten texts, which is what I could find openly licensed in English. That's the King James Bible, the Tanakh, the Qur'an, the Dhammapada, the Bhagavad Gita, the Kojiki, the Tao Te Ching, the Analects, the Meditations of Marcus Aurelius and the Book of Mormon. That list isn't a judgement about what counts, so specdeck spirit add-text takes any text of your own.

To be plain about what's new, specdeck itself existed before this week. The spirit layer, its tests and the fork are what I built for this challenge.

For the Ghost in the Machine theme I took the side about honoring the past. These are some of the oldest things anyone wrote down about why to do things right, and their authors are long dead, so this puts their words next to the reasons in a modern codebase. It's for people who build software and also read one of these texts, and who want the two in the same place.

Demo

The recording at the top of this post is the tool running on an example shop project. Here's the same rule, the same reason, and what came back from each text on a local Gemma.

Text	Passage for "a float made a refund one cent short"
Bible	"Ye shall do no unrighteousness in judgment, in meteyard, in weight, or in measure." (Leviticus 19:35)
Tanakh	The same verse, in the 1917 translation
Qur'an	"O my people! Give full measure and full weight in justice, and wrong not people in respect of their goods." (Surah Hud 11:85)
Dhammapada	"Life is hard for the conscientious, always seeking purity, neither clinging nor rude, pure of livelihood and discerning." (Dhammapada 245)
Analects	Confucius on rectifying names, because if names aren't correct, affairs can't succeed (XIII.III)
Kojiki	No passage fits
Book of Mormon	No passage fits

Each search only ever sees one text, so nothing here was comparing notes. The Bible and the Tanakh share that verse, so them agreeing makes sense, but the Qur'an got to the same idea through its own verse and the Analects got to something close from a completely different direction. An honest measure turns out to be a very old concern.

The rule about tests landed somewhere I liked too. Its reason says a failing rule test is the rule being broken, not a flaky test to skip, and the Qur'an came back with "Confound not truth with falsehood, nor knowingly conceal the truth" (Surah Al-Baqara 2:42).

The full output for ten texts is in SPIRIT.md. You can also clone the repo and run examples/agent-rules/spirit-demo.sh, which uses the saved results and doesn't need a model.

Code

BlaiseLabs / specdeck-spirit

A fork of specdeck that reads the why of each rule in your spec next to a spiritual text you choose, with open models running locally

specdeck-spirit

A fork of specdeck that reads the why of each rule in your spec next to a spiritual text you choose.

specdeck keeps each rule as a requirement with a statement, a reason and a check. This fork adds one layer on top of those reasons. For each one, open models running on your own machine look through the Bible, the Qur'an, the Dhammapada, the Kojiki or any text you add, and propose the passage that speaks to it. You keep the ones that mean something to you and reject the rest. When a rule breaks, its passage is printed under it.

specdeck: rule rules.decimal-money broken
  "Ye shall do no unrighteousness in judgment, in meteyard, in weight, or in measure." (Leviticus 19:35)

Everything else specdeck does is unchanged, and it's all documented below the line further down.

Try it

You need Ollama with two open models.

ollama pull gemma4:12b-it-qat

…

View on GitHub

The original, without the spirit layer, is at BlaiseLabs/specdeck.

How I Built It

A reason like "the float made a refund one cent short" shares no words with Leviticus, so plain search finds nothing. It takes three steps.

Gemma 4 12B says what human concern sits under the reason, leaving the technology behind, and what words this text uses for it.
BM25 looks for those words and EmbeddingGemma looks for that meaning, across every passage of the text. The best 8 go on.
Gemma picks one by its number, or says none fits.

The third step is the design decision I care about most. People read these as scripture, and a model that writes a verse that doesn't exist would be putting words in a holy text. So the model only ever answers with a number. The quote comes out of the fetched text, and specdeck spirit check compares every quote with the text again. There's a test that has the model try to slip in its own wording, and it can't.

Being allowed to say nothing mattered as well. The prompt says none fitting is a fine answer, and 9 of the 50 reason and text pairs came back with no passage. The Kojiki declined three of its five, which seems right for a chronicle of deities when you ask it about internationalization.

Choices go in a spirit.yaml you commit with your project. A passage stays a proposal until a person keeps it, one you reject isn't offered again, and if a reason changes, check tells you the passage is out of date.

Is it any good?

I wanted some check that this wasn't just pattern matching on nothing. For each passage it chose, I gave Gemma that passage and a random one from the same text, with no sign of which was which, and asked it to score each from 0 to 3 on whether it speaks to the concern. Chosen passages averaged 1.98 and random ones 0.49, and the chosen one scored higher in 32 of 41.

That's the same model marking its own homework, so all it shows is that it beats chance. Reading through them, some are good and some are a stretch. Leviticus 19:35 came back for a rule about UTC timestamps too, and that's mostly the word "measure" doing the work. And all 41 passages affirmed the reason. The prompt allows a passage to challenge you, and none did, which I'd like to fix, since a text that only ever agrees with you isn't doing much.

How I got here

I should say this wasn't my plan for the week. I spent most of it on a project that tried to rewrite LLM code into lines humans had already written, using an index of millions of Python files. It kept not working, but it did teach me something. In one small program, the person's request decided at most 10 of 70 observable behaviours and the model decided 58 on its own. What gets lost with LLM code isn't so much who typed it. It's the why.

Then I ran out of time, and I had a tool that already stores the why. Honoring the past is part of this week's prompt, and these are about the oldest writings on why anyone should bother doing things right.

Running It on My Own Work

After the shop example I ran it against several of my own projects. Each one got a spec with its rules and reasons, and each spec got aligned with the King James Bible. That came to 65 reasons and 53 passages. Here are some of the ones that stuck with me and how I might read them.

The verse that came back most, four times, was "Providing for honest things, not only in the sight of the Lord, but also in the sight of men" (2 Corinthians 8:21). Part of that is Gemma reaching for a safe verse. But a lot of my rules really are about not fooling myself with a good looking number, so I can't argue with it.

For a rule that keeps rewriting text until the reader can follow it, I got "except ye utter by the tongue words easy to be understood, how shall it be known what is spoken?" (1 Corinthians 14:9). The way I read that, if someone can't follow what I made, that's on me and not on them.

For a rule about renaming a variable everywhere it's used, I got "He that is faithful in that which is least is faithful also in much" (Luke 16:10). That's a lot of weight for a variable name. I still take it to mean the small stuff is where you find out how you actually work.

For a rule about sharing things at a steady pace, I got "bring forth fruit with patience" (Luke 8:15). I build a lot faster than I share, so I might read that as permission to slow down.

For a rule that keeps an approval page off the public internet, I got "Let not the gates of Jerusalem be opened until the sun be hot" (Nehemiah 7:3). That one barely needs interpreting.

Some of them pushed back, even when the tool didn't say so. "God hath made man upright; but they have sought out many inventions" (Ecclesiastes 7:29) was marked as agreeing with one of my rules. Read it properly and the inventions are the problem. I start a lot of projects, so I took that one personally.

The only passage marked as a challenge was "The desire of the slothful killeth him; for his hands refuse to labour" (Proverbs 21:25). It came back for a rule that stops me from counting work as avoided when I've only moved it somewhere else. Fair enough.

One of them fooled me. "Out of the earth shall others grow" (Job 8:19) looked lovely next to a rule about giving people a path to learn on. Then I read the verses around it. They're about people who forget God being uprooted, and the others growing are their replacements. The tool looks at one verse at a time, so read the chapter before you keep one.

None of this is the Bible talking about my code. A model picked these and I'm the one deciding what they mean. What I got out of it is simpler than that. Be honest about what I measured, make things people can follow, take care with the small stuff, and maybe start fewer things.

Why Does Open Innovation Matter?

Faith is private. Which text you read, and which of your project's reasons you hold it next to, is nobody's business. Gemma and EmbeddingGemma run locally through Ollama, so none of that leaves the machine.
It's a lot of embedding for a joke that turned out useful. The Bible alone is 31,102 verses, and it took about half an hour on a base Mac mini. Running that locally costs nothing, so I could index all ten texts without thinking about it.
The texts are open because people made them open. Sefaria, SuttaCentral, Project Gutenberg, Wikisource and the people behind the open Bible and Qur'an datasets did the real work here, and the README lists each text with its source and licence. Bhikkhu Sujato put his translation in the public domain on purpose. Anyone can add a tradition I missed, and I missed a lot.

One limit comes with that. Old translations are the ones anyone may share, so they carry the views of their translators, and many Muslims hold that a translation of the Qur'an is an interpretation and not the Qur'an itself. This isn't religious advice either. A model finding a connection doesn't mean a tradition teaches it.

The Spirit of It

The challenge's closing date is Halloween, right as Día de los Muertos begins, and both are about the dead still having something to say to us. I think that's what this is, in a small and slightly ridiculous way. Somebody wrote down that a false weight is wrong long before anyone had a refund to get wrong, and now it prints under my test failure.

Prize Categories

Best Use of Gemma. Gemma 4 12B finds the concern under each reason and picks the passage, and EmbeddingGemma searches every passage of every text, all running locally through Ollama.

I built this with a lot of help from an AI coding assistant. The idea and the design decisions are mine.

GuessWithAnki: Using computer science and Anki to learn more vocabulary with less memorization

Blaise Labs — Mon, 26 Oct 2026 06:16:30 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3, Slow and Steady.

I'm still a beginner in Japanese, and I've always been amazed watching more advanced learners go through flashcards full of words they've never seen before and still guess the reading and meaning. To me, Japanese text basically looked like hieroglyphics.

Then, after a while of doing my own vocab cards, it started happening to me too. Every now and then I'd see a word for the first time, take a guess, flip the card, and be exactly right.

So I got curious and tried to actually measure how often that's possible, by breaking words into the pieces they're built from and checking whether those pieces give the word away. That led me down a rabbit hole of greedy algorithms and graph theory. The idea is that if you study the right building blocks first, a lot of new words become guessable without having to memorize them individually.

The result is GuessWithAnki, an Anki add-on that reorders your deck so you can guess the meaning, and often the pronunciation, of a lot of cards on your first try.

What I Built

If you've already learned the pieces that make up a word, you can often figure out what it means without ever having studied the word itself. For example, suppose you've already studied

電車 (でんしゃ), train
天気 (てんき), weather

You've now encountered 電 pronounced as でん and 気 pronounced as き. GuessWithAnki recognizes this and moves 電気 (でんき) (electricity) forward in your deck, since you already know how to read its kanji in this word and have some clues about its meaning. Instead of memorizing 電気 entirely from scratch, you have a good chance of guessing it correctly the first time you see it.

A card you get right the first time you see it is what I call a free card, since you never had to learn it the hard way. GuessWithAnki looks for the words you're likely to figure out on your own, then puts them right after the cards that teach their pieces.

This builds on GuessWithKanji, my first add-on, which only worked for Japanese. This time I wanted to see how far the idea goes beyond Japanese, so it now handles five kinds of decks.

Deck	What counts as a piece	When a word is guessable
Japanese	A kanji paired with its reading in that word (電 read as でん)	Both the meaning and reading follow from its pieces
Chinese	A character paired with its pinyin syllable and tone (开 read as kāi)	Both the meaning and pinyin follow
Korean	A syllable with the Chinese character it comes from (학 from 學, study)	The meaning follows from its parts
English	A prefix, root, or suffix (un-, employ, -ed)	The meaning follows from its parts
Medical	A Greek or Latin root or affix (hepat, -itis)	The meaning follows from its parts

The goal is to reward pattern recognition over memorizing.

GuessWithAnki encourages this by minimizing the amount of memorization needed to grasp an underlying pattern in a vocabulary deck.

This has the added effect of improving your memory, and giving you access to skills that are usually reserved for more advanced language learners.

Demo

The video at the top walks through the different performance profiles of decks across languages. Below you'll see the potential gains in Chinese vocabulary decks, which are the best suited for this technique.

With GuessWithAnki you are able to learn the equivalent of 500 Chinese words with less than 200 words. Just by changing the order you study them in.

Code

BlaiseLabs/GuessWithAnki has the add-on, measurement tools, experimental results, and video source files, including Manim scenes, narration, and build scripts.
BlaiseLabs/GuessWithKanji is the original Japanese-only version.

How I Built It

1. How guessable is a word?

I started by looking at how much overlap in kanji there was across words. The more unique kanji there were, the more difficult it would be to guess a word's meaning.

Luckily for me that's not how Japanese works, and as it turns out there was a large overlap between the words and the kanji they shared.

The reading

This part was surprisingly straightforward.

Two free dictionaries, KANJIDIC2 and JMdict, provide kanji readings and tens of thousands of vocabulary entries.

I wrote a small Python function to match each word's reading to its individual kanji. Compared against JmdictFurigana, it agreed on 99% of 17,854 common words.

Once you have those matches, you can count how frequently each reading occurs.

For example, 気 is read as き in 130 dictionary words, but as け in only 14.

So if you've learned 気 as き, a new word using that same reading becomes much easier to guess.

The meaning

Figuring out whether a word's meaning follows from its pieces is trickier.

I tried two approaches, both using open models.

Embeddings. EmbeddingGemma represents each meaning as a point in a vector space. If a word's meaning is close to the meanings of its kanji, there's a good chance you can infer it. After tuning on labelled words, this approach achieved an AUC of 0.83, compared with 0.73 for simple word overlap.
Asking a model directly. Gemma 4 runs locally through Ollama and labels words in batches. It judges whether the reading and meaning are predictable, partly predictable, or not predictable, using a JSON schema that specifies the exact words in each batch.

My own deck

I ran the analysis on my own deck of 2,038 words containing kanji.

Here's what I found.

For 67% of the words, both the reading and meaning were predictable.

In other words, roughly two out of every three words I was about to study were, at least in theory, words I could have guessed on first sight.

That was a much bigger share than I'd expected.

2. Finding the right order with a greedy algorithm

There's a catch, though. You can only guess a word if you've already encountered the pieces it's made of. For example, you can't guess 天気 (てんき) from its kanji if you've never learned 天 read as てん.

So this basically becomes a max/min problem. How do I maximize the number of guessable Anki cards while minimizing the amount of memorization needed?

Trying every possible order is out of the question. For 2,000 cards there are about 3.3 × 10⁵⁷³⁵ possible orders.

This basically turns into something a lot like the traveling salesman problem, and one of the simplest ways to approach this is using a greedy algorithm. A greedy algorithm builds a solution one step at a time. At each step, it chooses whatever looks most promising right now, without going back to reconsider earlier decisions.

It doesn't guarantee the perfect solution, but it's fast, and can get pretty close.

At every step, the algorithm asks which card should come next.

If a word is already guessable, it gets priority, especially if you've just encountered the pieces that make it up.
If nothing is guessable yet, the algorithm looks for an opener, a card that introduces just one new piece, preferably one that will help unlock other words.

For example, you might study 取る (toru, to take), followed by 戻る (modoru, to return).

Once you've learned those pieces, 取り戻す (torimodosu, to take back) becomes guessable.

The algorithm tries to create as many of these little chains as possible.

On my own deck, this changed the number of guessable words among the next 500 cards from 66 to 307.

That's nearly five times as many words you might be able to figure out without first memorizing them.

3. Does it actually help?

Of course, a word being theoretically guessable doesn't mean you'll actually guess it correctly.

And even if you do, will it help you remember more over time?

To explore that, I built a simulation of someone studying with Anki for 100 days.

The simulated learner studies 20 new cards per day and completes every scheduled review. Reviews follow FSRS-6, Anki's scheduling algorithm, which I reimplemented and checked against py-fsrs.

Each piece of a word has its own memory state. That memory gradually fades, but gets reinforced whenever another word containing the same piece appears.

A word can only be guessed if the learner still remembers its pieces.

On a JLPT vocabulary deck, with perfect guessing, a learner would need to learn just 16 cards from scratch to know their first 100 words. The other 84 could be guessed.

100% guessing isn't realistic though. This isn't magic, and as learners we're still going to get some words wrong.

I checked my own Anki review history and found that when a word was guessable and I'd seen its kanji recently, I answered correctly about 73% of the time.

So I also tested a more realistic 80% guessing rate.

At that rate, reaching the first 100 words required learning just 35 cards from scratch, rather than 100.

And there was another benefit I hadn't expected. Less forgetting.

Every new word reinforces pieces you've already learned. So you're not just accumulating vocabulary. You're repeatedly practicing the patterns behind it.

In the Core 2k simulation, forgotten reviews by day 30 fell from 189 to 72.

The same ordering that made words easier to guess also helped keep their building blocks fresh in memory.

4. Does it work beyond Japanese?

Japanese turned out to be a great fit for this idea. But I wanted to know whether it would work for other subjects too.
Then I ran the same experiment on two decks each for Chinese learners, English learners, and medical students, and three decks for Korean learners.

The underlying algorithm stays the same. The only thing that changes is what counts as a reusable piece.

For speed, I used a cloud model to label the 21,624 words across these decks in parallel, processing about 2.6 million tokens. The add-on itself uses Gemma locally, processing one batch at a time.

Here are the results at an 80% guessing rate.

Deck	Guessable	Cards to reach 500 words	Speed-up
New HSK 3.0, levels 1–4 (Chinese)	71%	392 → 200	2.0×
HSK 2012, levels 1–5 (Chinese)	66%	473 → 256	1.8×
Core 2k (Japanese)	60%	481 → 265	1.8×
Kaishi 1.5k (Japanese)	64%	474 → 282	1.7×
Oxford 3000 (English)	27%	494 → 303	1.6×
Korean Vocabulary by Evita (Korean)	39%	492 → 310	1.6×
2k Essential Beginner Vocab (Korean)	31%	486 → 350	1.4×
4000 Essential English Words	20%	494 → 356	1.4×
Medical Terminology with Etymology	27%	482 → 474	1.0×
TTMIK My First 500 Words (Korean)	25%	495 → 492	1.0×

Chinese did even better than Japanese

Chinese turned out to be an even better fit than I'd expected.

A character usually has one reading, so the pinyin of about 96% of words can be predicted from their characters.

And 90% of HSK words share every character with at least one other word.

That gives the algorithm plenty of reusable pieces to work with.

The advantage also lasts. Even beyond a thousand words, the optimized order maintains a 1.6–1.8× lead.

Korean lands in the middle

Korean was a late addition, after someone asked for it.

Most Korean vocabulary is Sino-Korean, built from syllables that each come from a Chinese character (Hanja). So once you know 학생 (student) and 교실 (classroom), 학교 (school) gives itself away.

The catch is that native Korean words and loanwords don't split into pieces like that, so only about a third of a beginner deck is guessable.

Evita's deck still reached 1.6× at 500 words, and kept 1.5× past a thousand. The small TTMIK deck barely moved, since its pieces rarely come back.

English is more modest

Most everyday English words don't break neatly into meaningful pieces. Knowing the spelling of beach, for example, doesn't tell you what it means.

But word families offer a useful shortcut.

Once you know employ, words like employer, employment, and unemployed become much easier to figure out.

The gains aren't as dramatic as in Chinese or Japanese, but they're still meaningful.

Medicine was the surprise

I initially thought medical terminology would be the perfect use case.

So many medical terms are built from Greek and Latin roots. So I figured they would especially benefit from greedy based sorting.

But the medical terminology deck barely improved on its own.

The problem was the deck itself. It was relatively small and mixed together technical terms, abbreviations, drug names, and everyday vocabulary. Many roots simply didn't appear often enough to be reused.

Medical students are often advised to learn the roots first. But with a roots deck placed ahead of the terminology deck, the learner has to get through 982 root cards before seeing the first medical term, around day 50.

GuessWithAnki takes a different approach.

Instead of teaching every root up front, it introduces only the roots needed for the next terms, right before those terms appear.

That means the learner can start guessing actual medical terminology within the first two weeks.

So even when the raw speed-up looks small, changing the order can make the learning experience very different.

Across all five profiles, the pattern became clear. What matters is how often meaningful pieces get reused, and how reliably they predict the words built from them.

5. Making the video with open models

I also wanted to explain the project visually, so I made a 3Blue1Brown-style video using Manim.

It features a little mascot named Gaku (学, meaning "study"), who reacts to the explanations as I talk.

The narration uses a clone of my own voice, and the whole production pipeline runs locally on a Mac mini.

Here's how I put it together.

The voice. I used Qwen3-TTS (1.7B, open weights) through MLX, cloning my voice from just 5.7 seconds of recorded speech. I generate whole paragraphs at once to keep the delivery natural. Whisper then detects the pauses between sentences so I can cut the audio and align each animation with its narration.
Checking the narration. Every generated take is transcribed with Whisper and compared word for word against the script. If something comes out wrong, the pipeline automatically generates another take.
Fixing Japanese pronunciation. The cloned voice kept pronouncing とる (toru) as "toh-ruh", and no amount of creative respelling helped. In the end, I recorded that paragraph and the intro myself, then used CosyVoice2 for voice conversion. That preserved my actual pronunciation and timing, including the laughs and stumbles, while giving it the cloned voice's sound.
Catching layout bugs. Animation overlaps are surprisingly hard to spot by eye. So I wrote a checker that runs after every animation and flags overlapping text, text escaping its box, anything covering Gaku, and objects falling outside the frame. It caught 30 problems, plus one particularly funny bug where Gaku's eyebrows collapsed into a single dot in the middle of the screen.

Why Does Open Innovation Matter?

None of this would have been possible without open-source work.

The language data comes from open resources, KANJIDIC2 and JMdict from EDRDG, plus CC-CEDICT for Chinese.

The scheduling algorithm is open too. It's FSRS, developed by the open-spaced-repetition project.

And the AI models run on my own machines. GuessWithAnki uses Gemma 4 and EmbeddingGemma, while the video pipeline uses Qwen3-TTS, CosyVoice2, and Whisper.

Put together, these tools let one language learner go from wondering, "How do advanced learners do that?" to actually measuring the phenomenon and building something useful from it.

Just as importantly, other people can check the results and build on the work.

The add-on doesn't need a server. Even its built-in heuristics, without a language model, judged 68% of a 4,995-word HSK deck to be guessable, close to the model's estimate.

Guessability labels are just data. You can share them, bundle them with a deck, or improve them together as a community.

That means the idea doesn't have to stop with my experiments.

The Lazy Payoff

With an 80% guessing rate, the simulation suggests you could reach your first 500 Chinese words while learning only about half as many cards from scratch. Japanese comes close.

You get more words from less memorization, reinforce the pieces you already know, and spend more of your time recognizing patterns instead of treating every word as something completely new.

And that's what brings me back to those advanced Japanese learners who seemed to know words they'd never studied.

Now I understand they were able to do this by learning enough pieces to start seeing the patterns in kanji across words.

GuessWithAnki is my attempt to help the rest of us get there sooner.

Prize Categories

Best Use of Gemma

Gemma 4 labels word guessability locally through Ollama, processing batches of 20 words with a JSON schema that specifies the exact batch contents and a daily processing cap.

EmbeddingGemma provides a second way to estimate guessability by measuring the semantic similarity between a word's meaning and the meanings of its pieces.

On 1,839 words from my own deck, Gemma 4 12B agreed with a much larger cloud model on 86% of reading labels and 79% of meaning labels.

Sentry Agent Tracing

Every labelling job is recorded in a self-hosted Sentry instance using Sentry's AI agent tracing format.

Each batch gets its own transaction, recording token usage, timing, and unreadable words. Individual embedding calls are tracked as spans.

This wasn't just instrumentation for its own sake. The traces helped me catch several real bugs.

Empty responses with thinking enabled. Gemma sometimes returned nothing at all. Setting reasoning_effort to none fixed it.
Context overflow. Batches of 40 words exceeded Ollama's default 4,096-token context and crashed the parser. Reducing the batch size to 20 fixed the problem.
Incomplete but valid JSON. Gemma 4 E4B once returned a perfectly valid JSON response containing just 1 of the 20 requested words. I updated the schema to enforce the exact words and their count.
Missing traces on long jobs. Some long-running jobs disappeared from the tracer. Splitting the work into separate transactions per batch solved that.

After those fixes, Gemma 12B successfully labelled all 1,839 words in 2.3 hours, with no failures.

OpenGameBuilder: Describe a game in one sentence and generate it using a local LLM like Gemma 4.

Blaise Labs — Mon, 19 Oct 2026 07:20:25 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

Every pixel above is drawn by code. The whole world file is 551 bytes of JSON: a cherry bank, then paddies, people who wander, and a village of ten with a stone lane, shops, a shrine and a temple. A model can write a file like that from one sentence, and then it is a game you can play and download.

What I Built

What it is. A small game builder on top of a world engine. You pick a world and a kind of game (or describe a world in a sentence and let a model make it), press Play, and download the game as one HTML file that runs offline, drawn entirely in code with no image files. The demo comes with prebuilt worlds you can play in your browser right now (link under Demo).

Who it is for. People who would like a living little world or game but cannot draw or animate: small game makers, teachers, anyone making a toy for a friend. And people building with small local models, who need a model's output to become something visual that reliably works.

The side hustle: games as a service, for many people, not just me. It empowers solo game makers and enthusiasts to build simple games with open models like Gemma 4, at a quality comparable to a cloud model's. The point is that other people can make a living with it:

a language teacher turns each week's word list into a quiz world for their students;
a D&D game master builds their campaign's town so the table can walk it before the session;
someone starts a small business making games for a community, a shop, a classroom or a Discord server.

The tools are free to use, and free to make and sell games with. When one game has earned US$500 in total, it owes a royalty of 5% of its revenue above that: Unreal Engine's model, at the scale of small games. So a teacher or a game master never pays anything, and the project earns only when the people building on it do.

It is three open projects, each built on the one before:

procedural-almanac: the techniques (noise, light, dithering, water, terrain, motion, genes), each with its sources and short tests.
OpenWorldBuilder: worlds as data, drawn by the almanac's techniques: a top-down pixel style, a 3D outdoors mode, and side and island views.
OpenGameBuilder: a world plus a small rules file becomes a game.

Demo

Play the prebuilt worlds in your browser (no account, nothing to install; making a world from a sentence needs a model, so that part runs where you set one up).

Pick a world, or describe one ("a foggy harbour town where crabs run the market").
Pick a kind of game: explore and collect, endless runner, photo safari, hidden object, fishing, lane racer, quiz (from your own CSV), creature keeper, point and click, island explorer. Eight of them play on the top-down worlds.
Turn a few knobs, press Play, then Download: one HTML file, about 330 KB, that runs offline. With the 3D mode on it is about 1 MB.

From one sentence to a game: a model made this harbour, its knowledge base and its rules, then a bot played it and won.

The same worlds can stand up in 3D: an oblique camera that shows roofs and west walls, terraces and walls from the land's own heights, buildings with real roofs, sun shadows, windows lit at night.

Code

BlaiseLabs / procedural-almanac

Procedural drawing and motion techniques, each with its sources and short tests

procedural-almanac

Procedural drawing and motion for the canvas: walk cycles, flocks, noise-made land, light and projection, where every technique cites where it came from.

Version 0.2 holds 72 techniques, 36 established and 36 original, citing 60 sources and held by 150 checks. The full list, with every source and every test, is the catalog.

module	techniques
`numbers`	clamp, lerp, smoothstep, wrap, angleDiff
`random`	hash32, fnv1a, hashString, indexRandom, SeededRandom, latticeHash, linearCongruential
`noise`	latticeRandom, valueNoise, fractalNoise, ridgedNoise, noiseLine, noiseTile
`colour`	hexToRgb, rgbToHex, rgba, mixColour, shade, luma, rgbToHsl, hslToRgb, hueToward, gradeColour
`pixels`	packRgb, mixPacked, packedHsl, packedToHsl, hueShiftTone, bayerThreshold, ditheredBorder
`light`	dayCycle, aerialPerspective, twinkle
`water`	waterTime, waterPixel
`land`	hillLine, islandHeight, levelCut, heightWater, wanderingHeading
`scatter`	scatterAlong, windowLit, blink
`projection`	parallax, turnedProjection, turnedDepth, faceShade
`limbs`, `gait`, `genes`	twoBoneLimb; footStep, strideRate, gaitTiming; genomeFrom, crossGenomes
`motion`	flockStep, gridWalk, pulseRise
`particles`	particleField, fall, rise, hover, wrapAround
`growth`	branchingTree, swayingChain
`drawing`	partPath, fillInArt, drawRecipe, grain, vignette, glowSprite,

…

View on GitHub

BlaiseLabs / OpenWorldBuilder

Living worlds drawn by code from a JSON recipe; an open model on a laptop can write one

OpenWorldBuilder

Living worlds drawn by code, where a world is only data: a person can write that data by hand, and a language model even a small open one running on a laptop, can write it from a description.

Nothing here is a picture file. The ground and its hills, water you can see into, trees and stones standing with their shadows, animals living their own lives, people by the trail, rain and snow and fireflies, day turning to night: all of it is drawn by code, from a seed, by one engine (engine/). A world is one JSON file (worlds/*.json).

The top view

The main view is a world seen from above, drawn as pixel art. It is the engine of 言の葉 (Kotonoha, "leaves of words"), the procedural journey that plays behind the flash cards of 綴 Tsuzuri (Tsuzuri, "writing it…

View on GitHub

BlaiseLabs / OpenGameBuilder

A small playable web game from a world, an idea or your own data

OpenGameBuilder

A small playable web game from an idea, a few choices or some data. Pick a world and a genre (or describe one and let a model make it), turn a few knobs, upload a file if you have one, press Play, and download the game as one HTML file that runs anywhere, offline.

It is a thin layer on two other projects:

procedural-almanac: the techniques (noise, light, motion, drawing), each with its sources and tests.
OpenWorldBuilder: living worlds drawn by code from a JSON recipe; a model, even a small open one, can dream one up.

OpenGameBuilder adds what a world lacks to be a game: a player, a goal, a way to win, and a genre's rules.

Run it

npm install
npm start            # builds the game script, serves the builder at http://127.0.0.1:8124/builder/

Without a model, everything except "Describe" works (and the builder can be…

View on GitHub

The almanac is MIT. OpenWorldBuilder and OpenGameBuilder are under a small community license: free to use, change and share, free to make and sell games with, and 5% of a game's revenue above US$500.

Layer 1: the almanac

Every procedural technique OpenWorldBuilder and OpenGameBuilder use lives in one library, each with its sources and a set of short tests that validate it: drawing pixels, bodies that walk, terrain and water from noise, weather, light, paths. Today it holds 162 entries, 106 references and 268 checks. Moving a technique there changes no picture: every move was proved by drawing the same worlds before and after, 0 pixels different.

Layer 2: worlds as data

A top-down world is a list of lands and a route across them. A land is generated from a rule set, not a map:

rule	what it says	for example
ground	the two tones of the ground and how they are textured	snow, hatch, rows of tea
water	how much of the land is water, and what kind	sea, pond, river, hot spring, paddy
flora	which plants grow, how often, and where	maples in groves, reeds on the shore
fauna	which animals live there, how many, and how they live	deer that graze, gulls that flock, people who wander
places	the wayside things	a well, a shrine, a lighthouse
village	a cluster of buildings along a lane	ten houses, two shops, a temple
motes	what drifts in the air	snow, petals, fireflies, steam

Code turns the rules into an ecosystem with terrain, plants, animals, and weather.

The vocabulary is small and closed: 27 built-in lands, 23 plants, 25 body plans (people among them), 26 kinds of wayside place, 9 kinds of building, 21 ways of living. A checker answers every mistake in words a model can act on, such as a fish living on dry land or a boathouse with no water. A world can also be bounded, so a game's map has an edge: the sea, mist or mountains.

Layer 3: games as rules

A game's rules are a small JSON file beside the world. They never draw anything: they name the world's own animals, places and people by id ("meet the seals of the drift-ice sea", "find the cairn"), so the checker can tell at once whether a goal exists in the world. Each genre also has a bot that plays it. The test plays every genre on every world it fits, and all 324 games are won.

An open model on a Mac

The first version asked models to write whole worlds. Gemma 4 12B, on a Mac mini through Ollama, took up to 13 minutes a game world in the initial version of the builder.

So for small models the code does most of the writing. It lays out one built-in land for each place in the world's knowledge base, the nearest fit, and the model answers one small design: each land's colours, what drifts in the air, and which word draws each thing in the knowledge base. Gemma 12B now makes a clean world in under three minutes, in two calls and about 4.3k tokens, drawing 90 to 100 percent of its knowledge base. A town with a harbour and a temple village took 3.1 to 3.4 minutes.

Watching the agents with Sentry

Sentry 26.10.0 runs self-hosted on a mini PC beside the Mac: no account, and the traces never leave my network. Each world is one trace, each stage an invoke_agent span, each model call a chat span with its tokens (and, for Gemma, Ollama's own seconds for reading against writing), each check and repair an execute_tool span.

That is a whole world from one sentence ("a lantern-lit tea village on terraced hills where foxes carry letters between the farms"), made today by Gemma 12B on the Mac: 3.15 minutes and 9 spans in all. The Lorekeeper writes the knowledge base in one call (2.28 minutes), a repair tool tidies it in a millisecond, and the World Author answers one small design in one call (51 seconds). Nothing failed, so nothing was asked twice.

It did not start this lean. Two things the traces showed me. A 27-token answer took 56 seconds because Gemma was re-reading a 6.8k-token prompt on every call; a shorter prompt cut it to 33 seconds. And whole rewrites wasted most of the work: a draft from code with changes only drew the same knowledge base in 122 seconds instead of 369. Those two findings led to the design path above.

What it is not, yet

The bots prove every game can be won. They win in seconds, so they say nothing about whether a game is fun; no person has played them all.
There is no sound.
The 3D buildings are simpler than hand-drawn art, and every building faces south.
Runner and racer play only in the side view.
Gemma's lands start from built-in ones, so its worlds are safe rather than surprising.
The games' own words are thin: the lines a game says are made from templates, and my first user found them flat and in places wrong (see "My First User").

Why Does Open Innovation Matter?

Open innovation makes new economies possible. A closed tool sells games to people. An open one lets people sell games to each other. With an open model on their own machine, a teacher, a game master or a small studio can make games as a service for their own customers: their students, their table, their community. Their cost for one more world is electricity, not an API bill, so even a small price leaves them a living, and the license asks for nothing until a game has really earned.

The model lives where the worlds are made. Gemma runs on a small computer on my desk: no fee per call, no rate limit, nothing leaves the machine.

I could build around the model. With open weights I could measure where it spent its time, hold every answer to a schema made from the engine's own vocabulary, and shrink its job until it fit: three minutes instead of ten.

Open all the way down. Open weights, three plain JavaScript projects, worlds and rules as JSON a person can read and edit, and an open-source Sentry on my own machine. The art is code: no image model, nothing trained on anyone's paintings.

My First User

My first user is a customer in every way but one: they have not paid, because nothing they made has earned money yet, so under the license nothing is owed. They came with a game in mind and typed it in:

a medieval sky city where Laputa meets Arlathan (island explorer, five kinds of creature to talk to, three places to find)

It came back as two playable versions: one from a cloud model in 49 seconds, and one free, from Gemma on my Mac, in 6.5 minutes. Gemma's has elven purple woods, named folk like the Cloud Monk and the Cloud Strider, and a citadel town with a temple and a bathhouse.

It is not yet the sky city they imagined: nothing reads as sky, and in Gemma's version the bot could not reach the bathhouse and the temple, so the checker's promise that every game can be won has a gap to close.

They also played two games the night before the deadline, with nothing but the builder and its guide. They picked a world, a kind of game and a few settings, played, and wrote down what bothered them. I have left the code exactly as they found it until after the deadline, so this is their report, not a list of things already fixed.

Tea Hills in 3D, hidden object, 8 clues, no time limit, seed 1.

A wrong click names what you clicked, and the English is off: "That is the trees", "That is the tufts".
Some things answer a click with a description (the trees) and others (the animals) say nothing at all.

Glowing Reef Drift (a side-view reef), quiz in a world, 15 right answers to win, six screens wide, no file uploaded.

The game asked the same few questions (four, by their count) over and over to reach fifteen. The cause is plain once you look: this world has no knowledge base and they uploaded no questions, so the quiz made its questions from the world's animals and plants alone, and there were only a handful to make.
The score at the top right ("140") does not say out of what. "140/150" would.
The win screen is too dry: "You won. You did it." Their words: "Be happy for the player's victory, thou must."

None of this would have shown up in my tests, and that is the point of a first user. All 324 bot games are won, and a bot does not mind a repeated question, a bare number or a flat "You did it." The checker proves a game can be won; it says nothing about whether its words read as if a person wrote them. The fixes are small and clear, and they are the first things I will do after the deadline: names that read as English ("Those are the trees"), every clickable thing answering, a quiz that never asks more questions than it has (and says so, suggesting you upload your own), the score as a share of the goal, and a win screen with some joy in it.

Prize Categories

Gemma (Google): Gemma 4 12B, run locally on a Mac mini through Ollama, makes top-down worlds and towns in under three and a half minutes each, and the framework (a draft from code, one small design, the checker) is built so a small open model can do it.
Sentry Agent Tracing: every model run is traced in a self-hosted Sentry, and the traces led to the design path. Setup, spans and findings are in "Watching the agents with Sentry" above.

OpenGameBuilder: Describe a game in one sentence and generate it using a local LLM like Gemma 4.

Blaise Labs — Mon, 19 Oct 2026 07:01:01 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

a language teacher turns each week's word list into a quiz world for their students;
a D&D game master builds their campaign's town so the table can walk it before the session;
someone starts a small business making games for a community, a shop, a classroom or a Discord server.

It is three open projects, each built on the one before:

procedural-almanac: the techniques (noise, light, dithering, water, terrain, motion, genes), each with its sources and short tests.
OpenWorldBuilder: worlds as data, drawn by the almanac's techniques: a top-down pixel style, a 3D outdoors mode, and side and island views.
OpenGameBuilder: a world plus a small rules file becomes a game.

Demo

Play the prebuilt worlds in your browser (no account, nothing to install; making a world from a sentence needs a model, so that part runs where you set one up).

Pick a world, or describe one ("a foggy harbour town where crabs run the market").
Pick a kind of game: explore and collect, endless runner, photo safari, hidden object, fishing, lane racer, quiz (from your own CSV), creature keeper, point and click, island explorer. Eight of them play on the top-down worlds.
Turn a few knobs, press Play, then Download: one HTML file, about 330 KB, that runs offline. With the 3D mode on it is about 1 MB.

From one sentence to a game: a model made this harbour, its knowledge base and its rules, then a bot played it and won.

The same worlds can stand up in 3D: an oblique camera that shows roofs and west walls, terraces and walls from the land's own heights, buildings with real roofs, sun shadows, windows lit at night.

Code

BlaiseLabs / procedural-almanac

Procedural drawing and motion techniques, each with its sources and short tests

procedural-almanac

Procedural drawing and motion for the canvas and for pixel art: walk cycles, flocks, noise-made land, water weather, light and projection, ways across a grid, where every technique cites where it came from.

The island above is made with the almanac alone: one scene calls 85 of its functions with no sprites or image files, and each caption names the functions on screen. Run it in your browser, with a seed of your own.

The almanac holds 162 techniques, 77 established and 85 original, citing 106 sources and held by 267 checks. The full list, with every source and every test, is the catalog.

module	techniques
`numbers`	clamp, lerp, smoothstep, wrap, angleDiff
`random`	hash32, fnv1a, hashString, indexRandom, SeededRandom, latticeHash, linearCongruential
`noise`	latticeRandom, valueNoise, fractalNoise, ridgedNoise, noiseLine, noiseTile
`pixels`	packRgb, mixPacked, packedHsl, packedToHsl, hueShiftTone, bayerThreshold, ditheredBorder, scalePacked
`water`	waterTime, waterPixel
`colour`	hexToRgb, rgbToHex, rgba, mixColour, shade, luma, rgbToHsl,

…

View on GitHub

BlaiseLabs / OpenWorldBuilder

Living worlds drawn by code from a JSON recipe; an open model on a laptop can write one

OpenWorldBuilder

Living worlds drawn by code, where a world is only data: a person can write that data by hand, and a language model even a small open one running on a laptop, can write it from a description.

The top view

View on GitHub

BlaiseLabs / OpenGameBuilder

A small playable web game from a world, an idea or your own data

OpenGameBuilder

It is a thin layer on two other projects:

procedural-almanac: the techniques (noise, light, motion, drawing), each with its sources and tests.
OpenWorldBuilder: living worlds drawn by code from a JSON recipe; a model, even a small open one, can dream one up.

OpenGameBuilder adds what a world lacks to be a game: a player, a goal, a way to win, and a genre's rules.

Run it

npm install
npm start            # builds the game script, serves the builder at http://127.0.0.1:8124/builder/

Without a model, everything except "Describe" works (and the builder can be…

View on GitHub

The almanac is MIT. OpenWorldBuilder and OpenGameBuilder are under a small community license: free to use, change and share, free to make and sell games with, and 5% of a game's revenue above US$500.

How I Built It

I built it with AI coding agents, several at a time, each on its own part, each held to tests and to films of what it drew. I set the direction and judged every result by looking at it: the first versions were flat side-on scenes, I called them what they were, and the top-down style, the villages and the 3D came from that. The open model is what the product itself runs on: Gemma 4 12B through Ollama, on a Mac mini on my desk.

Layer 1: the almanac

Layer 2: worlds as data

A top-down world is a list of lands and a route across them. A land is generated from a rule set, not a map:

rule	what it says	for example
ground	the two tones of the ground and how they are textured	snow, hatch, rows of tea
water	how much of the land is water, and what kind	sea, pond, river, hot spring, paddy
flora	which plants grow, how often, and where	maples in groves, reeds on the shore
fauna	which animals live there, how many, and how they live	deer that graze, gulls that flock, people who wander
places	the wayside things	a well, a shrine, a lighthouse
village	a cluster of buildings along a lane	ten houses, two shops, a temple
motes	what drifts in the air	snow, petals, fireflies, steam

Code turns the rules into an ecosystem with terrain, plants, animals, and weather.

Layer 3: games as rules

An open model on a Mac

The first version asked models to write whole worlds. Gemma 4 12B, on a Mac mini through Ollama, took up to 13 minutes a game world in the initial version of the builder.

Watching the agents with Sentry

What it is not, yet

The bots prove every game can be won. They win in seconds, so they say nothing about whether a game is fun; no person has played them all.
There is no sound.
The 3D buildings are simpler than hand-drawn art, and every building faces south.
Runner and racer play only in the side view.
Gemma's lands start from built-in ones, so its worlds are safe rather than surprising.
The games' own words are thin: the lines a game says are made from templates, and my first user found them flat and in places wrong (see "My First User").

Why Does Open Innovation Matter?

The model lives where the worlds are made. Gemma runs on a small computer on my desk: no fee per call, no rate limit, nothing leaves the machine.

My First User

a medieval sky city where Laputa meets Arlathan (island explorer, five kinds of creature to talk to, three places to find)

Tea Hills in 3D, hidden object, 8 clues, no time limit, seed 1.

A wrong click names what you clicked, and the English is off: "That is the trees", "That is the tufts".
Some things answer a click with a description (the trees) and others (the animals) say nothing at all.

Glowing Reef Drift (a side-view reef), quiz in a world, 15 right answers to win, six screens wide, no file uploaded.

The game asked the same few questions (four, by their count) over and over to reach fifteen. The cause is plain once you look: this world has no knowledge base and they uploaded no questions, so the quiz made its questions from the world's animals and plants alone, and there were only a handful to make.
The score at the top right ("140") does not say out of what. "140/150" would.
The win screen is too dry: "You won. You did it." Their words: "Be happy for the player's victory, thou must."

Prize Categories

Gemma (Google): Gemma 4 12B, run locally on a Mac mini through Ollama, makes top-down worlds and towns in under three and a half minutes each, and the framework (a draft from code, one small design, the checker) is built so a small open model can do it.
Sentry Agent Tracing: every model run is traced in a self-hosted Sentry, and the traces led to the design path. Setup, spans and findings are in "Watching the agents with Sentry" above.