How can a game turn a typed spell description into a working spell without an LLM writing any text?

Ask seven small questions, not one big one

"What spell is this?" has no fixed answer set, so a model would have to write one out, and the game would have to parse whatever came back. Seven atomic questions each have a closed answer set the designer wrote: eight elements, six shapes, four targeting modes, six control effects, a five-level power scale, a four-level duration scale, and one yes or no legality check. They all go out in a single request and are evaluated in parallel, so adding a question barely moves the response time.

The model never sees the question ids (element, shape). Those keys exist for the code that reads the answers.

answers = jev(state = description, questions)        // one request, seven questions

if answers.forbidden.noul >= 0.6:
    refuse("The runes go dark. That is not permitted here.")

cost = BASE[shape] + round(power.score * 8) + round(duration.score * 5)
if cost > mana:
    fail(cost, mana)                                   // show the numbers

element = answers.element.confidence >= 0.5
        ? answers.element.choice
        : sample(answers.element.probabilities)        // unstable: re-rolled on every cast

spell = { element, shape, targeting, control,
          power_level:  round(power.score),
          duration_sec: DURATION_SEC[round(duration.score)],
          mana_cost:    cost }

cast(TABLES, spell)                                     // each field picks a row the designer built

Probabilities are game data

The answer is more than its top choice. "Freezing fire" comes back split between fire and ice, and the low confidence is the signal. Instead of picking one and pretending, the game marks the spell unstable and samples the element from the distribution on every cast. The player sees the roll, so an ambiguous description becomes a mechanic instead of a bug. Power works the same way: score is the probability-weighted mean of the levels, so "heavy" and "catastrophic" in one sentence land between levels, and the mana cost follows.

The designer still owns every output

Jev only ever picks from criteria the designer wrote, and the game only ever builds from tables the designer filled: a sprite, a speed, a size, a particle count, a damage number, a knockback vector per entry. The model cannot invent a ninth element or a damage type the engine has no code for. The worst it can do is pick a valid entry the player did not expect, and the probabilities show exactly how likely that was.

Why this could not exist before

Classic text parsers needed exact verbs ("cast fireball at goblin") and broke on anything a designer had not anticipated. Chat-style LLMs understand loose descriptions, but they are too slow for a crafting loop the player repeats every few seconds, they cost per output token, and they can describe effects the game has no code for, which someone then has to catch and refuse. A typed System One call sits between the two: it reads free text like a language model and answers like a lookup table, in tens to hundreds of milliseconds, priced on input alone.

About this demo: every answer here comes from a local mock. Presets use hand-written answers so they always behave the same. Free text uses a keyword heuristic: keyword hits become logits, softmax at temperature 0.7 with a small seeded jitter. Confidence is shown as 1 minus normalized entropy, an approximation of TypeSafe's unpublished formula. Latency is drawn uniformly from 70 to 500 ms to match TypeSafe's reported end-to-end range, and token counts are the JSON length divided by 4. Jev is in early access; nothing on this page calls it.