Topaz treats source code as an executable specification. The source should be readable enough to explain the rule, precise enough to run as the reference answer, and stable enough for another implementation to prove that it agrees.
This page is about that architecture, not a second introduction to the language.
1. Human-first specification
A useful specification must be readable before it can be trusted. If the important rule is buried under machine ceremony, the document may be technically executable, but it is a poor reference for humans and agents.
Topaz puts the domain rule first. Names can stay in the language of the domain. The grammar stays small enough that a reader is not forced to learn a local dialect per file. The goal is not to make every programming style possible. The goal is to make the rule hard to misunderstand.
2. Executable oracle
A specification that only lives in prose drifts. It starts as the truth, then slowly becomes a story about old truth.
Topaz avoids that by making the specification runnable. The interpreter is the oracle path: for a given input, it computes the reference observable result. That result can be pinned as a fixture and compared against every faster or lower-level path.
When the question is "what should this do?", the first answer should come from the Topaz source, not from a generated artifact or a hand-written translation.
3. Differential verification
Production still needs a compiled path. Topaz keeps the roles separate:
topaz runexecutes the reference path through the interpreter.topaz buildproduces a compiled path: a Rust native binary, or generated Python with--target python.
Those paths are not trusted by intention. They are compared. The differential harness feeds the interpreter and each backend the same inputs and checks observable results byte for byte: values, stdout, files, faults, and source spans. If a backend diverges, that build has not proved itself over the measured surface.
That is the meaning of run ≡ build: not a slogan, but a verification obligation the harness enforces for every backend target.
4. Why small matters
Smallness is not taste here. It is the boundary that makes the oracle usable.
A closed surface gives the parser, checker, interpreter, emitter, docs verifier, and generated-code reviewer the same target. It gives agents less room to invent syntax and humans fewer dialects to decode. The smaller the surface, the more practical it becomes to test the whole shape instead of scattered examples.
Topaz stays small so the toolchain can make stronger promises about the code that remains.
5. ATLAS as the proof case
ATLAS is the first production proof case for this model. It uses Topaz for complex Korean typography rules, keeps the interpreter as the reference path, and judges performance-oriented Rust paths against the Topaz result with corpus tests, golden fixtures, and differential checks.
The claim is intentionally narrow. ATLAS does not prove that every defect is impossible, and it does not validate Rust as a whole. It shows that a real product can put Topaz in the reference seat, put Rust in the production seat, and require agreement before the production path counts as correct.
6. Checked backends
The Rust and Python backends extend this model to different ecosystems. The Topaz source and interpreter stay the reference; Rust and Python are emitted, checked artifacts, not independent authorities. The Rust backend lowers to a self-contained native binary. The Python backend targets server, data, and operations work.
Agreement is something the toolchain tests, not a sentence the site states. The public evidence is a measured-surface receipt: across the exercised suite the same Topaz source shows the same observable behavior and the same runtime-guard behavior on the interpreter, Rust, and Python paths, with silent divergence held at zero. A completeness claim over everything the checker accepts is out of scope; the status page states the exact surface.
This matters in an agent-heavy project. Agents generate code quickly, but speed is not proof. A second checked backend gives another executable path for review, debugging, and disagreement. If the interpreter, Rust path, and Python path drift, the drift becomes visible.
7. Conclusion
Topaz is where intent becomes executable.
You write the rule once. The interpreter computes the reference answer. Rust emission checks the native and systems-shaped design path. Python emission checks the server and data-shaped design path. The harness checks that the paths say the same thing.
One spec. Multiple emitted checks. Zero drift.