#4793 TypeSafe AI's JEV

A new kind of AI model from a ChatGPT inventor is thrilling developers

https://techcrunch.com/2026/09/18/a-new-kind-of-ai-model-from-a-chatgpt-inventor-is-thrilling-developers/

#4793 Tell me about TypeSafe AI's JEV.

Jev (released mid-September 2026 by TypeSafe AI) is a specialized AI model designed to evaluate program state and return strictly typed, probabilistic decisions rather than generating open-ended natural language text.

Founded by former OpenAI researcher Diogo Almeida (along with Erik Gafni and Sasha Sheng), TypeSafe AI built Jev around the concept of a "System One" model—named after Daniel Kahneman’s fast, reflexive cognitive archetype. The model is named after economist William Stanley Jevons, referencing the Jevons paradox: making machine intelligence orders of magnitude cheaper and faster will drastically increase the surface area where it gets embedded.

Core Architecture and Mechanics

Rather than generating sequential autoregressive tokens that an application must parse with Pydantic or instructor schemas, Jev acts as a deterministic, schema-enforced decision engine:

No Free-Text Output: Jev does not generate paragraphs, code, or conversational replies. Because it cannot output unstructured tokens, schema violations and hallucinated fields are structurally impossible.
Single Parallel Pass: When sent a payload of input state along with multiple questions, Jev evaluates all queries simultaneously in a single forward pass, typically returning in 70 to 500 ms.
RLCD (Reinforcement Learning for Calibrated Decisions): Unlike conversational models tuned with RLHF (optimizing for human conversational preference), Jev is trained specifically on synthetic decision-making tasks to calibrate true statistical confidence. If Jev outputs an 85% probability, it is optimized so that roughly 85% of such evaluations are empirically correct.

The Three Decision Primitives

All questions sent to Jev must conform to one of three primitives:

Primitive	Function	Return Payload	Typical Use Case
Choice	Picks one discrete category out of a developer-supplied set (up to 255 options).	Winning option, probability distribution across all choices, and overall confidence.	Semantic routing, intent classification, next-action selection.
Score	Maps state against an ordered rubric of 2 to 10 descriptive levels.	Continuous score value, distribution across tiers, confidence.	Priority ranking, risk assessment, prompt injection severity scoring.
Noul	Evaluates a binary proposition (yes/no).	A single float between $0.0$ and $1.0$ representing $P(\text{true})$ .	Guardrail checks, threshold triggers, exit conditions.

Where It Fits in the Software Stack

Jev is engineered to function as an intelligent programmatic branching tool rather than an autonomous general-purpose agent.

Fast-Path Agent Routing: In agent architectures, a heavy frontier LLM often spends seconds parsing an observation just to decide which tool to trigger. Developers use Jev as an ultrafast router: Jev evaluates the state at ~300 ms to select the tool branch; heavy models are invoked only if narrative writing or deep analytical generation is explicitly required.
Map-Reduce and Batch Triage: At a base pricing of roughly $0.042 per million input tokens with no output token generation costs, running millions of records through semantic filters becomes computationally negligible.
Control-Loop Advisory: In low-latency environments (such as simulated robotics, UI automation, or real-time gaming), Jev sits between deterministically parsed sensor/state data and mechanical actuators to provide tactical judgment at 2–10 Hz.

Key Trade-offs and Constraints

Strictly Advisory: Jev does not carry persistent context, long-term memory, or an internal scratchpad. Context is capped at 64k tokens, and extraneous data degrades accuracy.
No Mathematical or Algorithmic Execution: Jev struggles with explicit multi-step arithmetic, precise date arithmetic, or counting. Deterministic operations (e.g., date diffs, parsing tabular schemas, calculations) must remain in application code.
Schema Reliability vs. Correctness: While Jev guarantees the return format cannot violate your typing, it can still pick the wrong option. Safety hinges on application logic explicitly checking the returned calibrated confidence and handling ambiguous distributions via fallback paths.

Given my background and interests, how can I apply JEV in innovative ways?

Because Jev acts as an ultra-low-latency (70–500 ms), non-autoregressive "System One" decision engine rather than a text generator, applying it innovatively means identifying places where generative LLMs are too slow, brittle, or expensive, but deterministic heuristic code is too rigid.

Here are five architecture-level ways to apply Jev across complex engineering, graph, and agentic workflows:

1. The "Pre-Router" for Agentic Orchestrators and Workflow Governors

