The valid zone that could not hold the pallet
VelaFresh Logistics is a fictional cold-chain warehouse operator. Its receiving teams move inbound pallets from temperature-controlled trailers into storage zones before those pallets continue to customer orders.
VelaFresh built DockPilot to help with the first decision. A receiver scanned a pallet, added a short exception note, and received a proposed zone. DockPilot used one model call to balance ordinary operating preferences: avoid unnecessary handling, keep urgent pallets near outbound doors, and make sensible use of the zones Zone Control said were open.
Noor Bakshi was the warehouse automation engineer who owned DockPilot and its handoff to the warehouse-management system, or WMS. DockPilot could propose a location. The WMS was the component that reserved that location and released a forklift putaway task.
That division mattered even on a normal day.
How a pallet normally reaches storage
The receiver began the journey, but no person had to copy a zone identifier by hand. Inventory systems supplied the pallet's SKU attributes and the currently open zones. DockPilot proposed one zone and one handling reason. The WMS turned an accepted proposal into a forklift task. A location scan recorded where the pallet ended up.
The team had already improved this path once.
DockPilot's first prototype generated free-text locations. It could return a misspelled code, a zone that did not exist, or an explanation where the integration expected a field. Noor's team replaced that loose response with : the model had to emit an object matching a declared shape.
For each immutable putaway-request.v1, the team also built the zoneId enum from a pinned Zone Control snapshot. Zone Control owned capability, open status, reservable capacity, and the allocation version; the WMS remained the sole reservation and task-commit authority. If the snapshot listed ZONE-A, ZONE-B, and ZONE-C, those were the only identifiers the constrained call could return.
The improvement was real.
DockPilot could no longer invent ZONE-NEAR-DOOR. It could not select a zone the availability response had already marked closed or full. The pallet identifier had to match the request, the handling reason had to come from a small recognized set, and extra fields were forbidden.
After rollout, malformed proposals disappeared from the handoff. The integration stopped spending time repairing missing fields and fictional locations. The team began describing DockPilot's output as “restricted to valid live zones.”
The strongest guarantee in the room
The request for one inbound pallet asked the model for a putaway-proposal.v1 artifact under a contract equivalent to this:
{
"type": "object",
"required": ["palletId", "zoneId", "handlingReason"],
"additionalProperties": false,
"properties": {
"palletId": { "type": "string", "enum": ["PLT-2048"] },
"zoneId": {
"type": "string",
"enum": ["ZONE-A", "ZONE-B", "ZONE-C"]
},
"handlingReason": {
"type": "string",
"enum": [
"NEAR_OUTBOUND_DOOR",
"REDUCE_HANDLING",
"FOLLOW_RECEIVER_NOTE",
"NO_PREFERENCE"
]
}
}
}
The exact keywords supported by hosted model APIs differ. What mattered to VelaFresh was the tested contract of its pinned model and structured decoder: one object, three required fields, no extras, one request-bound pallet, one listed zone, and one recognized reason.
That is . The generated artifact conforms to its representation contract.
It is worth stating what the contract established before looking for anything it missed:
| Check | What passed |
|---|---|
| Object shape | Exactly the required fields appeared. |
| Pallet membership | palletId was PLT-2048, the pallet in this request. |
| Zone membership | zoneId was one of the three open zones in the request snapshot. |
| Reason membership | handlingReason was recognized. |
Those were useful production guarantees. None was fake, stale, or bypassed.
One chilled pallet
On the morning of the incident, a receiver scanned PLT-2048. Its fictional signed SKU profile said the assigned zone needed a certified capability interval of [2 C, 5 C].
The pinned Zone Control snapshot returned three choices:
| Zone | Open with capacity | Certified capability interval |
|---|---|---|
ZONE-A | Yes | [2 C, 5 C] |
ZONE-B | Yes | [6 C, 8 C] |
ZONE-C | Yes | [1 C, 4 C] |
The receiver added one note:
Stage near the outbound door.
DockPilot returned:
{
"palletId": "PLT-2048",
"zoneId": "ZONE-B",
"handlingReason": "NEAR_OUTBOUND_DOOR"
}
ZONE-B was not hallucinated. It existed. It was open. It had capacity. It was in the enum built for this request.
The constrained decoder accepted the artifact. The application schema validator accepted it too. The WMS received the structurally valid proposal, reserved ZONE-B, and released a forklift task.
The pallet moved.
Only then did the missing question become visible.
Two valid facts did not make a valid pair
The signed SKU profile and the Zone Control record were both authoritative inside VelaFresh's fictional system:
SKU required capability: [2 C, 5 C]
ZONE-B capability: [6 C, 8 C]
For this warehouse policy, the zone's capability interval had to contain the SKU's required interval:
zone.minimum <= sku.minimum
and
zone.maximum >= sku.maximum
For ZONE-B, the first comparison was already false:
6 <= 2 -> false
8 >= 5 -> true
overall -> incompatible
That relationship was absent from the schema. An enum can constrain a field to members of a set. It cannot, by itself, join the selected member to another authoritative record and prove that the pair belongs together.
This was a failure of : the authoritative relationship that determines whether individually valid values can be used together for the current request.
The model's reason did not repair the gap. “Near outbound door” explained why the model preferred ZONE-B; it was not evidence that ZONE-B could hold this pallet. More fluent reasoning would still leave the same authority question unanswered.
Eighteen fictional minutes after placement, an independent environmental monitor raised an alarm. Operations moved the pallet into quarantine for inspection and delayed one outbound order.
The alarm detected the problem after commitment. It was not the compatibility validator, and the consequence is not presented as a claim about a real food, warehouse, or regulatory threshold.
The sequence contains no malformed output and no stale enum. Every structural check passes. The failure appears in the relationship the WMS never required before it acted.
The old mental shortcut was:
zone is in the available enum
-> proposal is valid
-> release putaway
The corrected path needed one more gate:
zone is in the available enum
-> proposal is structurally valid
-> authoritative pallet-zone relationship is compatible
-> atomically reserve or hold
Correction A: validate the proposal before commitment
Noor's default correction kept the broad open-zone enum. DockPilot could still use the receiver's note to choose among all currently open zones. But its output remained a proposal until deterministic code checked the relationship.
The Putaway Eligibility service resolved the signed SKU profile and the selected zone's capability from their pinned snapshots. Its central check was deliberately boring:
function isCompatible(
sku: {requiredMinC: number; requiredMaxC: number},
zone: {capabilityMinC: number; capabilityMaxC: number},
) {
return zone.capabilityMinC <= sku.requiredMinC
&& zone.capabilityMaxC >= sku.requiredMaxC;
}
If the relation failed, Putaway Eligibility returned INCOMPATIBLE_PROPOSAL. The pallet stayed in a controlled receiving lane, and a supervisor owned the exception.
Each immutable putaway-request.v1 allowed exactly one model attempt. Provider refusal, timeout, incomplete generation, or a structurally invalid putaway-proposal.v1 returned MODEL_PROPOSAL_UNAVAILABLE to the same typed hold. The application never retried that request. Only a new authority snapshot could create a new request and permit another attempt.
If the relation passed, the WMS still had work to do. Availability could change between generation and reservation. Inside one warehouse transaction, it rechecked the pinned SKU-profile, zone-capability, and allocation versions, reran the same containment rule, confirmed capacity, and wrote the reservation, putaway task, receipt, and task-outbox event together. Only the committed outbox event could release forklift work.
This did not turn freshness into the story's main failure. It simply kept the correction honest: a pre-commit check must still be true at the commit boundary.
The cost was visible. The validator added authority reads, latency, receipts, and a maintained dependency. A model could choose an incompatible zone even when another compatible zone was open, pushing a pallet into the supervised lane. When an authority was unavailable, automation stopped rather than guessing.
Correction B: compute the eligible set first
Noor's second design moved the same deterministic relation earlier.
Before the model call, eligibility code joined the SKU profile to every open zone. For the incident snapshot, the resulting enum would have contained only ZONE-A:
open set: ZONE-A, ZONE-B, ZONE-C
compatible set: ZONE-A
DockPilot could then use the receiver's note to rank only compatible choices. The model still contributed a preference decision when several eligible zones existed; deterministic code owned which candidates were safe to propose.
The alternative prevented this incompatible pair before generation, but it was not free. Each pallet could require a different enum. VelaFresh had to build and contract-test dynamic request schemas, accept less reuse in some caches, and operate the eligibility service as a request-path dependency. The WMS still had to revalidate at commitment because capacity and versions could change after the set was computed.
And sometimes the compatible set was empty.
That was not an invitation to widen the enum or regenerate until the model selected something. It was : an explicit outcome that declines to automate because the system cannot satisfy its contract.
NO_COMPATIBLE_ZONE kept the pallet in the supervised receiving lane. It was allowed only after deterministic code checked every open zone and found none that satisfied the same containment rule. If the set was non-empty but provider or structural generation failed, the one attempt ended as MODEL_PROPOSAL_UNAVAILABLE. A later request could use a new authority snapshot, but that was a new decision—not a hidden repair loop around the old proposal.
Concepts in this story4 concepts
Constraining a model response to an allowed shape, grammar, or schema while tokens are generated. It can guarantee representation and permitted members; it does not establish that the resulting values are true, compatible, or authorized for use.
Conformance to a declared representation contract such as required fields, types, cardinality, and enum membership. Structural validity says the artifact is well formed under that contract, not that its values form a valid business decision.
A relationship established by authoritative rules or records showing that individually valid values can be used together for the current request. It must be checked at the boundary that can still prevent the effect.
An explicit outcome that declines to produce or accept an automated answer when the system cannot satisfy its evidence, capability, risk, or deadline contract. Abstention must lead to a defined hold, fallback, or human path.
What VelaFresh measured separately
Noor replayed a clearly fictional 10,000-request fixture through the corrected path. The numbers were designed for this story; they are not measurements of a real company, provider, model, warehouse, food category, or industry rate.
| Measure | Fictional replay result |
|---|---|
| Structurally valid proposals | 10,000 / 10,000 |
| Incompatible selected zones | 68 / 10,000 |
| No compatible open zone | 11 / 10,000 |
| Commit rejected after a snapshot changed | 17 / 10,000 |
| Forklift tasks after a failed gate | 0 |
The first row did not become “10,000 valid decisions.” It remained a structural result. Semantic rejection, abstention, stale commitment, and accepted commitment stayed separate in the receipt and dashboard.
That separation answered different questions:
- Did the generated artifact conform to the request contract?
- Did authoritative records establish the pallet-zone relationship?
- Was that decision still current when the WMS committed?
- Did a failed gate release any warehouse work?
The complete corrected responsibility map looked like this:
The two designs disagree about when to narrow the model's choices. They agree about the authority boundary: the model proposes, deterministic code establishes compatibility, and the WMS alone commits.
Transfer the relationship test
Imagine a deployment assistant that emits a region from a valid region enum and a data class from a valid data-class enum. Both fields parse. Both values exist.
Before placement, ask three questions:
- What relationship must hold between this data class and this region?
- Which policy or authoritative record owns that relationship?
- Which component can still reject the proposal before deployment begins?
“Both enums are valid” is not an answer. Neither is “the model explained its choice.” The deployment needs a deterministic residency or placement check at the boundary that still controls the effect.
The same test applies to an inspector and an appointment, a flight and a connection, or a creative and a broadcast window. Name the pair, name the relationship, name its authority, and place the check before commitment.
The rule Noor kept was short:
Allowed structure narrows what a model can say. Authoritative validation decides whether the values belong together. Only then may the application act—or hold.
Evidence and fiction note
Current Google Gemini structured-output documentation explicitly distinguishes schema-compliant output from semantically correct values and tells applications to validate the result. It also documents a provider-specific supported subset, which is why this story does not claim that every schema keyword is portable.
The Hidden Cost of Structure provides bounded research evidence that constrained decoding and task behavior should be evaluated separately. It does not establish the fictional rates or model behavior above.
The FDA Food Code supports only the general background that controlled food temperatures matter. VelaFresh, DockPilot, Noor, the pallet, identifiers, temperature intervals, 18-minute alarm, incident, order delay, and replay results are all fictional. The story is an architecture lesson, not food-safety or legal guidance.