Skip to main content
The first slice is built; the rest is design. mz harness version, definition and entry exist, and the entries they print are tested in CI. The plugin host, and skills and benchmark guides generated from the definition, are design only (RFC-0012, a draft, amended on 7 October 2026). Checked at language main be88017, released on 8 October 2026.
The language harness is the spine of the language. RFC-0012, as amended, says every feature of the language is defined once, as a harness entry inside the compiler: each type with its operators and methods, each statement form, each declaration kind, each diagnostic code with its fixes, and each mz command. mz harness definition prints those entries as the language an agent reads. The toolchain, the agent protocol (mz check --agent, mz fix) and external clients such as the CLI and the MCP server are meant to attach to it, not hold a second copy of the language. It was called “the harness” until 7 October 2026. It is a different thing from benchmarks/harness/, the Phase 0 scorer, which is always called the benchmark harness.
“The harness is the central spine, internal and external, for the language.” — the owner, 7 October 2026, quoted in RFC-0012

​
What an entry holds

At be88017 the definition holds 133 entries: program, and component and service as kind-level entries; int, float, bool and text; every operator, try among them; the 11 numeric methods; every statement form, C4’s control flow and C9’s results among them; print and error; the nine mz commands; and 66 diagnostic codes, the 45 MZ09xx codes a program raises and the 21 shared codes it reuses. The 55 codes of components and services are on a pending list that a test freezes, so it can only shrink.

​
mz harness

At be88017, mz harness version prints:
No crate version changes: the crates stay at 0.0.0, and the definition’s SHA-256 pins its content, changing whenever an entry does. Each subcommand exits 0, or 2 for a usage problem or an unknown name. mz harness plugins is designed and not built. The MZ09xx table on the compiler page is generated from mz harness definition, not written by hand.

​
What is enforced, and what is written by hand

The amended RFC’s rule, from the owner’s direction of 7 October 2026, is that a pull request that adds or changes a language feature adds or updates its harness entry in the same pull request, and a tracker row is not done until its entries are. The first slice holds it in three different ways, and the difference matters: Fix kinds are recorded as raised, so an agent can receive a guess on a code whose entry lists only exact: when two exact fixes overlap, mz check demotes one.

​
What is not built

  • The plugin host, its manifest and lifecycle, and mz harness plugins. Nothing in mz loads, lists or calls a plugin.
  • Generated skills and benchmark guides. The agent skills and the benchmark’s prompts are still written by hand, and do not yet describe programs.
  • The checker reading its rules from the registry, rather than being checked against it.
  • Full entries for components and services, which are kind-level only.

​
Whether it helps is a hypothesis

The owner expects the language harness to improve the benchmarks. That is a hypothesis, and nothing here has measured it. RFC-0012 §9 question 9 says how the benchmark is designed to test it. No benchmark has run with an agent taught by the definition, and the run that tests the charter’s kill criterion has not happened. See Status and the pilot results.