In complex multi-agent state machines (e.g., LangGraph or custom execution loops), developers frequently spin up a heavy LLM just to decide which agent node to invoke or whether an artifact passed review.

The Antipattern: Prompting an LLM with structured output/Pydantic schemas to output {"next_node": "critic", "confidence": 0.82}, which costs 2–5 seconds and requires retry blocks if the JSON drifts.
The Jev Architecture: Use Jev’s Choice and Noul primitives directly inside the conditional edge router.
- In a single parallel payload, pass the current artifact state and evaluate:
  1. Choice(options=["DomainSynthesizer", "VerificationCritic", "HumanIntervention", "TerminalComplete"])
  2. Noul(statement="The generated requirements contain contradictory or untraceable statements.")
  3. Score(scale=["Needs Total Rework", "Minor Clarification Needed", "Nominal / Approved"])
- Because Jev evaluates in ~200 ms with calibrated probabilities, the governor branches with deterministic schema certainty. Heavy frontier models are called only when analytical drafting or natural language synthesis is genuinely required.

2. High-Throughput GraphRAG Entity & Relation Disambiguation

Constructing knowledge graphs from dense technical corpora (PDF parsing pipelines, ASTs, or document trees) involves thousands of micro-decisions: entity linking, coreference resolution, and taxonomy classification.

Batch Cypher Ingestion Triage: Instead of relying solely on vector cosine similarity (which often collapses across dense engineering terminology) or full LLM extraction runs, use Jev in the ingestion pipeline.

Ontology Alignment via Choice: When an extraction pipeline identifies a component, Jev can evaluate candidate parent nodes or relationship types against a strict schema:

{
  "primitive": "Choice",
  "options": ["COMPOSES", "INTERFACES_WITH", "CONSTRAINS", "VERIFIES"],
  "state": "Component: Flight Software Task Scheduler; Target: Watchdog Timer Service."
}

Calibrated Co-reference: At $0.042 per million input tokens, you can run hundreds of thousands of candidate graph edges per minute. When confidence falls below 0.70, route the ambiguous edge to a human queue or a deeper reasoning model.

3. Verification Gatekeeper for Compliance and Hazard Matrices

When reviewing engineering artifacts, software hazard reports, or system decompositions against rigid procedural standards:

Multi-Beat Compliance Auditing: Pass parsed requirement clauses and standard rules to Jev to execute concurrent primitive checks:
- Noul: Does this requirement statement violate standard phrasing (e.g., uses ambiguous words like "should", "etc.", or "flexible" instead of verifiable criteria)?
- Score: Calibrate implementation risk on a 5-tier descriptive scale (e.g., Catastrophic, Critical, Moderate, Negligible).
- Choice: Map the clause to its classification tier (e.g., Class A, B, C, or Non-Safety-Critical).
Automated Failure Mode Pruning: In Cause-Effect Chain Analysis or TRIZ-based trade studies, Jev can evaluate candidate physical contradictions or failure paths to prune non-viable branches before simulating the system state.

4. Hybrid SysML / Digital Twin State Transition Advisories

Digital twins and SysML v2 behavioral diagrams model state machine transitions (e.g., telemetry mode transitions from INIT $\to$ ARMED $\to$ BURN $\to$ ABORT).

Tactical Control Advisories (2–5 Hz): While geometric or physical control systems operate at 50–500 Hz deterministically, Jev can sit as an intermediate advisory layer.
Telemetry Anomaly Triage: Given parsed, object-centric JSON of telemetry parameters (temperatures, bus voltages, pressure differentials), Jev can run parallel evaluations:
- Choice: Recommended mode adjustment (MAINTAIN, LOAD_SHED, SAFE_MODE).
- Noul: Sensor reading indicates physical component drift rather than transient bus noise.
- Because Jev evaluates structured JSON directly without screenshot/OCR latency, it provides semantic failure classification inside interactive visualizers or simulation harnesses.

5. Generative Algorithmic Control (Audio / MIDI / Synthesis Engines)

In parameter-driven interactive systems (such as algorithmic sequencers, Web Audio API engines, or generative modulation matrices):

Contextual Macro Switching: Autoregressive LLMs cannot react in real time to musical performance loops. Jev’s sub-100 ms latency makes it usable in event loops (e.g., 2–4 beats per bar).
Dynamic Mod Matrix Routing:
- Input State: Current MIDI clock, active pitch density, velocity variance, filter cutoff position.
- Jev Queries:
  - Choice: Select next structural section transition (Breakdown, Drop, Rhythmic Ostinato, Polyphonic Cadence).
  - Score: Rhythmic tension index (0 to 8).
  - Choice: Select LFO routing target (VCF Resonance, Pulse Width, Sub-Oscillator Level).
