Conditional chaining

The || operator joins rules into a fallback chain: if the first rule fails to produce a mapping, the second rule runs against the same input, and so on. This is invaluable when the source data has multiple plausible mappings and the engine should try them in priority order.

Pre-map plus vocabulary lookup

A common pattern: a Map supplies hand-curated codes for the values that the vocabulary cannot resolve, and a VocabMap handles the rest:

Map([
  ["legacy_code_A", "ICD10_A12.3"],
  ["legacy_code_B", "ICD10_B45.6"]
]) || VocabMap("ICD10")

If Map finds the input value, its replacement flows on. Otherwise VocabMap runs against the original input.

Two parallel maps with a Selector

The pre-map approach above only works if the chosen vocabulary actually has a code you can pre-map to. When that is not the case, the alternative is to run two independent rules into separate variables and combine with Selector — but this approach is slower and harder to read than || and should be reserved for genuinely independent mappings.

Family restrictions

• Mapping rules can only be ||-chained with other mapping rules.
• Aggregating rules can only be ||-chained with other aggregating rules.
• Not every rule supports || chaining. Each rule's reference page declares whether it does (look for supports || in the meta line).

Multi-step chains

Conditional chains can have any number of rules — the engine walks them in order until one succeeds:

Map([...]) || UsagiMap("file.csv") || Map([..., default_code])

The final entry can be a Map with a default value as a catch-all that guarantees a successful mapping.