Diagnosing YAML Implicit Boolean Conversion (the Norway Problem)

When a configuration file contains an unquoted scalar like no, off, on, yes, y or n, some YAML parsers silently convert it to the boolean values false or true. This can turn a country code country: no into false or a mode label mode: off into false, breaking downstream logic that expects the original string.

Recognizable Condition

• Value appears as false/true when the source contains an unquoted yes/no/on/off/y/n.
• A mapping key written as on: (or off:, etc.) is loaded as the boolean key true (false) so lookups by the string on fail and round‑tripped files show True: or False:.
• The same file works in one tool but fails in another, indicating mixed YAML 1.1 and 1.2 consumers in the pipeline.

Cause / Diagnostic Table

Ordered Checks

1. Reproduce with a minimal snippet: load the suspect YAML and print the resolved type and value (e.g., in Python yaml.load(data, Loader=yaml.BaseLoader) or the equivalent in your language).
2. Confirm the scalar is unquoted in the source file (search for the pattern yes/no/on/off/y/n not surrounded by quotes).
3. Identify the YAML library and schema mode each consumer uses (check documentation for YAML 1.1 vs YAML 1.2 core or flags like PureLoader, SafeLoader, FullLoader).
4. Check whether any formatter, generator, or CI step rewrote the file and altered quoting (diff the file before and after the step).

Fixes Tied to Findings

• Quote ambiguous scalars: change mode: off to mode: 'off' (single or double quotes).
• If the parser supports explicit tags, use mode: !!str off.
• Standardize new services on a YAML 1.2 core‑schema parser (e.g., PyYAML >=5.1 with yaml.YAML(typ='safe'), SnakeYAML 1.27+, or libyaml with YAML 1.2 mode).
• Add a lint or style‑guide rule that rejects unquoted y/n/yes/no/on/off as both values and keys (many YAML linters have this check).

Escalation Criteria

• Treat as a data incident if wrongly typed values were persisted to storage or emitted to downstream consumers; the fix must include backfill or re‑emission of the corrected data.
• Escalate to platform or shared‑library owners before changing a common parser’s resolver, because that change affects every consumer at once.

Limitations and Practical Verification

• The behavior is library‑ and version‑specific; do not assume all parsers in your pipeline agree — verify each consumer’s actual dependency.
• Quoting fixes values but not keys; a key like on: needs the same quoting or a parser‑side resolution change.
• Some ecosystems layer their own resolvers on top of a YAML library, so library defaults alone may not predict the final type a consumer sees.
• Do not hand‑edit generated config to add quotes without fixing the generator, or the regression returns on the next render.
• Practical check: load a one‑line snippet (e.g., mode: 'off') with each parser in the pipeline and print the resolved type and value; compare against the expected string.
• Search config repositories for unquoted yes/no/on/off/y/n used as values and as keys, and review the hits manually.
• Check the chosen library’s documentation or changelog for its schema (YAML 1.1 vs 1.2 core) and any flags controlling boolean resolution.
• Round‑trip a representative file through any tool that rewrites YAML and diff the parsed types before and after.