The system treats musical tension and stylistic grammar as a real-time probabilistic classification problem without needing hardcoded heuristics or sluggish API roundtrips.

Strategic Architectural Heuristic

System Need	Traditional LLM (GPT-4 / Claude)	Jev (System One)	Deterministic Code
Output Type	Prose, full code, explanations	Typed primitives (`Choice`, `Score`, `Noul`)	Hard types (ints, structs)
Latency	2,000 – 10,000 ms	70 – 500 ms	< 1 ms
Ideal Position	Deep analysis, creative drafting, multi-turn synthesis	State machine routing, verification gates, semantic filtering	Control loops, numerical math, safety-critical interlocking

The winning pattern is pairing: use deterministic parsers to extract structured state $\to$ feed state to Jev for fast, calibrated branching $\to$ trigger specialized LLMs only when natural language synthesis or deep symbolic reasoning is truly required.

Describe how it could be applied to a 3-entity American-rules football computer game, with one entity as offensive coach, one as defensive coach and one as referee

In a 3-entity American football simulation, traditional generative LLMs are far too slow and nondeterministic to run play-by-play decision loops, while standard rigid rule engines (e.g., hardcoded decision trees) produce predictable, lifeless play-calling.

Jev fits naturally as the fast-twitch semantic layer sitting on top of a deterministic physics/mechanics engine. Running at 100–300 ms per pass, Jev handles the contextual instincts, probabilistic tendency shifts, and subjective game-day calls across all three roles.

       ┌────────────────────────────────────────────────────────┐
       │             Deterministic Game State Engine            │
       │  (Score, Down/Distance, Clock, Field Pos, Personnel)   │
       └───────┬───────────────────┬───────────────────┬────────┘
               │ (Pre-Snap)        │ (Pre-Snap)        │ (Post-Whistle)
               ▼                   ▼                   ▼
     ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
     │ Offensive Coach  │ │ Defensive Coach  │ │  Lead Referee    │
     │  (Jev Primitive) │ │  (Jev Primitive) │ │  (Jev Primitive) │
     └─────────┬────────┘ └────────┬─────────┘ └────────┬─────────┘
               │ Concept & Tempo   │ Front & Coverage   │ Penalty / Challenge
               └─────────► Play Resolution Engine ◄─────┘

1. Entity: Offensive Play-Caller (Offensive Coordinator)

The Offensive Coach evaluates the macro game state, opponent tendencies, and recent success rates to select play concepts, audibles, and pacing.

Play Concept Selection (Choice):
- Input Payload: Current score differential, time remaining, down and distance (e.g., 3rd & 7), field position, weather conditions, and opponent’s previous 3 defensive coverage shells.
- Evaluation:
  { "primitive": "Choice", "options": [ "Pass_QuickGame_Slants", "Pass_Intermediate_Levels", "Pass_DeepShot_PostWheel", "Run_InsideZone", "Run_PinAndPull", "Screen_RB_Tunnel" ] }
- Role: Because Jev returns the winning option plus the full calibrated distribution across all choices, your game engine can use Jev’s probability distribution for dynamic roll-offs or play-sheet weighting.
Line-of-Scrimmage Audible (Noul):
- Input Payload: Pre-snap defensive alignment (e.g., "Defensive front shows 8 men in the box with single-high safety; offensive call is Inside Zone").
- Evaluation: Noul(statement="Current pre-snap box count completely neutralizes the called run design; trigger check-with-me audible.")
- Role: A binary flag returning in ~120 ms allows a smooth pre-snap animation beat where the QB audibles at the line without stalling game rendering.
Game Pacing & Aggressiveness (Score):
- Evaluation: Score(scale=["Drain Clock / Conservative", "Standard Huddle", "Up-Tempo / Hurry-Up", "Panicked 2-Minute Drill"])
- Role: Adjusts clock run-off, substitution frequency, and sideline urgency.

2. Entity: Defensive Play-Caller (Defensive Coordinator)

The Defensive Coach tries to anticipate offensive intent, balance risk vs. reward (e.g., blitzing vs. umbrella coverage), and manage sideline personnel packages.

Shell & Coverage Call (Choice):

Input Payload: Offensive personnel grouping on field (e.g., 11 personnel vs. 22 personnel), offensive run/pass ratio on 2nd-and-medium, down/distance, and trailing margin.

Evaluation:

