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 (current doctrine — post wrong=0 correction)

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 per-category injector (generate/recognizer_anchor_inject.inject_from_match) is consulted;
• if the injector emits one or more CandidateInitial / CandidateOperation that survive admissibility, those candidates are added to the per-sentence choice space exactly as parser output would be;
• if the injector emits nothing (or all candidates are dropped by later pronoun/lookback guards), the graph refuses explicitly with the reason "recognizer matched but produced no injection for statement: ... (category=...)".

Never silently drop a recognized math statement as "zero state". The historical skip-only rule ("drop it, Cartesian product unchanged") was retired because it admitted incomplete graphs at the problem level (the solver could answer from the remaining statements and produce a number that was not the answer to the full input). The current code and this document treat "recognized + no typed emission" as a refusal case. Old skip-only language appears only in historical notes below.

Empty registry → the guard is a no-op and the pre-registry refusal behavior is preserved byte-identically.

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 / D.2 follow-up (historical note)

Early Phase D wiring (the registry + skip-only guard) was intentionally "skip-only by construction" so that adding recognizer categories could not regress wrong=0. That doctrine was corrected once the "recognized but uninjected → incomplete graph" hazard was understood (see the explicit refusal branch and comments in math_candidate_graph.py and the ADR-0167 / Brief 11 lineage).

Current follow-up work (Workstream A Inc 2 and successors) adds the per-category injectors that turn parsed_anchors for rate_with_currency (and later categories) into grounded CandidateOperation / Rate / apply_rate primitives that the existing solver already knows how to execute. When an injector is present and emits, the statement contributes real solver state; when it cannot, refusal (not silent drop) is the outcome.

Historical skip-only descriptions are preserved only as "rejected behavior" markers in this document and in code comments. Grep for the old phrases on the active source surfaces should surface only such markers.