Topaz treats a program as an executable statement of intent: readable enough to review and precise enough to run. The goal is not to maximize syntax, but to make ordinary programs direct and consistent.
One clear form
Ordinary code should have one preferred form. Domain names can remain in Unicode, effects and failures stay visible, and features that are not ready stay out of examples. This keeps code written by people and code generators equally readable.
Predictable execution
The same source should behave consistently whether it is run directly, compiled to a native program, or emitted as Python. Topaz defines visible behavior such as values, ordering, errors, and cleanup while leaving implementations free to choose their internal representation.
Multiple useful outputs
Rust, Python, and web outputs serve different deployment needs without creating separate Topaz dialects. A program is checked once, then sent to the selected output path. Differences found during testing are treated as compiler bugs rather than language choices.
Small surface, deep policy
A focused grammar and standard library give readers, tools, and implementations the same target. Topaz can grow, but new features should arrive with defined behavior, working implementations, examples, and documentation.
Real programs guide growth
Real applications reveal which strings, numbers, collections, files, packages, and diagnostics are actually missing. Future interpreter work also guides improvements to recursion, portable values, state, printing, and errors. Product needs set priorities without adding one-off syntax.
Honest status
The documentation distinguishes features available in the current release from future plans. Limits are stated on the page where they matter, without turning implementation details into part of the public language.