Be permissive at input and strict at output

What it is

A tolerant reader, canonical writer accepts multiple local surface forms when they are equivalent and safely interpretable, then stores, exchanges, or emits a declared canonical representation. “Permissive input” means traceable input normalization, not ignoring errors. “Strict output” means a stable, unambiguous contract with types and units, not writing an unconfirmed guess as fact. If two interpretations produce different values, the system must ask or reject rather than silently choose.

Why it happens

People enter familiar spaces, hyphens, case, full-width or half-width characters, and local grouping. Downstream systems need stable data for comparison, deduplication, calculation, and interchange. Parsing known-equivalent surface variants into a structured value reduces pointless rejection; generating canonical output from that value prevents every consumer from guessing again. Normalization can nevertheless change meaning: removing decimal or date separators, folding Unicode characters, or altering leading zeroes may turn one value into another. A robust pipeline therefore preserves the original, parses, resolves ambiguity, produces the canonical value, and records the rule version.

Studying it

Build a variant corpus and label each sample as equivalent, parseable but ambiguous, invalid, or unknown, with review by people familiar with the target regions. Measure acceptance of legitimate variants, invalid-input leakage, silent value changes, confirmation requests, and round-trip consistency separately. Property-based tests can assert that parse(format(value)) preserves the semantic value; differential tests can reveal disagreement among client, server, importer, and exporter. Report inputs that were accepted yet changed meaning as their own failure class, because they are less visible than explicit rejection.

Where it stops holding

Automatic normalization is appropriate only when equivalence is established, the conversion can be explained, and no business or security boundary is crossed. Amounts, decimals, dates, units, names, passwords, signed material, and opaque identifiers may contain characters that look decorative but carry meaning. Generic trimming, case folding, or character folding can corrupt them. Preserve the original representation where an external protocol requires byte-for-byte fidelity. For high-impact or irreversible actions, show the interpretation and seek confirmation whenever ambiguity remains.

Applying it

• Define accepted grammar, permitted equivalence transforms, ambiguity conditions, canonical internal type, and output representation per field. Do not reuse a global “clean string” function.
• Retain the original input alongside the parsed structured value and record the parsing-rule version. Automate only transformations proven to preserve meaning, and make the interpreted result visible on echo-back.
• When date order, decimal separator, unit, or character identity has more than one plausible interpretation, request context or confirmation. Never mutate the value silently through a default region.
• A successful parse must consume all input except explicitly permitted outer whitespace; any remainder requires an error or confirmation. Specify API, export, and UI output contracts for type, time zone, unit, precision, encoding, and missing values, then run round trips with trailing junk, repeated units, and concatenated values.

Related

• Same group: S2.09.1 Regular-expression validation usually embeds a single-region assumption · S2.09.2 Identity-document numbers vary by format and length · S2.09.3 Validation errors must explain the expected format
• Adjacent: S2.02.4 Numeric input must accept local formats · S2.03.4 Separate timestamp storage from localized display
• Search terms: tolerant reader canonical writer · input normalization · round-trip parsing