Loading today’s stories
Build1 distinct publisher3 min readPublished
According to a dev.to writeup measured on gemini-3-flash-preview, the required array governs emission order whenever propertyOrdering is unset, so a derived field placed early gets decided before the evidence for it has been written.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Constrained decoding guarantees membership, not selection. `L3-OPS` and `L3-TECH` are both legal members of the same 143-value enum, so nothing objected when `role_code` disagreed with the `department` field emitted eight positions later [9][25].
Order is the mechanism. The model writes the object in one forward pass, and a token already emitted cannot be revised when a later field contradicts it [6]. The v18 required array lists fourteen fields with `role_code` third [14], which leaves eleven of them, 79 percent of the schema, downstream of the decision they were meant to inform [15]. `department`, which agreed with the correct reading in all four failures, came out eleventh [10].
The boring explanations were ruled out first: byte-identical schemas, the wrong code already present in the raw provider response rather than introduced by downstream mapping, the correct enum value present and used correctly elsewhere in the same responses, and source documents with zero matches for operations wording against 11 to 20 matches for technical wording each [11]. That is the order I would want the diagnosis done in.
Nine CVs, all advertising the same role, is a thin sample, and 5 of 9 to 9 of 9 is a four-document swing [13][16]. The mechanism travels better than the ratio. Three things have to hold for that number to mean anything in your pipeline: you have derived fields whose evidence lives in other fields of the same response; you leave `propertyOrdering` unset, as this team does everywhere [5]; and your enum is wide enough that a wrong answer still validates [9].
Reordering `required` is a refactor with no type checker behind it. Once `department` moved ahead of `role_code`, its description still told the model to classify from the stated `role_code`, which is the same failure one level down [17]. Descriptions are prose to the decoder. Only real enum arrays are enforced, and values listed in a description are not constrained at all [18]. The fix itself needed no change to types, enums or shape [12].
Reordering alone is also silent, so v19 told the model where to look: "You have ALREADY emitted the work_history array above. Read the title of its first entry and use it" [19]. The opposite failure was then checked. Two candidates whose most recent entry sat one level below the advertised role still came back with the advertised level, because the stated position legitimately outranks work history in that ladder [20].
My own read, for a schema that is version-controlled against a pinned model: if required order governs only in the absence of `propertyOrdering` [5], depend on the documented field instead. Set `propertyOrdering` to the same identity, then evidence, then derived sequence the post recommends [24], and the behaviour you rely on sits somewhere Google has agreed to support. Two of the five rules I cannot price from what is published here. The post says to count total enum values because the ceiling is undocumented and lower than you expect [21], and that `PROVIDER_EXHAUSTED` immediately after a prompt change means a broken schema rather than a busy provider [22]. I am not going to guess a limit on someone else's quota.
Ranked by verification strength, evidence, and original report placement.
Gemini emits every required property first, in exactly the order the required array lists them, then the optional ones; declaration order inside properties is ignored for the required set.
The behaviour was measured twice on gemini-3-flash-preview with opposite orders, reading the raw response text; a field that was 12th in properties and 3rd in required came out 3rd.
propertyOrdering is the documented knob, but the team does not set it anywhere, and absent it the required order is what governs.
Schema v18 put role_code third in required, after only first_name and last_name; its instruction was a priority ladder whose second priority was the title of the most recent work_history entry, emitted 4 fields later.
Across nine CVs all advertising the same role, four came back with role_code L3-OPS, a role from a different department, and all four were internally self-contradictory, pairing L3-OPS with department Technical and a work_history title of L3-TECH.
The department field was emitted 11th and agreed with the correct reading in all four failing cases, so the consistency check was generated downstream of the error.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 28, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Count invalid JSON as a failed classification, and model choice becomes a reliability problem1 distinct publisher
security
Washington names industrial-scale distillation, then hands the detection bill to abuse teams1 distinct publisher
security
Google's reference agent approved a $10,000 refund on a $149 order, on purpose1 distinct publisher
build
An empty MCP tool list is a successful response, and the bug is on the server side1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One careful witness, no second one
dev.to's post is unusually explicit about method for a practitioner writeup — schemas compared byte-for-byte, the wrong code located in the raw provider response rather than downstream, keyword counts run over the source documents to kill the ambiguous-input explanation, the ordering rule measured twice with opposite arrays. What it cannot supply is corroboration: the client is scrubbed, no responses or schemas are published, the decisive run is nine documents on a preview checkpoint, and the enum boundary is an interval the author says he never bisected.
One pipeline, shipped
The behaviour is in production somewhere — v19 is described as already reordered and the five rules as what the team builds against now — but that is the whole footprint. No other team reports the required-array effect, no framework or SDK encodes it, and Google has neither documented nor contradicted it. The one thing that travels beyond a single deployment is the enum rejection reproducing across three checkpoints, which says the surface is stable, not that anyone else has met it.
Title generalises further than the run does
Five undocumented rules for Gemini structured output is a lot of ground for one extraction pipeline, nine CVs and an untested interval to cover, and the ordering rule in particular is stated as how Gemini behaves rather than how it behaved on gemini-3-flash-preview in one schema. The overshoot is modest because the post argues from a mechanism that is genuinely general — one forward pass, no revising an emitted token — and because it flags its own limits, including the unbisected ceiling and the over-anchoring risk in its own fix.
Credibility, not commerce
Nothing is for sale in this post. No product, no consultancy, no client name, no vendor relationship — the domain is anonymized down to renamed role codes, and the return on publishing is standing among other Gemini users. The pressure that remains is narrative rather than commercial: a story where one array reorder lifts 5 of 9 to 9 of 9 is cleaner than most debugging actually is, and the same anonymization that removes the commercial motive also removes any way for a reader to audit the numbers. Google, whose documentation is the implicit target, has no voice here at all.
Test it on your own schema before believing it
We hold the mechanism more firmly than the measurements. Autoregressive commitment is not in dispute, and the diagnosis reads like someone who actually eliminated the boring causes before reaching for the interesting one. But one author, one pipeline, single-digit samples and a preview checkpoint is a narrow base for rules stated at the level of the whole API. The ordering claim is cheap enough to verify yourself that there is no reason to take it on trust.