Different parts of the Topaz product answer different questions. Use the language definition to determine what a program means, the checker to determine whether a source file is admitted, and execution evidence to determine what was observed in a given environment.
Which authority answers which question?
| Authority | Direct role |
|---|---|
| Language specification (SPEC) | Defines canonical syntax, types, semantics, and observable language boundaries |
| Checker | Decides whether a source file parses, resolves, type-checks, and is admitted for the selected use |
| Interpreter and output targets | Provide direct execution or a generated product; an unsupported route rejects before artifact output |
| Canonical examples | Present supported forms and workflows with observable results |
| Tests and verification records | Record observed results for named inputs, toolchains, environments, profiles, and resource limits |
A practical verification path
- Start from the current language pages and canonical examples.
- Run
topaz checkto catch syntax, name, type, and selected-profile errors. - Run the program and its tests. Record the outputs, diagnostics, file changes, and exit status that matter to the application.
- Build the intended output target and check its documented limits. A target that cannot preserve required behavior must fail clearly.
- When reading a test result or record, keep its exact inputs, environment, and limits attached to the claim.
The common command sequence is:
topaz check main.tpz
topaz run main.tpz
topaz build main.tpz --out-dir buildComparing compiler evidence
Canonical compiler observations compare the named boundary behavior and inputs
of two runs. Use semantic for the ordered source set through diagnostic and
outcome phases, generated-source for exact emitted Rust, provenance for
producer identity, and native-binary for exact same-target executable bytes.
Each layer records its own compiler output, while a passing workload records
the observed results for its named inputs and environment.