Speculative Fan-Out

Think of the page where you build a car. Pick the model, and that decides which engines appear. Pick the engine, and that decides which wheels appear. Industrial suppliers sell the same way, and it is how a large share of B2B manufacturing revenue is actually quoted. A valve is not a thing on a shelf. It is eight choices that together make one part number.

The catch is that the form fights you. Fields stay locked until the thing they depend on is set. Options that were there a second ago vanish when you change an earlier choice. Some combinations are only rejected at the very end, when you press submit.

The catalogue in this experiment is invented, but its shape copies real ones. Eight fields:

Which is why you cannot just ask once

Almost nothing on that grid is legal, and the form only ever shows you the small slice that still is. Here is a real path through it. The grey squares are what the catalogue holds, the blue ones are what the form actually offers you at that moment, after everything you already picked.

The normal way to drive a configurator is a loop. Ask, set the field, see what changed, ask again. Fan-out looks impossible because the questions are not independent: you cannot ask "which seal" before you know the body.

Unless you ask about hypotheticals. Every question then stands alone, so they all fit in one call, and code walks the tree afterwards using answers it already holds. Branches nobody takes are wasted, but a wasted branch is a few dozen tokens.

The catalogue above, plus the five things that make a real configurator annoying: fields locked until their dependency is set, options that vanish when an earlier choice changes, one deliberately mislabelled option, a submit that refuses the first press, and one rule that only appears at submit.

Ground truth is built backwards: walk the graph to a valid configuration, then write the customer request from it, so the answer is unambiguous by construction.

300 requests in four bands: 90 easy, 90 medium, 90 hard, and 30 impossible ones the catalogue forbids, where the only right answer is to refuse. The headline metric is consistent: every field the customer explicitly named is satisfied. An agent that walks the graph legally but picks at random scores 97.4% valid and 0.7% consistent, which is why validity proves nothing.

The usual expectation is that batching costs accuracy. It does not here, because each question is still answered against the correctly narrowed option list, just under a hypothesis instead of a commitment.

What did not work: asking the model whether the request was self-consistent. 10% recall at 15% false positives, no better than guessing, because the constraints live in the catalogue and not in the request text.

What worked: ask what the customer explicitly named, then compare it in code to what the walk delivered. Those eight questions depend on nothing, so they ride in the same call at no extra round trip.

Verification also refuses about a third of solvable requests, which sounds alarming until you ask what it refused.

Jev gives up 6 correct answers to withdraw 83 wrong part numbers. Gemini gives up 20 to withdraw 72. In a quoting workflow that trade is not close: a wrong part number reaches a customer, a refusal reaches a human.

A4 branches over the series too, asking 296 questions instead of 29. On Jev it works. On Gemini it returned 400 INVALID_ARGUMENT on all 300 requests, in about a tenth of a second each, before any generation happens.

This is not the context window. The wide call is roughly 55,000 input tokens against a million-token window. It is the structured-output schema. To guarantee output that matches your schema, Gemini compiles it into a grammar and constrains decoding to it. The grammar is built before generation starts, and every option in every question adds to it.

Jev has a ceiling too, a different one. Its envelope is 64k tokens for state plus questions. 419 fully labelled questions is about 147,000 characters and returns max_tokens_exceeded. In a separate email test it answered 801 short questions in one call.

And fanning out on Jev is close to free. Same email, one question against 800 in the same call: 0.65s against 1.33s, confidence moving about 0.01, and the main answer unchanged on 39 of 40 emails. The one that flipped had said 0.40 to begin with.

Identical accuracy, ten times the questions, nine times the cost. Branch over each step's real dependencies, not over the whole path. The chain is eight steps long but no step depends on all of its predecessors: seal depends only on body, port and actuation only on series. That is what holds the count at 29 instead of thousands, and it is the practical guidance from this work.

• One synthetic catalogue. The generator is published. Nothing here is a claim about any real configurator.
• A hard precondition. Speculation assumes the option graph can be read once and cached. A configurator that computes options server side on every selection defeats it completely.
• The verify mechanism was designed after seeing the failure it fixes, so its 90% is in-sample. The interval, 73% to 98%, is what should be quoted.
• Absolute accuracy is low across the board. On the hard band only three of eight fields are stated. The comparison between arms is the result, not the level.
• Gemini is the more accurate model here, by about seven points. Jev's case is cost, refusal quality and the absence of a schema ceiling.
• Arms are only comparable within a single run. No number here is quoted across runs.
• The error message. Google's docs attribute this failure class to schema complexity, with the wording "too many states for serving". Our logs contain only the bare "Request contains an invalid argument", so that phrase is not quoted as observed.

It held on two independent models, at a third of the calls and half the wall clock, and the one thing it breaks is fixed by eight more questions in the same call. The model-specific part is narrower: Jev withdraws fourteen wrong answers for every correct one it gives up, against Gemini's under four, costs eleven times less per correct configuration, and has no schema ceiling to run into.

Rerun in full on 25 September 2026, all eight arms in one process, and rescored by a second independent implementation that agrees with the original scorer to the decimal.