Problem articulation for programmers
Millay is a new project, still in the early stages of conceptual development. It grew from a pattern I could not ignore: AI answers arrived faster than understanding. I needed a way to stay inside the problem — to break it open, name it honestly, and only then reach for math, design, and proof. Nothing executes your code. What you see here is the emerging shape of that desk, not a finished product.
Early concept
Problem before solution
Millay opens with a blunt contract: on-device, offline-capable, problem before solution. You cannot know a solution is correct until you understand the problem. These screens capture an early conceptual build — the stance and the pipeline are taking form; the craft is still being refined.
Chapter 01 · Discover
Start where the idea is still messy
Most engineering pain begins as a feeling you cannot quite say. Discover is a guided prober: answer curated questions, skip what does not fit, and leave with an Articulate-ready draft instead of a vague itch.
It is deliberately conversational — not because chat is trendy, but because naming a problem is iterative. You circle until the real constraint surfaces.
Chapter 02 · Articulate
Name what is true before you connect anything
Articulate forces honesty: value domain, work shape, correctness frame — the scaffolding another engineer would need before arguing about implementation.
Optional space for geometry when shape is part of the problem. Required fields stay required. The orange line at the bottom is not nagging; it is a checklist against wishful thinking.
Chapter 03 · Inspect
What math is already in play
Paste a procedure. Millay surfaces formulas already implied by the work, then candidates that fit — while optional “squirming facts” keep latency, failure modes, bounds, and concurrency in view without blocking exploration.
This is the opposite of a black box: the machine helps you see the math, then you decide whether it belongs.
Chapter 04 · Verify
Design the proof before you trust the idea
Verify takes procedure plus intent — what should this guarantee? — and returns a proof sketch: asserts, fixture schema, A vs B harness. You can save a Millay claim. Still: nothing runs your code. The discipline is knowing what “correct” means before the runtime lies to you.
Chapter 05 · Keep what held
A catalog to search. A library that never leaves the device.
Browse is a living catalog of fields, formulas, and proof suites — filterable by programming topic when you need an engineering lens, not a random blog post.
My Library keeps claims, discoveries, and keepers local to the browser. Collaboration starts from something you actually understand, filed where you can find it again.
I did not want AI to disappear into a solution I could not explain. I wanted a desk that forced me to stay in touch with the code — deeper, slower where it matters, and honest about what I still did not know.
Under the hood
On-device by design — still taking shape
The engine is Odin compiled to freestanding WebAssembly. The UI is a SvelteKit static app. Content — fields, formulas, proof suites — lives in authorable TOML. Capacitor wraps the same build for mobile. The stack mirrors the philosophy: explicit, portable, no hidden cloud required to think. Expect sharp edges; this is early conceptual work, not a polished release.
Problem
AI can ship a solution before you understand the problem — leaving programmers with code they cannot explain, defend, or evolve.
Approach
An on-device pipeline — Discover → Articulate → Inspect → Verify — with an Odin/WASM engine, curated math, and proof suites.
Outcome
An early conceptual prototype: the desk’s intent and flow are visible, with a long road of development still ahead.
Technologies
- Odin
- WebAssembly
- SvelteKit
- TypeScript
- Systems Design
- Data Oriented Design
- Capacitor