Everything an implementer needs lives in the repo's spec/ folder, and the contract is deliberately small: pick a surface (cues or blanks), parse its markdown format, and pass the executable fixtures in spec/conformance/. You don't have to implement every surface; a runtime is conformant for the surfaces it implements.
The conformance suite's shape
| Directory | Contract |
|---|---|
valid/ | Files your parser MUST accept: per-surface examples plus the master files |
invalid/ | Files it MUST reject, each with an .expected.json naming the lint rule code |
wire/ | LLM wire-format cases: parsing the INDEX:alt1,alt2 response lines |
routing/ | Scenarios pinning per-word dispatch, priority tiebreaks, catch-all fallback, and blank shapes |
A complete runner is about 80 lines: four loops over those directories. (For calibration, the reference implementation's own runner is around 280 lines, since it also hand-rolls a routing algorithm, and currently passes 54 tests with 6 marked as known parser gaps.) You may legitimately skip fixtures your runtime can't exercise: LLM cases for a static-only runtime, script blanks for a browser host.
What you must honour beyond parsing
The behavioural spine from spec/core.md: the three-location search path with additive layering, deterministic triggers (a cue fires when its regex hits a typed word, never because an LLM read its description), per-word routing where the highest priority claims each word, hot-reload (config edits MUST NOT require a restart; landing within a couple of seconds by any mechanism is conformant), declarative host compatibility, and the security floor: LLM output must never be routed into tool execution, network fetches, or any side-effect channel. A conformant runtime SHOULD also ship three CLI verbs: validate, list, and seed-configs.
What you're free to invent
Everything user-facing: how alternatives render (ANSI dim, CSS highlights, something new), which keys cycle, prompt wording, provider choice, and your runtime's own settings file. The standard deliberately pins interop, not experience. Unknown frontmatter fields are preserved rather than rejected, so extensions don't break older readers.
The honest status, and why to do it anyway
No second implementation exists yet; the suite is the contract one would target, and the spec is a 0.7 draft whose field names can still move before 1.0. The flip side: features are only promoted into the standard once two independent runtimes adopt them, so an early second implementer gets a real voice in what the standard becomes, through a proposal process modelled on MCP's SEPs. Start at spec/README.md, and open a discussion in spec/proposals/ when the spec fights you.
Related: What is an open standard for AI? · The open standard page · How to contribute · GitHub repo