Overview

Executable Specification

One spec. Two engines. Zero drift. Topaz is an executable specification language for deterministic software.

Topaz is an executable specification language for deterministic software: human-readable as a spec, runnable as an oracle, and differential-tested against production implementations.

Topaz is not trying to outrun Rust. That is the wrong frame. Topaz exists to make intent precise enough that humans can read it, agents can write it, and the toolchain can verify what production code claims to implement.

This architecture moves in three acts: human-first specification, executable oracle, and differential verification.

1. 正 Human-First Specification

Most languages are written machine-first. You describe what the hardware should do, and the actual intent, the rule, the policy, the domain, is left implicit inside control flow.

Topaz inverts the order. The intent comes first, and it is written in the language of the problem, not the language of the metal.

Domain words are code. 한글, Кириллица, and emoji are first-class identifiers, not escape hatches. Unicode-first is not decoration. It is how rules survive without translation loss.

The surface is small and closed on purpose. For each common intent, there should be one canonical way to say it. The language fixes the policy so people and agents do not relitigate dialect, style, and shape on every line.

The result is that hard logic, Korean typography, locale-bound rules, and difficult business cases, can read like the rule itself. A specification must be readable before it can be trusted.

2. 反 Executable Oracle

A specification that only lives in a document is a dead specification. It drifts from the code. Eventually it lies.

Topaz refuses to be a dead spec. Every rule you write runs.

The interpreter turns the specification into an executable oracle. It does not merely describe the program. It computes the reference answer for the same input, with observable results that can be pinned as golden fixtures.

Topaz is a document that calculates the answer.

That inversion matters. The spec is not documentation trailing behind the implementation. The spec is the implementation's reference point. When you want to know what correct means, you do not start by reading the Rust. You ask Topaz.

3. 合 Differential Verification (run ≡ build)

Production still demands a fast path. So Topaz emits a Rust production path while keeping the interpreter as the reference execution path.

But a trusted translation is not verification. topaz run and topaz build must be judged against each other.

In CI, the corpus and golden fixtures feed both paths the same inputs. The differential harness compares value, stdout, files, failures, and spans byte for byte. Same input must produce the same observable result, or the build does not pass.

That is run ≡ build.

It is not a slogan. It is a verification obligation the toolchain must satisfy. The interpreter says what is true. The Rust path says it fast. The harness checks that they are the same sentence.

Topaz is not the slower implementation. Topaz is the executable reference implementation other implementations must answer to. Topaz does not exist to replace production code. It exists to define what production code must prove.

You write the intent. The compiler writes the Rust. The toolchain proves they agree.

4. Why A Small Language

Small is not an aesthetic preference. In Topaz, small is a verification boundary.

A small closed surface reduces misreadings. It gives agents less room to invent syntax. It gives humans fewer local dialects to decode. It gives the toolchain a fixed target it can parse, check, run, and compare.

That is the existing Topaz identity elevated into an executable architecture.

One canonical way to say each thing. Domain words kept in the language of the domain. Unicode-first from the lexer up. People and agents write the same surface, and the toolchain verifies it.

Topaz is deliberately small because the point is not to express every possible programming style. The point is to make intent stable enough to execute and verify.

5. ATLAS As Production Proof Case

ATLAS is the first production proof case of this architecture.

It applies Topaz to complex Korean typography logic: the rules are specified in Topaz, the interpreter provides the executable oracle, and performance-critical Rust paths are judged against the Topaz result through corpus tests, golden fixtures, and the differential harness.

That claim is intentionally narrow. ATLAS does not claim that every defect is impossible. It does not validate Rust as a whole. It shows how a real product can put Topaz in the reference path and Rust in the production path, then require the two paths to agree before the production path counts as correct.

ATLAS is the first production proof case. It should not be the last.

6. Conclusion

Topaz is where intent becomes executable.

You write the rule once, in a small Unicode-first language. The interpreter makes it runnable. The compiler writes the Rust. CI compares the reference path and the production path byte for byte.

One spec. Two engines. Zero drift.