When should a fleet move from encoding/json to encoding/json/v2, and who owns the traffic it starts rejecting?

## What is actually being decided The question sounds like a dependency upgrade and is not. `encoding/json/v2` shipped in Go 1.27, and moving a call site to it costs one import line. What it changes is the set of documents your systems accept, and those documents are produced by people who do not report to you. That makes this a decision about *whose traffic may break, and on whose schedule* -- which is why it belongs to someone who can be overruled by a service team, rather than to whoever is doing the upgrade. Two commitments are entangled and worth separating. **The toolchain commitment.** The package exists only from Go 1.27, so a module using it must declare a `go` directive of at least that version. In Go 1.27 `go test` runs the `stdversion` vet check by default, so a module still declaring an older `go` line will be told it is using a standard-library package newer than it claims to support. That is a real cost for a fleet with a conservative pinning policy, and it is separable: a team can be on the toolchain for a year before it touches an import. **The strictness commitment.** Independent of the version, this is the one with a blast radius, and it is per call site. ## Adopt by position, not by percentage The useful axis is where a piece of code sits relative to a trust boundary. *Inbound edges* -- a gateway validating payloads before forwarding them, a webhook receiver, anything parsing a document from outside -- are where strictness is the product. Rejecting a document with duplicate object names is precisely what you want at the place where two components could otherwise disagree about which value counts. Adopt here first. *Interior services* that decode documents your own code encoded gain little. The producer is under your control, so the class of defect v2 rejects mostly cannot occur, and the migration risk -- particularly the quiet one, a member that used to match case-insensitively and now does not -- is pure cost. Adopt here on the ordinary schedule of touching that code, not on a campaign. *Round-tripping code* -- a proxy that reads a third-party document, modifies one member and forwards the rest -- is the case to be most careful with, because you are not the author of what passes through and you may not be entitled to refuse it. Keeping the older package here can be the correct permanent answer, and a policy that cannot express "never, deliberately" will be routed around. ## Evidence before schedule A campaign that says "all services on v2 by Q3" without measurement converts an unknown number of partner outages into a deadline. The precondition I would put in writing is that no inbound route flips until a shadow decode over live traffic has produced a list: which sender, which class of rejection, on which route. That list is the artefact the decision actually needs, because it turns "strictness might break things" into a set of named conversations with dates. ## Who holds the veto The platform owner sets direction; the team facing the partner owns the rejection. Formalise that rather than resolving it in an incident. The mechanism is already in the API: the loosening options are per call, so a service team can adopt v2 everywhere and pass `jsontext.AllowDuplicateNames(true)` on the one route whose partner is still fixing an encoder. That exception should carry a comment naming the partner and the date it is expected to go, and it should be reviewed like any other dated debt. What should not be policy is the build-level opt-out. Rebuilding a service with `GOEXPERIMENT=nojsonv2` reverts an entire implementation for reasons nobody records, hides which package was affected, and does not even undo an import that was already changed. It is a diagnostic tool for a suspected regression in the reimplementation of the old package, not a governance instrument. ## The part that is not about decoding One more cost belongs in the decision because it is easy to miss: the redefinition of `omitempty` changes what services *emit*, not only what they accept. A service that adopts v2 for its own strictness starts putting `"verbose":false` on the wire where it previously omitted the member. That is a change to a published payload, and if consumers distinguish absent from false, the adopting team has just modified an interface it may not own. A policy that only talks about rejection has covered half the change. ## The position to defend Strictness is worth buying at the boundary and rarely worth a campaign in the interior; measurement precedes schedule; the exception mechanism belongs to the team holding the relationship; and the toolchain pin is a separate, cheaper decision that can be made first.