{
  "primitive": "Choice",
  "options": [
    "Cover_0_AllOutBlitz",
    "Cover_1_Robber",
    "Cover_2_HardFlats",
    "Cover_3_Cloud",
    "Cover_4_Quarters",
    "Cover_6_QuarterQuarterHalf"
  ]
}

Front-Seven Pressure Dial (Score):
- Input Payload: Quarterback mobility rating, pass protection sack rate over past 2 drives, time left in half.
- Evaluation: Score(scale=["Passive 3-Man Rush", "Base 4-Man Rush", "5-Man Sim Pressure", "Zone Blitz / Overload", "Zero Rush / Max House"])
- Role: Directly dictates defensive lineman stunt assignments and linebacker rush angles to the physics engine.
Fourth-Down Defensive Strategy (Noul):
- Evaluation: Noul(statement="Offense alignment indicates fake punt or hard-count draw rather than conventional punt execution.")
- Role: Dictates whether the punt-return unit stays in "safe" defense or sells out for the return block.

3. Entity: The Referee (Officiating & Review Official)

In video games, rule enforcement is usually either 100% deterministic (frustratingly robotic) or flat random (annoying). Jev enables a realistic officiating entity with human-like judgment thresholds, variable crew tendencies, and objective video review adjudication.

Subjective Penalty Assessment (Noul & Score):
- Real-world penalties like Holding, Pass Interference, and Roughing the Passer aren't binary physics events; they are judgment calls based on physical contact severity and game context.
- Input Payload: Contact duration between WR and DB, separation distance, ball arrival timestamp, hand placement vector, and crew strictness index.
- Evaluation:
  - Noul(statement="Defensive contact materially restricted the receiver's path while the ball was in the air.")
  - Score(scale=["Incidental / Legal Hand-Fighting", "Marginal Contact / Play On", "Clear Pass Interference / Throw Flag"])
- Role: Flags are thrown based on calibrated statistical confidence, mimicking real-world officiating variance without arbitrary random number generation.
Coach's Challenge / Replay Review (Choice):
- When a coach challenges a ruling (e.g., sideline toe-tap or fumble recovery before down-by-contact):
- Input Payload: Text/vector summary of collision events: "Runner knee touched grass at t=3.41s; ball control was dislodged by defender helmet at t=3.39s; camera frame clarity rating: High."
- Evaluation:
  { "primitive": "Choice", "options": [ "Ruling_Stands_IndisputableEvidenceMissing", "Ruling_Confirmed_CallOnFieldCorrect", "Ruling_Overturned_ReversedByClearVideo" ] }
- Role: Decouples the simulation physics from the official call, creating authentic booth reviews where marginal plays might "stand" if the virtual visual clarity is ambiguous.

The Execution Loop (Per Play)

Phase	Engine Action	Jev Payload & Role	Return Time
1. Play Calling	Deterministic down/distance update	Offense & Defense: Concurrent `Choice` calls for formation, play design, and defensive shell.	~150 ms
2. Pre-Snap	Players line up; motion starts	Offense: `Noul` check on defensive tell $\to$ triggers audible or cadence shift if $P(\text{true}) > 0.80$ .	~80 ms
3. Execution	Physics / animation simulation	Deterministic mechanics run locally.	0 ms
4. Whistle / Flags	Tackle made; physics generates telemetry	Referee: Evaluates contact parameters via `Score` and `Noul` for fouls or out-of-bounds rulings.	~120 ms
5. Post-Play / Sideline	Clock runs; timeouts assessed	Both Coaches: `Noul` evaluation on whether to call a timeout, take a penalty, or throw a red challenge flag.	~100 ms

Why This Outperforms Traditional Methods

vs. Autoregressive LLMs (GPT/Claude): Total pipeline latency across all three entities is sub-300 ms, fitting seamlessly into real-time animation state transitions without freeze-frames or loading spinners.
vs. Rigid Decision Trees: The coaches and referee don't run on brittle if/else ladders. If the offense runs an unorthodox 4-TE set on 3rd & 25, Jev’s semantic evaluation gracefully maps the novel situation to sensible strategic primitives based on its learned training distribution.

How is "success" of an offensive play vs defensive config determined, while also updating game state: Time, score, field position, etc.?

To evaluate whether an offensive play succeeded against a defensive configuration while keeping game state updates rock-solid, games decouple semantic evaluation (did the concept beat the scheme?) from state transition math (yardage, clock run-off, points).

The modern standard in football analytics and game design uses an EPA / Success-Rate framework layered over a deterministic state machine.

