# noCV engineering task library Content version 5 Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs. Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence. ## PDSL — Make fulfillment rules understandable without executing scripts A fictional fulfillment product routes parcels using destination zone, weight in grams, and service level. Its next release needs nested eligibility rules, but arbitrary customer scripts are out of scope. Create a local TypeScript baseline and synthetic parcel/rule fixtures; no starter repository or fixtures are supplied. Keep parsing and evaluation in a local practice application with no network, filesystem, or host-code expressions in the language. **Field:** Compiler and language tooling. **Suggested stack:** TypeScript, Node.js, Vitest, JSON. **Engineer value:** Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. **Company value:** Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. **Delivery agreement:** Ten tickets across language definition, evaluation, and evolution. Author a minimal local baseline for individual tickets or build the complete synthetic rule engine and compatibility report. ### Setup prerequisites - Recursive data structures - Parser error handling - Discriminated unions ### Define the language boundary Give saved rules an explicit grammar, tree shape, and useful diagnostics. #### PDSL-101 — Settle literal and operator precedence before saving warehouse rules **Task · High priority · Foundational** noCV practice brief v5 · PDSL-101 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the language boundary. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 80% · API design 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Pattern topics: Interpreter (apply). Interpreter — Apply: Use an explicit expression grammar as the interpreter boundary so precedence and permitted operations are reviewable before execution. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Operations wrote zone == 'north' OR service == 'express' AND weightGrams < 500. Two engineers read it differently, and there is no grammar to decide which parcels qualify. Acceptance criteria - Define parentheses, AND-before-OR precedence, quoted strings, and nonnegative integer gram literals with unambiguous examples. - Reject unknown operators, decimal weights, and trailing tokens with a stable code and source range. - A parse result carries a language version; invalid input cannot produce a saved rule object. Implementation constraints - Keep the grammar limited to the three documented parcel fields; do not translate input into JavaScript or expose general function calls. Verification - Parse the disputed expression and its parenthesized alternative into different expected trees. - Reject an unterminated string and an extra closing parenthesis without a stack trace in the public diagnostic. Deliverables - Versioned grammar note, parser entry point, and synthetic parsing cases Rollout and recovery: Use the grammar for newly authored local rules first; retain the original text when reverting the parser version. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PDSL-102 — Represent nested all-of and any-of rules without special-case depth handling **Story · High priority · Intermediate** noCV practice brief v5 · PDSL-102 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the language boundary. Depends on: PDSL-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 75% · System design 25%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Pattern topics: Composite (compare). Composite — Compare: Compare uniform leaf/group composition with the existing fixed-depth structure, retaining type safety without requiring a class per node. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The current rule model has separate fields for one AND group and one OR group. A warehouse needs (north OR west) AND (express OR under-500g), which cannot be represented without duplicated conditions. Acceptance criteria - Model comparisons and nested all-of/any-of groups through one expression contract while preserving child order. - Reject empty groups and enforce a documented maximum of 16 levels and 1,000 nodes at construction. - Serialize and parse a valid tree without changing its grouping, field types, or language version. Implementation constraints - Compare a discriminated-union tree with a class hierarchy; choose the smaller representation that supports the required operations. Verification - Round-trip a four-level mixed rule and compare every node and child position. - Reject a seventeenth level and a reused mutable child that would change an already constructed rule. Deliverables - Expression model, boundary tests, and a short representation decision Rollout and recovery: Convert only synthetic flat rules first and compare their trees; retain flat input conversion until nested-rule behavior is checked. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PDSL-103 — Point rule editors to invalid fields before evaluation starts **Story · Medium priority · Foundational** noCV practice brief v5 · PDSL-103 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the language boundary. Depends on: PDSL-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 70% · Developer tooling 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Pattern topics: Visitor (compare). Visitor — Compare: Keep validation separate from evaluation and compare visitor dispatch with an exhaustive function for adding independent tree operations. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A rule containing weightGrams == 'heavy' parses successfully, then fails when a parcel reaches the evaluator. Support needs all actionable type errors from the saved rule before attempting a run. Acceptance criteria - Validate permitted field/operator/literal combinations in a pass that does not evaluate parcel data. - Return diagnostics in source order with node path and source range, capped at 50 with an omitted count. - Keep the rule tree unchanged and report an unknown node kind as an unsupported-language error. Implementation constraints - Compare a visitor with an exhaustive traversal function; document how adding a node forces the validator to handle it. Verification - Collect distinct string/number mismatch diagnostics from separate branches in stable order. - Pass a synthetic unknown node and a 70-error tree; verify safe rejection and the diagnostic cap. Deliverables - Static rule validator and support-facing diagnostic examples Rollout and recovery: Run validation on synthetic saved rules in report-only mode before blocking new invalid saves. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Evaluate and inspect Make rule behavior deterministic and inspectable without mutable shared state. #### PDSL-104 — Stop treating an absent parcel weight as a zero-weight match **Bug · High priority · Advanced** noCV practice brief v5 · PDSL-104 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate and inspect. Depends on: PDSL-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 70% · Backend 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Pattern topics: Interpreter (refactor). Interpreter — Refactor: Replace coercion spread across conditions with one explicit interpreter result model and consistent missing-value semantics. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A carrier feed omitted weightGrams and the evaluator coerced it to zero. The parcel passed a weight limit despite having no measurement; OR branches also mask inconsistent missing-value behavior. Acceptance criteria - Define true, false, and unknown outcomes with explicit AND/OR truth tables and no implicit string/number coercion. - Missing referenced inputs produce unknown with the relevant field path; only true authorizes the synthetic routing decision. - Repeated evaluation of the same rule and parcel returns the same outcome and bounded explanation without mutating either input. Implementation constraints - Short-circuit only when the declared three-valued semantics permit it; retain enough information to explain the final outcome. Verification - Exercise every pair in both truth tables, including false AND unknown and true OR unknown. - Evaluate missing, null, zero, and numeric-string weights and assert the distinct documented results. Deliverables - Typed evaluation result, truth-table regression cases, and explanation format Rollout and recovery: Compare decisions against a synthetic parcel corpus; keep unknown outcomes in a review queue and revert the evaluator by version. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PDSL-105 — Keep draft rule builders from changing previously saved expressions **Bug · Medium priority · Intermediate** noCV practice brief v5 · PDSL-105 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate and inspect. Depends on: PDSL-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 50% · Frontend 30% · API design 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Pattern topics: Builder (compare). Builder — Compare: Assess whether staged rule construction earns its complexity and make the handoff from a mutable draft to an immutable expression explicit. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The rule editor reuses a builder to produce two templates. Adding a condition to the second template mutates the first because both saved objects reference the builder's child array. Acceptance criteria - A build operation returns an immutable validated expression with no writable references to builder state. - Incomplete drafts identify missing fields without emitting a partially valid saved rule. - Building twice and then editing the draft cannot change either earlier result or its serialized bytes. Implementation constraints - Compare a builder with ordinary validated object construction; retain staged construction only where it improves the editor's incomplete-state handling. Verification - Build two rules from one draft and edit a nested child; verify both saved rule snapshots stay unchanged. - Attempt to build a comparison without a literal and confirm no persisted rule identity is allocated. Deliverables - Draft-to-rule construction API and shared-reference regression reproduction Rollout and recovery: Switch local editor saves behind a construction flag; old saved rules stay readable if the editor construction path is reverted. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PDSL-106 — Give the support inspector a stable walk through nested conditions **Task · Medium priority · Intermediate** noCV practice brief v5 · PDSL-106 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate and inspect. Depends on: PDSL-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 60% · Developer tooling 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Pattern topics: Iterator (apply). Iterator — Apply: Provide a shared traversal contract for independent tree consumers without exposing the representation or coupling their presentation logic. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The support inspector duplicates recursive loops for a tree outline, field usage report, and copyable diagnostics. These loops disagree on child order and sometimes skip a nested condition. Acceptance criteria - Expose a read-only depth-first iterator that yields each node once with a stable path and parent path. - The outline and field usage report consume the same traversal contract while retaining their own presentation rules. - Early termination releases traversal state, and malformed cycles are rejected instead of looping indefinitely. Implementation constraints - Do not expose the mutable traversal stack or allow consumers to rewrite children during iteration. Verification - Walk a mixed tree and compare the complete path order used by both consumers. - Break after the first leaf, then start a fresh iteration; also supply a manually constructed cycle and assert a bounded error. Deliverables - Traversal API, two migrated consumers, and cycle/early-exit checks Rollout and recovery: Compare inspector output before replacing the duplicated traversals; restore the old read path if ordering changes unexpectedly. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PDSL-107 — Measure whether interning field symbols actually reduces rule-cache memory **Task · Low priority · Advanced** noCV practice brief v5 · PDSL-107 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evaluate and inspect. Depends on: PDSL-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Compiler and language tooling 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Pattern topics: Flyweight (compare). Flyweight — Compare: Test whether sharing intrinsic symbol metadata saves enough memory while keeping source, tenant, and evaluation context out of shared objects. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A heap profile suggests thousands of cached rules repeat the same field and operator metadata. The proposed optimization shares entire nodes, including source locations and tenant rule identifiers. Acceptance criteria - Benchmark an authored 10,000-rule synthetic corpus before and after sharing only immutable context-free symbols. - Keep source spans, rule identities, and parcel evaluation state outside shared symbols, and bound or evict the intern pool. - Report retained heap, parse time, and identical rule outcomes across repeated runs; retain the optimization only if the measured tradeoff justifies it. Implementation constraints - State runtime, corpus seed, warmup, and measurement variability; a decision to remove the pool is an acceptable result. Verification - Compare all evaluation outcomes and source-specific diagnostics with pooling enabled and disabled. - Load many distinct invalid symbols and verify rejection cannot grow the intern pool without bound or reuse another rule's source range. Deliverables - Reproducible heap comparison and an evidence-backed keep-or-remove decision Rollout and recovery: Default pooling off until the local measurements pass review; disabling it must leave serialized rule content unchanged. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Evolve within limits Add syntax safely, bound adversarial inputs, and preserve old rule versions. #### PDSL-108 — Add membership expressions without leaving tree operations behind **Story · Medium priority · Expert** noCV practice brief v5 · PDSL-108 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evolve within limits. Depends on: PDSL-104, PDSL-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 70% · System design 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Pattern topics: Visitor (compare) · Composite (refactor). Visitor — Compare: Use a real new-node change to compare operation-oriented visitors with node-local methods and make the extension cost visible in the patch. Composite — Refactor: Integrate the membership leaf into the uniform expression tree without adding special group traversal paths or weakening node validation. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Warehouse rules repeat long chains such as zone == 'north' OR zone == 'west'. Adding IN to evaluation alone would leave validation, inspection, and serialization unaware of the new node. Acceptance criteria - Add string-set membership with a 50-item limit, explicit duplicate handling, and no implicit type conversion. - Update parsing, validation, evaluation, inspection, and serialization, with an exhaustive mechanism that exposes unhandled node kinds. - Compare visitor-based operations with node-local methods for this change and explain which extension axis becomes easier or harder. Implementation constraints - New syntax uses a new language version; existing rules retain their old version and behavior, including missing-field outcomes. Verification - Compare membership and equivalent OR rules over present, absent, matching, and nonmatching zones. - Run every tree operation on the new node; reject a 51-item set and an older parser receiving the new version. Deliverables - Membership implementation, operation coverage matrix, and extension tradeoff note Rollout and recovery: Enable authoring for the new version after all operations support it; turn off new authoring without rewriting saved older rules. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PDSL-109 — Bound rule parsing and explanation work before expensive allocation **Bug · High priority · Advanced** noCV practice brief v5 · PDSL-109 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evolve within limits. Depends on: PDSL-104, PDSL-108. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 50% · Security 30% · Performance engineering 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Pattern topics: Interpreter (refactor). Interpreter — Refactor: Make resource accounting part of the interpreter contract so nested expressions cannot bypass limits through separate parsing or explanation paths. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The editor rejects a deeply nested rule only after parsing its entire text. A pasted megabyte of repeated parentheses stalls the local worker, and explanations allocate one message for every attempted comparison. Acceptance criteria - Reject source text above 64 KiB before tokenization and enforce depth, node, and literal limits as input is consumed. - Bound evaluation steps and explanation entries independently; return distinct stable limit codes without partial routing approval. - After a rejected rule, the same process can evaluate a small valid rule with no retained traversal or explanation state. Implementation constraints - Use deterministic operation budgets rather than relying solely on wall-clock time; no regex features with unbounded backtracking are required by this language. Verification - Exercise just-below and just-above each declared bound with reproducible generated inputs. - Alternate rejected and valid rules for 100 runs; confirm bounded diagnostics and unchanged valid outcomes. Deliverables - Limit enforcement changes, adversarial local cases, and resource-bound report Rollout and recovery: Publish the limit codes in the local editor before enforcing them; revert language authoring if needed while retaining safe evaluator limits. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### PDSL-110 — Ship a rule-language upgrade with a reversible authoring boundary **Task · High priority · Expert** noCV practice brief v5 · PDSL-110 · Make fulfillment rules understandable without executing scripts Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Evolve within limits. Depends on: PDSL-105, PDSL-108, PDSL-109. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 50% · System design 30% · Site reliability 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Pattern topics: Interpreter (apply) · Builder (refactor). Interpreter — Apply: Keep interpreter semantics tied to stored language versions so deploying or reverting authoring code cannot silently change routing behavior. Builder — Refactor: Make version conversion an explicit construction step with a preview instead of rebuilding unknown nodes with guessed defaults. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The membership release introduces version 2 rules, but a rollback plan assumes every stored rule can still be opened by the version 1 editor. Saving an unrecognized node would silently discard a condition. Acceptance criteria - Route evaluation by saved language version and fail closed for unknown versions without rewriting the original rule bytes. - Keep unsupported rules read-only in an older editor and require an explicit conversion preview before creating a new version. - Demonstrate a rollback sequence that stops version 2 authoring while preserving version 2 evaluation or explicitly pausing those rules. Implementation constraints - Record conversion warnings and original version lineage; a builder must not invent defaults for unsupported expression nodes. Verification - Run a mixed-version synthetic corpus before upgrade, after upgrade, and through the documented rollback sequence. - Open a version 2 rule in the old editor and submit an unknown-version rule; verify neither path loses conditions or approves routing. Deliverables - Compatibility matrix, conversion preview, and rehearsed local rollback runbook Rollout and recovery: Stage evaluation support before new authoring, then enable one synthetic warehouse; retain versioned evaluators until all dependent rules are explicitly retired. Project prerequisites: Recursive data structures Parser error handling Discriminated unions Engineer value: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter. Company value: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence.