An ambiguous condition grammar leaves two evaluators disagreeing about thousands of saved rules — how do you get to one meaning?

## Name the failure correctly first Neither evaluator is wrong. Both implement the published grammar; the grammar permits two trees, and each implementation picked one. Framing this as "evaluator B has a bug" sends someone to patch an implementation and leaves the actual defect — an under-specified language — in place, where the next reader of the grammar will hit it again. The unit of repair is the specification. ## Decide the meaning before touching anything Ambiguity means the grammar abdicated a choice, so someone must now make it, and "whichever is easier to implement" is the wrong basis. Useful inputs: - **What did users believe they wrote?** Sample the affected rules and read them as prose. The reading that matches ordinary expectation — conventional precedence, nearest binding — is almost always the right target, because it is what the authors meant. - **Which reading is already load-bearing?** If the request path has used one reading for two years, that reading is the de facto meaning of the stored data, whatever the batch job computes. - **Which is cheaper to express afterwards?** Whichever you do not choose must remain writable via brackets; check it actually is. ## Three fixes, and what each costs | Fix | Removes divergence for | Cost | |---|---|---| | Publish the convention; leave both parsers | Nobody, reliably — it is guidance a future implementer may not read | Cheapest, weakest; the grammar still permits both trees | | Ship one parser as a shared component both services call | Today's two implementations | Real, but the grammar stays ambiguous, so a third reader — a validator, an exporter, a UI preview — reintroduces it | | Rewrite the grammar so each rule has exactly one tree | Every present and future reader | Highest effort; must be paired with a migration story for stored text | These are layers, not alternatives: the durable answer is the grammar rewrite, with the shared parser as the mechanism that guarantees everyone runs the new grammar, and the written convention as documentation of a decision rather than a substitute for one. ## Migrating text that already exists The stored rules are the hard part, because a grammar change can silently reinterpret them. Work it in order: 1. **Parse every stored rule under both readings** and compare the resulting trees. Rules whose trees coincide are unaffected — expect most of them, since the ambiguity needs a specific shape to bite. 2. **Partition the differing set** by whether evaluation actually diverges. Two different trees can still agree in value when the operator is associative, which shrinks the review pile again. 3. **Attribute the remainder to owners** and ask which reading they meant. This is the only step that cannot be automated, and it is why step 1 matters: reviewing a hundred rules is possible, reviewing thousands is not. 4. **Rewrite the survivors into an explicitly bracketed canonical form**, so their meaning no longer depends on any convention and the change is visible in a diff. 5. **Freeze it**: the new grammar plus a corpus of rules with their expected trees, checked on every build. A silent mass rewrite that assumes one reading is the failure mode to avoid — it is indistinguishable, from an owner's point of view, from the system changing its behaviour for no reason. ## Closing the door for good - **One implementation of the parser**, consumed by everything that reads rules, so "which tree" has exactly one answer in the organisation. - **A conformance corpus** of rule text and expected trees. This is what makes a future reimplementation — in a different service, a different runtime, a different team — provably equivalent instead of hopefully equivalent. - **A version on the language**, so a future disambiguation is an explicit migration rather than a redeploy that changes what old text means. - **A guard on the grammar itself**: keep it in a form your parser construction accepts, so that a future edit reintroducing ambiguity fails the build instead of shipping. ## What an interviewer is listening for Three moves, in this order: locating the defect in the specification rather than in an implementation; sizing the blast radius with data before proposing a migration; and separating the decision (which meaning) from the mechanism (how it is enforced) and the migration (what happens to text already written). A candidate who jumps straight to "we standardise on one parser" has solved the incident and left the cause; a candidate who proposes rewriting thousands of stored rules without first measuring how many actually differ has invented a migration that did not need to exist.