Tolerant Reader / Strict Writer Policy¶
Interface strictness policy — instantiates Asymmetric Interface Tolerance Calibration
Sets the interface's standing regime as deliberately asymmetric — strict about what the system emits, liberal about what it accepts — and writes that choice down as policy rather than leaving it to each parser.
Tolerant Reader / Strict Writer Policy is the archetype's namesake move stated as a standing rule: emit conservatively, accept liberally, on purpose and in writing. Its defining contribution is the decision itself — it fills in the strictness matrix's asymmetric cell and defines how wide the accept side may open, so the interface's tolerance is a governed choice rather than an accident of whatever each implementer happened to code. It does not itself lint output or normalize input; it declares the regime those tools then carry out. The point of writing it down is that "be liberal in what you accept" is only safe when paired with a bound: the policy states both which asymmetry the interface runs and how far the tolerance extends before it stops.
Example¶
A city's open-data platform ingests spreadsheets from dozens of departments — police, transit, parks — each maintained by different people with different habits: date formats, column names, encodings, stray header rows. A brittle importer would reject most of them and generate endless tickets. So the platform adopts a tolerant-reader / strict-writer policy. As a reader it accepts a wide, explicitly-bounded envelope: several date formats, case-insensitive headers, common encodings, blank lines. As a writer it emits exactly one canonical form to every downstream consumer — ISO dates, a fixed schema, UTF-8 — no exceptions. The policy document names both sides: here is the list of input variations we tolerate (and everything outside it is rejected, not guessed); here is the single output shape we guarantee. Departments get frictionless ingestion; every dashboard and API downstream sees one clean shape, because the messiness was absorbed at the reader and never re-emitted.
How it works¶
- Name the regime explicitly. The policy states the interface is strict-out / liberal-in — one cell of the strictness matrix — so the asymmetry is a recorded decision, not an emergent one.
- Bound the accept side. "Liberal" is defined as a specific enumerated envelope of tolerated variations, with a hard edge beyond which input is rejected rather than charitably interpreted.
- Delegate enforcement. The strict-emit clause is handed to an output linter; the normalization of accepted variants to a canonicalizing parser. The policy sets direction; other mechanisms execute it.
- Keep the two sides from leaking. Crucially, tolerated inbound variety is never propagated outbound — what the reader accepts loosely, the writer still emits strictly, so tolerance stops at the boundary.
Tuning parameters¶
- Accept-envelope width — how many inbound variations are tolerated. Wider eases integration but enlarges the surface the reader must handle correctly and safely.
- Asymmetry direction — the usual strict-out / liberal-in can be flipped to strict-in / liberal-out for a source-of-truth publisher; the policy is where that per-direction choice is made.
- Envelope explicitness — whether tolerated variants are enumerated or left to "be reasonable." Enumerated envelopes are safe and testable; vague ones invite scope creep and silent protocol expansion.
- Repair visibility — whether accepted-but-nonstandard input is silently normalized or normalized-and-flagged, trading a quiet interface against a signal that a producer is drifting.
- Review cadence — how often the envelope is revisited, so "temporary" tolerances don't harden into a permanent second contract.
When it helps, and when it misleads¶
Its strength is resilience without decay when — and only when — both halves are honored: strict emission keeps the ecosystem's de-facto contract from rotting, while bounded liberal acceptance keeps harmless variation from causing needless failure. Writing the regime down is what makes it auditable and testable instead of a folk practice scattered across parsers.
Its danger is the half-applied version. The interface-design canon is Postel's robustness principle — "be conservative in what you send, be liberal in what you accept"[1] — and its much-discussed failure is that liberal acceptance, left unbounded and unmonitored, teaches producers that the written contract is optional: the real protocol quietly becomes whatever receivers happen to tolerate, and every reader must forever bug-for-bug match every other. The classic misuse is invoking "tolerant reader" to justify accepting anything while quietly neglecting the strict-writer half — the discipline that actually holds the contract. The guard is to bound and enumerate the accept envelope, monitor what enters it, and enforce the emit side with real teeth: tolerance with an edge and a gauge, never tolerance as a shrug.
How it implements the components¶
strictness_regime_matrix— it is the filled-in matrix for this interface: the recorded per-direction decision that emission is strict and acceptance is liberal.inbound_acceptance_envelope— it defines the bounded set of inbound variations the receiver will tolerate, and the hard edge past which input is rejected rather than guessed.
It declares but does not enforce: the strict-emit side is carried out by Strict Output Linter, the actual normalization of accepted variants by Lenient Parser with Canonicalizer, and the specific treatment of unrecognized fields by the Unknown-Field Handling Rule.
Related¶
- Instantiates: Asymmetric Interface Tolerance Calibration — it is the explicit statement of the asymmetric regime the whole archetype turns on.
- Sibling mechanisms: Strict Output Linter · Unknown-Field Handling Rule · Strict Bidirectional Contract Gate · Lenient Parser with Canonicalizer · Quarantine and Manual Review Queue
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Tolerant Reader / Strict Writer Policy operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it sets the interface's standing regime as deliberately asymmetric — strict about what the system emits, liberal about what it accepts — and writes that choice down as policy rather than leaving it to each parser.
Independent corroboration: The frozen evidence defines Tolerant Reader / Strict Writer Policy as 'Sets the interface's standing regime as deliberately asymmetric — strict about what the system emits, liberal about what it accepts — and writes that choice down as policy rather than leaving it to each parser', so its operative form is Rule, Policy & Commitment.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: RFC 793: Transmission Control Protocol states the Internet robustness principle of conservative emission and liberal acceptance as an interface policy. This directly supports computer science as the best-evidenced historical home of the operation—Sets the interface's standing regime as deliberately asymmetric — strict about what the system emits, liberal about what it accepts — and writes that choice down as policy rather than leaving it to each parser.—while the alternates record adjacent lineages rather than mere domains of later use.
Related originating lineages:
- Engineering & Design (beyond software) — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: sets the interface's standing regime as deliberately asymmetric — strict about what the system emits, liberal about what it accepts — and writes that choice down as policy rather….
- Organizational & Management Science — Organizational management supplies a historically relevant adjacent lineage or formative practice for the operation—Sets the interface's standing regime as deliberately asymmetric — strict about what the system emits, liberal about what it accepts — and writes that choice down as policy rather than leaving it to each parser.—but the researched evidence more directly locates the defining lineage in computer science.
- Systems Thinking & Cybernetics — Feedback, system boundaries, stocks, flows, and regulation supplies a distinct formative lineage for the mechanism's tolerant reader strict writer policy logic.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus computer_science). The defining operation is: Sets the interface's standing regime as deliberately asymmetric — strict about what the system emits, liberal about what it accepts — and writes that choice down as policy rather than leaving it to each parser. The researched RFC 793: Transmission Control Protocol states the Internet robustness principle of conservative emission and liberal acceptance as an interface policy. That is mechanism-specific evidence for computer science as the historical origin. Organizational management remains represented among the uncapped alternates where it contributes a genuine formative practice, but broad deployment or governance of the operation is not by itself evidence that the mechanism originated there. origin_mode=single_lineage records lineage; domain_reach=universal separately records later applicability.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
References¶
[1] Thomson, M., and Schinazi, D. Maintaining Robust Protocols. RFC 9413, Internet Architecture Board (2023). Restates Postel’s robustness principle and explains how broad acceptance can entrench malformed behavior as a de facto contract that other implementations must reproduce. registry ↩ Show verification details
SupportedVerified against the work's full text
RFC 9413 states Postel's robustness principle as the long-standing guide to protocol design, in the quoted wording.
“The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols.”