1. Determining Play "Success"

In professional analytics (and high-fidelity simulation engines), raw yardage is deceptive—gaining 3 yards on 3rd & 2 is a massive success, while gaining 3 yards on 3rd & 10 is a failure.

Success is measured along two complementary axes:

Quantitative Criterion: Expected Points Added (EPA) & Down-Success

A play is marked Successful (True) if it meets benchmark thresholds of the yardage required to keep the drive alive:

1st Down: Gaining $\ge 45\%$ of the needed yards (e.g., 4.5+ yards on 1st & 10).
2nd Down: Gaining $\ge 60\%$ of the needed yards (e.g., 4+ yards on 2nd & 6).
3rd & 4th Down: Gaining $100\%$ of the needed yards (a conversion or score).

\text{EPA} = \text{EP}_{\text{post-play}} - \text{EP}_{\text{pre-play}}

If $\text{EPA} > 0$ , the offense won the down; if $\text{EPA} \le 0$ , the defense won.

Qualitative / Tactical Matchup Resolution

Before calculating yards, the engine scores how well the offensive concept counteracts the defensive scheme. This generates a success distribution (e.g., probability of explosive play, stuff, or sack).

Offensive Concept	Defensive Configuration	Structural Matchup	Expected Yardage Profile
Inside Zone Run	Cover 2 (Light Box, 6 men)	Offense Heavy Advantage	High median (5–7 yds), high floor
Inside Zone Run	Cover 0 / 1 (Loaded Box, 8 men)	Defense Advantage	High stuff/TFL rate (-2 to 1 yds)
Four Verticals	Cover 3 (Single-High Safety)	Offense Advantage (Seams)	High variance (0 yds or 25+ yds)
Quick Slants	Cover 2 Invert / Press Man	Contested / Leverage-based	Decided by individual WR/CB ratings

If you use a decision engine like Jev here:

Feed the parsed tactical match (Play Concept vs. Coverage/Front) to Score(scale=["Catastrophic Loss/Turnover", "Stuffed/Negative", "Neutral/Tackle at Scrimmage", "Efficient Gain", "Explosive Play"]).
Jev returns the calibrated category probability distribution. The game engine samples that distribution combined with player physical attributes (e.g., tackle-break or pass-rush delta) to yield the exact discrete yardage gain.

2. Updating the Game State: The Deterministic Transition Engine

Once the resolution phase outputs a discrete outcome tuple—for example:

\text{Outcome} = \{\Delta\text{yards}: +7, \text{play\_type}: \text{"run"}, \text{tackle\_in\_bounds}: \text{True}, \text{penalty}: \text{None}, \text{turnover}: \text{False}\}

The state machine runs a strict, sequential pipeline to update the scoreboard, down/distance, clock, and field coordinates.

 [Play Outcome]
       │
       ▼
 1. Check Turnovers & Touchbacks  ──► (Flip possession & yardline if triggered)
       │
       ▼
 2. Compute New Field Position    ──► (Yardline = Yardline + Δyards)
       │
       ▼
 3. Check Scoring Boundary        ──► (Yardline ≥ 100 ➔ Touchdown; Yardline ≤ 0 ➔ Safety)
       │
       ▼
 4. Evaluate Line to Gain         ──► (Gain ≥ To_Go ➔ 1st & 10; Else Down += 1)
       │
       ▼
 5. Advance Clock & Trigger Rules ──► (Run-off 4–7s live + 25–40s dead clock if in-bounds)

3. Step-by-Step State Transition Rules

A. Field Position & Boundaries

The field is tracked as an integer coordinate $X \in [0, 100]$ (0 = own goal line, 100 = opponent goal line).

$\text{New\_Yardline} = \text{Current\_Yardline} + \Delta\text{yards}$
Touchdown: If $\text{New\_Yardline} \ge 100$ :
- Offense score $+6$ .
- State shifts to POINT_AFTER_TRY.
Safety: If $\text{New\_Yardline} \le 0$ :
- Defense score $+2$ .
- State shifts to SAFETY_KICKOFF from the 20-yard line.

B. Down, Distance, and Possession

First Down Achieved: If $\Delta\text{yards} \ge \text{Yards\_To\_Go}$ :
- $\text{Down} = 1$
- $\text{Yards\_To\_Go} = \min(10, 100 - \text{New\_Yardline})$ (triggers 1st & Goal if inside the 10).
Subsequent Down: If $\Delta\text{yards} < \text{Yards\_To\_Go}$ :
- If $\text{Down} \in \{1, 2, 3\}$ :
  - $\text{Down} = \text{Down} + 1$
  - $\text{Yards\_To\_Go} = \text{Yards\_To\_Go} - \Delta\text{yards}$
