skip to content

When a platform mandates one wire encoding, what evidence justifies an exception for a single integration surface?

level: seniorimportance: nice to knowfreq 30%

answer

  1. the default wins ties
  2. burden of proof sits on the exception
  3. name a criterion, not a preference
  4. measure this hop, not another
  5. bound the scope, owner and expiry

basics

~20 s

Evidence tied to a criterion the standard did not anticipate on this hop: a measured cost, a consumer set with no decoder, a different trust boundary, or a fidelity requirement. Preference and familiarity are not evidence.

solid answer

~40 s

The burden of proof sits on the exception, because the default already paid for itself in toolchains nobody has to learn twice. To carry it I show that one of the selection criteria takes a different value on **this** hop than the standard assumed, with a measurement rather than an assertion: payloads an order of magnitude larger than the standard's assumed shape, a consumer ecosystem with no maintained decoder, a trust boundary the standard never considered, or a fidelity requirement the default encoding cannot express. Then I bound it: which surface, who maintains the second toolchain, and what condition ends the exception. An exception with no scope and no expiry is not an exception, it is a second standard acquired by precedent.

go deeper

for a junior

Understand that a platform standard exists to make most encoding choices unnecessary, and that departing from one is a decision that needs a reason someone else can check.

for a middle

Be able to name which criterion your surface breaks and show the measurement, rather than arguing that the alternative encoding is generally better.

for a senior

Bring a bounded proposal: the surface, the criterion with its numbers, the maintainer of the second toolchain, and the condition that retires the exception.

for a principal

Write the standard as criteria and weights with an implied default and a defined exception path, so that unanticipated hops resolve on evidence instead of escalating into a question of authority.

## A default is a decision already paid for A platform-wide encoding standard is not bureaucracy; it is the uniformity benefit banked once so that every subsequent hop costs nothing to decide. Its value is precisely that most teams never open the question. That is why the burden of proof sits on the exception rather than being shared: the default's cost was paid up front, and every departure withdraws a little of it — one more library in the graph, one more decode failure shape on call, one more thing a new engineer must know before they can debug across the system. So the exception's case is not "this encoding is better". It is narrower: **a criterion takes a different value on this hop than the standard assumed**, and here is the measurement that shows it. ## What counts as evidence | Ground | What you show | Why it survives review | |---|---|---| | A hard constraint fails | A consumer ecosystem with no maintained decoder for the mandated encoding | An unusable candidate is not a preference; the standard simply does not apply here | | The assumed shape is wrong | Measured payloads and rates from this surface against the standard's assumption | The standard was calibrated on a shape this hop does not have | | The trust boundary differs | This surface takes input from unauthenticated callers, unlike the hops the standard was written for | A criterion the standard never weighed | | Fidelity cannot be expressed | A value this hop must carry that the default encoding flattens or cannot distinguish | Correctness, not taste | | The operating mode differs | Incident handling on this surface depends on reading captured payloads directly | A criterion weighted differently by how the hop is operated | The common thread is that every row names a **property of the workload**, verifiable by someone who does not trust you, and none of them is a property of the team. ## What does not count - **Familiarity.** "We have used it before" is a genuine cost, but it belongs to the team rather than the hop, and it does not transfer when the team changes. - **A borrowed benchmark.** Numbers measured on a different payload shape, message size or rate say nothing about this surface; measure this one. - **A margin inside the noise.** A size or speed win that disappears under compression, or that is small against the standard's uniformity benefit, is not a reason. - **Aesthetics.** "Cleaner" is not a criterion, and when it is the strongest argument available, the exception has already failed. - **Silence.** Routing around the standard without a decision is worse than losing the argument, because the cost lands on everyone and the reasoning is preserved nowhere. ## The shape of a good exception 1. **Scope.** Exactly which surface is exempt, and explicitly not anything adjacent to it. An unscoped exception spreads by precedent within a quarter. 2. **The criterion.** One named criterion, with the measurement, stated in terms the standard itself uses. 3. **The owner.** Who maintains and patches the second toolchain, answers questions about it, and is called when it breaks. 4. **The expiry condition.** What would make the exception unnecessary — a maintained decoder appearing in the last consumer ecosystem, the volume falling, the surface being retired — and who checks. ## Writing standards that expect exceptions A standard that names a single blessed encoding and nothing else guarantees that every genuinely different hop becomes a fight. A better one states the **criteria and their weights**, names the default that those weights imply for the common case, and describes what a valid exception looks like. Then an exception is an ordinary application of the standard rather than a defiance of it, the argument is about evidence rather than authority, and the cases that were never anticipated resolve without escalation. ## Where this goes wrong - The exception is granted and the second toolchain is nobody's: it goes unpatched until a decode failure reaches production. - No expiry condition is written, so the exception outlives its reason by years. - The scope is written loosely — "the reporting surfaces" — and quietly grows into a parallel standard. - The measurement is taken once and never repeated, even though the volume that justified it fell by an order of magnitude. - The standard is treated as a veto rather than as encoded weights, so teams stop asking and start routing around it.

  • What kinds of argument are genuinely not enough to carry an exception?
    Anything that is a property of the team rather than of the hop: familiarity, aesthetics, a benchmark borrowed from a different payload shape, or a margin that vanishes under compression. These are real costs but they do not show that the standard's assumptions fail here, which is the only thing that turns an exception from a preference into a decision.
  • How should an encoding standard be written so that exceptions do not require a fight?
    State the criteria and their weights, then name the default those weights imply for the common case, and describe what a valid exception looks like. A standard expressed as weights lets a genuinely different hop be resolved by applying the standard rather than by defying it, and moves the argument from authority to evidence.

saying these in an interview costs you the question

  • Argues from personal familiarity with an encoding rather than the workload.
  • Cites a benchmark measured on a different payload shape and rate.
  • Treats the standard as an obstacle to route around quietly.
  • Wins the exception without stating what would end it.
  • Leaves the second toolchain with no named maintainer.
  • Writes the exemption scope loosely enough to keep growing.