# Natural-language criteria: what parses, what does not

`criteria` accepts plain strings in English or Chinese. Verified live: "有 test_log" parsed to `evidence_present` on key `test_log`; "there must be a changelog" parsed to `evidence_present` on key `changelog`; "https://example.com returns 200" parsed to `url_status` with the expected status.

Parsing guesses the evidence key from your sentence, and that guess can miss. "at least 3 boundary cases" parsed to `count_min` but looked for a key named `boundary`, while the evidence key was `boundary_cases`; the item failed even though three cases existed. Write the exact key name in the sentence, or use the object form, whenever your key is not the obvious noun.

A criterion that is not mechanically checkable comes back with `kind: "unverifiable"`, `parsed: false`, `met: false`, and a `missing` message telling you to switch to the object form. The call also carries `ai_diagnostic: {"unparsed": n, "ai": "..."}` when anything was left unparsed.

Rule of thumb: plain strings for prose criteria where the key name is obvious, `{"text":"...","check":{...}}` when a wrong guess would cost you a re-run. A re-run costs 1 credit, so being exact is cheaper than retrying.

中文：自然语言标准中英文都能解析，但**键名是从句子里猜的**——句子里的名词和 evidence 键名不一致就会误判（实测 "at least 3 boundary cases" 猜成 `boundary`，实际键是 `boundary_cases`）。键名不显然时用对象写法；核不了的会返回 `kind:"unverifiable"`、`parsed:false` 并告诉你改成对象写法。

## Source

https://nodcheck.com/answers/natural-language-criteria