- If $\text{Down} = 4$ :
  - Turnover on Downs: Possession flips to opponent.
  - $\text{Opponent\_Yardline} = 100 - \text{New\_Yardline}$
  - $\text{Down} = 1, \text{Yards\_To\_Go} = \min(10, 100 - \text{Opponent\_Yardline})$

C. Game Clock & Play Clock

Clock management depends on play termination:

Live-Play Elapsed Time:
- Pass play: $3 \text{ to } 7 \text{ seconds}$ based on depth of target.
- Run play: $4 \text{ to } 9 \text{ seconds}$ based on run path and tackle location.
Dead-Clock Status:
- Clock Continues Running (Running Clock): Tackle in-bounds, completed pass tackled in-bounds, or declined dead-ball foul.
  - In simulated time, the play clock resets to 40 seconds. Unless a hurry-up tempo is active, $25 \text{ to } 35 \text{ seconds}$ drain from the game clock before the next snap.
- Clock Stops:
  - Incomplete pass $\to$ game clock stops immediately; play clock resets to 40s.
  - Runner steps out of bounds --> clock stops until referee spots the ball (or until snap under 2:00 of 2nd quarter / 5:00 of 4th quarter).
  - First down conversion --> clock stops momentarily for chains in college football; runs continuously in NFL rules except under 2:00.
  - Penalty, injury, or challenge --> administrative stoppage (play clock resets to 25s).
  - Score or change of possession --> clock stops until next live snap/kickoff.

4. Reference Implementation (Python State Machine)

from dataclasses import dataclass
from typing import Optional

@dataclass
class GameState:
    offense_team: str
    defense_team: str
    score: dict[str, int]
    yardline: int           # 1 to 99 (from offense perspective)
    down: int               # 1 to 4
    to_go: int              # Yards needed for 1st down
    game_clock_sec: int     # e.g., 900 for 15-min quarter
    quarter: int
    clock_running: bool

@dataclass
class PlayResult:
    yards_gained: int
    play_type: str          # "run", "pass", "sack", "incomplete"
    ended_in_bounds: bool
    turnover: bool = False
    turnover_type: Optional[str] = None  # "fumble", "interception"

def resolve_state_transition(state: GameState, result: PlayResult) -> GameState:
    # 1. Clock run-off for the live play itself
    live_play_seconds = 5 if result.play_type == "run" else 4
    state.game_clock_sec = max(0, state.game_clock_sec - live_play_seconds)

    # 2. Handle Turnovers
    if result.turnover:
        return handle_turnover(state, result)

    # 3. Incomplete Pass Check
    if result.play_type == "incomplete":
        state.clock_running = False
        return advance_down(state, yards_gained=0)

    # 4. Update Field Position & Scores
    new_yardline = state.yardline + result.yards_gained

    if new_yardline >= 100:  # Touchdown
        state.score[state.offense_team] += 6
        state.clock_running = False
        # Hand off to PAT / Kickoff subroutine
        return state

    if new_yardline <= 0:    # Safety
        state.score[state.defense_team] += 2
        state.clock_running = False
        # Hand off to Free Kick subroutine
        return state

    state.yardline = new_yardline

    # 5. Down and Distance Progress
    if result.yards_gained >= state.to_go:
        # 1st Down awarded
        state.down = 1
        state.to_go = min(10, 100 - state.yardline)
    else:
        state = advance_down(state, result.yards_gained)

    # 6. Dead-ball Clock Flag
    state.clock_running = result.ended_in_bounds
    return state

def advance_down(state: GameState, yards_gained: int) -> GameState:
    if state.down < 4:
        state.down += 1
        state.to_go -= yards_gained
    else:
        # Turnover on downs
        state.offense_team, state.defense_team = state.defense_team, state.offense_team
        state.yardline = 100 - state.yardline
        state.down = 1
        state.to_go = min(10, 100 - state.yardline)
        state.clock_running = False
    return state

By separating the strategic outcome selection (using EPA tables or Jev decision distributions) from the deterministic transition engine, the simulation guarantees zero arithmetic/rule errors while keeping the play-calling unpredictable and authentic.

From <https://gemini.google.com/app/187bb15a66824033> Google Gemini (3.8 Flash)

Search This Blog

Learning from ChatGPT