core/docs/recognizer-registry.md

Ratified Recognizer Registry (ADR-0163 Phase D)

The recognizer registry projects accepted exemplar-corpus proposals from the append-only proposal log into a tuple the math candidate-graph consults before refusing on an empty per-statement choice list. It is the connective tissue between Phase C's operator review surface and Phase D/E's admission expansion.

Projection rule

A proposal enters the registry iff all of:

• source.kind == "exemplar_corpus" (Phase C's source kind)
• review_state == "accepted" (operator ratification — never agent-side)
• proposed_chain.recognizer_spec parses as a teaching.recognizer_synthesis.RecognizerSpec

Pending, rejected, withdrawn, and non-exemplar proposals are invisible. Malformed accepted proposals raise RegistryLoadError with the offending proposal_id — silent drops are forbidden.

Registry order is (review_date, proposal_id) ascending — stable across runs.

Match contract

generate.recognizer_match.match(statement, registry) returns at most one RecognizerMatch per call (first-match-wins over registry order). Each per-category matcher is rules-only — no LLM, no embedding, no learned classifier. A module-import test pins the no-ML constraint.

parsed_anchors carry numeric tokens extracted from the statement text, not from the spec. For descriptive_setup_no_quantity, parsed_anchors is the empty tuple by design — the recognizer admits the statement as setup context, contributing no math state.

Narrowness invariant

Per ADR-0163 §Phase C The Synthesis Rule property (b), the recognizer is the narrowest commitment that subsumes the seeds. The matcher inherits that narrowness verbatim:

• A currency symbol outside the spec's observed_currency_symbols does not match rate_with_currency.
• A window unit outside observed_window_units does not match temporal_aggregation.
• A statement with any digit, number word, or indefinite quantifier does not match descriptive_setup_no_quantity.

Widening happens through the corridor — wider exemplar corpus → Phase C synthesis on wider seeds → operator ratifies the wider proposal — never by editing the matcher's permissiveness.

Wiring point

generate/math_candidate_graph.py:parse_and_solve consults the registry at the per-statement choice loop, before the existing no admissible candidate for statement refusal. When the registry recognizes the statement, the statement is dropped from per_sentence_choices and the loop continues. Empty registry → the guard is a no-op and the existing behavior is preserved byte-identically.

Skipping a recognized statement contributes ZERO math state to the solver, so the Cartesian product is identical to "this statement was never there." This preserves wrong = 0 by construction; the downstream solver still refuses if the remaining statements + question cannot produce a consistent answer.

Ratification boundary (ADR-0161 §5)

The agent does not ratify the live proposal log. Phase D tests build a synthetic in-memory RatifiedRecognizer tuple from the Phase C pending proposals' content (tests/_phase_d_fixture.py). The matcher and candidate-graph wiring exercise the same RecognizerSpec bytes the operator will later ratify, with zero modification to teaching/proposals/proposals.jsonl.

The operator's ratification path is the existing core teaching review <proposal_id> --accept --review-date <YYYY-MM-DD> — no new CLI surface lands with Phase D.

Phase E follow-up

Phase D wires the registry into the admission boundary; downstream consumption of parsed_anchors (turning recognized rate/temporal surfaces into solver state that produces concrete answers) is deferred to Phase E. The wiring is in place; Phase E adds the math_candidate_parser handler that consumes the typed anchors.