Decode Error Taxonomy¶

Failure-classification policy — instantiates Round-Trip Code Alignment

A classified catalogue of every way a decode can fail — malformed, unsupported, ambiguous, incomplete, unsafe — each mapped to a mandated handling rule, so the decoder responds deliberately instead of guessing or crashing.

Every other mechanism here tends the happy path; Decode Error Taxonomy governs what happens when it breaks. It presumes that some inputs will fail to decode and pre-decides, for each class of failure, exactly what the decoder must do — reject, ignore, quarantine, renegotiate, or refuse — so behavior on bad input is designed rather than improvised in a catch block. Its defining move is to convert "the receiver interpreted an invalid message anyway" into a small, closed set of named cases, each with one mandated response, and to place a hard stop on the class that is not merely broken but unsafe. It is the written answer to the question every decoder eventually faces: this input is wrong — now what?

Example¶

A bank's gateway parses inbound payment messages in a standard financial format such as ISO 20022 or ISO 8583. A decode error taxonomy classifies the ways a message can fail and fixes one response to each: malformed syntax → reject with a precise diagnostic code; an unknown but optional field → log and ignore; an unsupported message version → route to the migration path rather than reject; an ambiguous or incomplete amount → quarantine for human review and never post; a suspected injection or a decompression bomb → refuse outright and alert security. Because every class has exactly one mandated action, a garbled or hostile message can never be quietly "interpreted anyway" into a wrongful transfer. The taxonomy is where the institution writes down, in advance, that when in doubt it does not act.

How it works¶

Enumerate failure classes, not instances. Malformed, unsupported, ambiguous, incomplete, stale, unsafe — a small closed set that covers the ways decoding breaks, so no failure is unaccounted for.
Map each class to a mandated response. Reject, ignore, quarantine, renegotiate, or refuse-and-alert — decided once by the designers, not left to whoever wrote the parser.
Draw the interpretation line. Ambiguous or incomplete input means do not act; unsafe input means refuse. The taxonomy is where "when in doubt, don't" becomes an enforced rule rather than a hope.

Tuning parameters¶

Strictness — how liberal the decoder is with imperfect input. Tolerance improves interoperability, but the "liberal in what you accept" half of the robustness principle is a well-documented attack surface.^[1]
Class granularity — a few coarse buckets versus many fine ones. Finer classes enable precise handling at the cost of a heavier catalogue to maintain.
Quarantine versus fail-fast — whether ambiguous input is held for a human or rejected immediately. Safety against throughput.
Escalation thresholds — which classes silently log, which page an operator, and which alert security.

When it helps, and when it misleads¶

Its strength is converting undefined behavior on bad input into deliberate, auditable responses — the difference between a decoder that fails safe and one that acts on garbage. It is the home of the "unsafe → refuse" rule that keeps a malformed message from becoming an exploit.

It misleads when the catalogue is incomplete: a novel failure with no matching class gets funneled into whichever bucket the fallback names, and the fallback is too often the permissive one. Over-tolerance compounds the risk, quietly widening the attack surface in the name of interoperability. The classic misuse is a catch-all "on any error, do our best to proceed," which re-creates precisely the "interpreted an invalid message anyway" failure the taxonomy exists to prevent. The discipline is to default the unknown failure to REFUSE rather than proceed, and to revisit the taxonomy whenever a failure escapes every named class.

How it implements the components¶

Decode Error Taxonomy realizes the failure-handling side of the archetype — the components that govern the unhappy path:

decode_failure_handling — it is the failure-handling policy: the classified map from each failure class to its mandated response.
security_boundary_guard — it owns the "unsafe decode" class — injection, resource-exhaustion bombs, hostile input — and mandates refuse-and-alert, drawing the security boundary precisely at the decode step.

It does not detect corruption in the first place (that is Checksum or Hash Validation) — it classifies and handles what detection surfaces; it does not negotiate versions (that is Version Negotiation Handshake); and it does not implement the decoder whose failures it governs (that is the Parser/Emitter Pair).

Instantiates: Round-Trip Code Alignment — supplies the deliberate, safe behavior for every way a decode can go wrong.
Consumes: Checksum or Hash Validation — the detection layer that surfaces the corruption this taxonomy then classifies.
Sibling mechanisms: Codec Specification · Round-Trip Property Test · Golden Test Vectors · Canonicalization Rule · Checksum or Hash Validation · Parser/Emitter Pair · Compatibility Matrix · Schema Registry · Lossy Compression Profile · Migration Adapter · Version Negotiation Handshake

References¶

[1] Postel's robustness principle — "be conservative in what you send, be liberal in what you accept." Decades of security experience show that the "liberal in what you accept" half is a double-edged sword, tolerant parsing being a recurring source of vulnerabilities; this is why the taxonomy lets the unsafe class override leniency. ↩