### The native sink through the conformance runner, and a result that admits an implementation only for a run that passed

- **Admitting an implementation** ([extensions/conformance-results.md](extensions/conformance-results.md) §4.1). A
  relying party that admits an implementation on a `conform-result/1` record, such as a certification of a sink or a
  gate in a build, requires the record accepted (§4), its run passed (`not_conformant`), its suite one whose corpus it
  holds (`suite_unknown`), and its corpus digest that corpus's (`corpus_mismatch`). `wai verify --conformant [--root
  <wai-dir>]` applies the rules against the corpus of a checkout. A record of a run that did not pass is a genuine
  record, and `wai verify` without `--conformant` accepts it as before.
- **A sink kind.** `wai conform sink --suite native-sink` gives a native sink every session of
  `live-conformance/native-sink/` with its answers withheld, and each configuration the corpus states a session
  refuses; a case passes when the sink's answers, one RFC 8785 text a line, have the SHA-256 of the answers the corpus
  states. `wai_native_sink_vectors answers [--c-abi] <case>` is the reference sink, through its module or through the C
  interface the platform integrations link.
- **The native sink and the score decoder in CI** (`wai-breaking.yml`, the runner job): the native sink through its
  module and through its C interface, and the score decoder (`decoder --suite score`), each run conformant and each
  record admitted against the checkout's corpus. A planted sink that presents an object whose digest does not match
  fails its run, on that case; its record verifies, and admission refuses it at rule 2. `tests/cli_conform_sinks.rs`
  holds the same, and refuses a run against a copy of the corpus changed to suit the sink (`corpus_mismatch`) and a
  record of a suite the build does not run (`suite_unknown`). The browser sink has no `sink` suite:
  `wai_browser_sink_vectors verify` and `browser_sink_verify.py` hold its corpus, as before.

