Skip to content

Strict Output Linter

Emit-side conformance tool — instantiates Asymmetric Interface Tolerance Calibration

Checks everything a system is about to emit against the canonical form and blocks non-conformant output at the source, so producers never teach the ecosystem a sloppier contract.

Strict Output Linter is the "strict writer" half of the interface made mechanical: an automated checker that inspects what a system is about to send and refuses to let anything non-canonical leave. Its defining move is that it points outward at its own output, not inward at inputs — it is the discipline of being conservative in what you emit, enforced by a tool rather than left to good intentions. By collapsing every producer to a single canonical form[1] before anything ships, it keeps the ecosystem from learning a looser de-facto contract than the written one — and it is exactly what makes a liberal reader elsewhere affordable: receivers can be tolerant because emitters are policed.

Example

A scientific-journal publisher ships article XML to aggregators and indexers in JATS, a standard flexible enough that the same article can be encoded several valid-but-divergent ways. Left unchecked, each production vendor drifts into its own dialect, and downstream systems quietly start depending on one house's quirks. So the publisher runs a strict output linter in its build: before any article is released, the linter checks it against the publisher's canonical JATS profile — required metadata present, one approved way to tag an affiliation, no deprecated elements, dates in the single blessed format. A file that validates against raw JATS but violates the house profile fails the build, with the offending element and line called out, and never reaches an aggregator. The published corpus stays uniform, so consumers integrate against one shape instead of guessing which vendor produced which file.

How it works

  • A canonical target, not just "valid." The linter checks output against a tightened profile — the single approved form — usually far narrower than the base spec's notion of "well-formed."
  • At the source, before send. It runs at author or build time on the emitter's side, so nonconformity is caught by the party that can fix it, not discovered downstream.
  • Oracle, not guesser. It is a deterministic conformance oracle: given an artifact it answers conform / does-not-conform with a specific reason, and it can be pointed at generated and adversarial cases to prove the emitter never produces off-spec output.
  • Block, don't repair. It fails the output rather than silently fixing it, so the producer's own code gets corrected instead of a normalizer masking the defect forever.

Tuning parameters

  • Profile strictness — how far the canonical form narrows the base spec. Tighter yields more uniformity but flags more benign variation and irritates producers.
  • Blocking vs. warning — whether a violation fails the build or merely warns. Blocking guarantees conformance but can halt shipping; warning informs without teeth.
  • Rule granularity — how specifically each violation is reported (element, line, fix hint). Finer messages speed correction but cost authoring effort.
  • Oracle coverage — whether it checks only hand-written cases or also fuzzed and generated output, to catch emit paths ordinary tests miss.
  • Waiver handling — whether a producer can suppress a specific rule, and whether suppressions are tracked, so the canonical form doesn't erode one silenced warning at a time.

When it helps, and when it misleads

Its strength is upstream leverage: fixing output at the emitter is far cheaper than every receiver coping with variety forever, and a policed emit side is the precondition that lets the accept side be generously tolerant without the protocol rotting. A strict linter also makes drift visible and blockable the moment it appears, rather than after a dialect has spread.

Its limits are two. First, it governs only what you emit — it cannot make the peers you receive from conform, so it is half of an interface and must be paired with acceptance-side handling for inbound traffic. Second, its classic misuse is being run backwards: teams facing a deadline silence the rules or downgrade blocking to warning "just this once," and the canonical form quietly dissolves into whatever shipped. A linter is only as strict as its least-enforced rule. The discipline is to keep the profile itself under version control and review, and to treat a rising count of suppressions as erosion to reverse, not noise to ignore.

How it implements the components

  • outbound_conformance_policy — it operationalizes "strict about what you send": the canonical profile is the emit policy, and the linter is its enforcement point.
  • conformance_and_fuzz_oracle — it is the deterministic oracle that decides whether an emitted artifact conforms, and it can be driven with generated cases to prove the emitter never goes off-spec.

It does not define how tolerant the receive side should be (that's Tolerant Reader / Strict Writer Policy), does not probe the acceptance boundary for what a receiver wrongly admits (Fuzz Testing Against Acceptance Boundary), and does not hold ambiguous inbound items for a human (Quarantine and Manual Review Queue).

Notes

A strict output linter is one-directional by construction: it disciplines your side of the wire and says nothing about what arrives. It pairs naturally with a tolerant reader (you accept variety but never add to it) and with contract tests or version negotiation for the inbound half. Deployed alone and mistaken for a whole interface policy, it leaves the receive side ungoverned.

References

[1] Canonical form — a single, normalized representation chosen as the one correct way to encode something, out of many a permissive spec would treat as equally valid. A strict output linter enforces the canonical form on emit, which is what stops otherwise-equivalent variants from proliferating. ↩