GCA Americas’ one-hour workshop teaches discriminative models through a deliberately constrained fighting game. Jev—or an open DiffusionGemma endpoint behind the same API—chooses an action every tick. Gemini runs on a slower parallel branch to read a visual spell card and, after the fight, write the story.

I inspected the README, staged exercises, game engine, decision policy, ADK workflow, rehearsal server, and Google Cloud setup. The Python sources compiled successfully. The repository has no automated test suite, and I did not provision its L4 VM, use Google credentials, or make live Jev or Gemini calls; this was an implementation inspection, not a security audit.

The exercise has a real architectural lesson

The arena separates four kinds of work:

  • Deterministic code owns hit points, legal actions, damage, spell validation, and the end condition.
  • The decision model reads a text telegraph and answers three typed questions: response Choice, exposed Noul, and danger Score.
  • Policy code applies thresholds and fallbacks to those answers.
  • Gemini handles the open-ended jobs: reading an image, composing an incantation, and telling the final story.

This is more useful than pretending one model should run the whole system. The fast branch can loop every few hundred milliseconds while the slower vision branch works independently. They meet through explicit state: when a valid spell is ready, the next decision request includes cast as an available option.

Policy stays outside the model

The workshop does not wire the top Choice answer directly to the game.

  • Below 0.40 Choice confidence, a predicted heavy attack falls back to dodge.
  • When a spell is ready and exposure is at least 0.60, a planned strike becomes cast.
  • cast is never offered before a spell exists, and code converts any impossible cast back to strike.
  • The game engine—not either model—decides whether an action succeeds and how much damage occurs.

Those thresholds are instructional constants, not validated safety guarantees. Still, the shape is sound: a typed model supplies evidence, while code owns policy and consequences.

Hosted, open, and fake backends

The same TypeSafe SDK can point at three backends:

  1. hosted Jev with a TypeSafe key;
  2. DiffusionGemma served by djev-run on a Google Cloud L4 VM and reached through an IAP tunnel;
  3. a local rehearsal server that mimics the HTTP contract with keyword heuristics.

The rehearsal server is unusually honest. Its source says the numbers mean nothing; it exists to verify plumbing. The open-model path also documents operational details often omitted from demos: GPU quota checks, a private model port, startup scripts, pause/resume commands, teardown, and the continuing disk charge after the VM is stopped.

What is and is not demonstrated

  • The repository demonstrates a complete teaching harness, API interchangeability, explicit thresholds, bounded state, and a parallel fast/slow workflow.
  • It does not publish repeated win rates, action accuracy, spell-recognition accuracy, latency distributions, or comparisons between Jev and DiffusionGemma.
  • Its quoted latency and pricing figures are source/vendor claims; I did not reproduce them.
  • The fake backend proves compatibility, not model quality.
  • A typed decision is not necessarily the correct counter-move.
  • The open endpoint is API-compatible, not evidence of behavioral parity with Jev.

Takeaway

The workshop’s best contribution is a runnable mental model: use ordinary software for rules, a small decision model for frequent bounded judgments, and a language model only where perception or generation is actually required.

It is an implementation and curriculum artifact, not an evaluation. The next useful addition would be a fixed-seed tournament that reports action accuracy, fallback frequency, win rate, latency, cost, and disagreement between hosted Jev and the open backend.