# Elevator Sense We're very good at optimizing numbers. What we can't do is optimize for meaning, because meaning never makes it into the numbers. Elevator Sense tests whether Jev can supply that missing input. Live demo: https://jev-elevator-dispatch.vercel.app Code: https://github.com/tanishkgovil/jev-elevator-dispatch ## The problem The math of dispatch is mature: distances, travel times, queues. But the right decision often depends on meaning the optimizer never sees. A hospital elevator knows where you're going, not who's waiting. A trauma patient on a bed, a nurse on break, and a family heading to the cafeteria are all just "a hall call." LLMs can read that meaning, but at seconds per call they're too slow to sit inside a control loop. ## What I built A simulated 10-floor hospital with two identical elevator banks side by side: same building, same stream of requests, same dispatch algorithm. The optimizer is left exactly as-is. The only difference is that on the right, Jev reads each free-text request first (e.g. "Bed transport ER to ICU, pt intubated, need to go NOW"). ## How Jev is used One Jev call per request, three typed questions, ~100–200 ms: - Priority (Choice): stat / urgent / routine / visitor - Load (Choice): bed / wheelchair / cart / walking - Needs its own car?: probability 0–1 Code translates those answers into numbers the optimizer already understands: a bed takes a whole car, an emergency counts 10× when weighing delays, and a patient who needs their own car only goes to empty cars. The same ETA-based dispatcher then does the math. Jev supplies the meaning; the optimizer still does the optimizing. That split is deliberate: TypeSafe's docs note Jev is weak at arithmetic, and the numeric part is already solved. Live incidents typed into the demo ("Car C door keeps sticking", "Trauma incoming to the ED in 5 minutes") go through a second Jev call (event type, floor, car). The physical effect happens in both buildings, but only the Jev side can respond. ## Results The optimizer didn't get smarter; it got better inputs. Mean over 16 randomized traffic scenarios that were NOT used for tuning: - Emergency patients wait: 46s → 13s (−71%) - Patient beds wait: 80s → 24s (−70%) - Everyone, on average: 31s → 19s (−38%) - Trips where a bed didn't fit: 120 → 3 Jev came out ahead in 14 of 16 scenarios. ### Limitations - It's a simulation; the physics and traffic mix are assumptions. - I wrote the test requests myself, so Jev's accuracy on real hospital language is untested. - The baseline is a textbook dispatcher, not a commercial controller. The claim is "the same optimizer with vs. without semantic inputs," not "better than industry systems." ## What's next Test on requests written by real clinical staff; use Jev's confidence scores to handle uncertain requests conservatively; compare against published dispatch algorithms. The broader pattern is to take optimization we've already solved numerically and give it the semantics it's missing. It applies anywhere meaning changes the right answer: hospital porters, ambulances, warehouse robots, job queues.
Built at JEVATHON (w/ The AI Collective)
Elevator Sense
# Elevator Sense We're very good at optimizing numbers. What we can't do is optimize for meaning, because meaning never makes it into the numbers. Elevator Sense tests whether Jev can supply that missing input. Live demo: https://jev-elevator-dispatch.vercel.app Code: https://github.com/tanishkgovil/jev-elevator-dispatch ## The problem The math of dispatch is mature: distances, travel times, queues. But the right decision often depends on meaning the optimizer never sees. A hospital elevator knows where you're going, not who's waiting. A trauma patient on a bed, a nurse on break, and a family heading to the cafeteria are all just "a hall call." LLMs can read that meaning, but at seconds per call they're too slow to sit inside a control loop. ## What I built A simulated 10-floor hospital with two identical elevator banks side by side: same building, same stream of requests, same dispatch algorithm. The optimizer is left exactly as-is. The only difference is that on the right, Jev reads each free-text request first (e.g. "Bed transport ER to ICU, pt intubated, need to go NOW"). ## How Jev is used One Jev call per request, three typed questions, ~100–200 ms: - Priority (Choice): stat / urgent / routine / visitor - Load (Choice): bed / wheelchair / cart / walking - Needs its own car?: probability 0–1 Code translates those answers into numbers the optimizer already understands: a bed takes a whole car, an emergency counts 10× when weighing delays, and a patient who needs their own car only goes to empty cars. The same ETA-based dispatcher then does the math. Jev supplies the meaning; the optimizer still does the optimizing. That split is deliberate: TypeSafe's docs note Jev is weak at arithmetic, and the numeric part is already solved. Live incidents typed into the demo ("Car C door keeps sticking", "Trauma incoming to the ED in 5 minutes") go through a second Jev call (event type, floor, car). The physical effect happens in both buildings, but only the Jev side can respond. ## Results The optimizer didn't get smarter; it got better inputs. Mean over 16 randomized traffic scenarios that were NOT used for tuning: - Emergency patients wait: 46s → 13s (−71%) - Patient beds wait: 80s → 24s (−70%) - Everyone, on average: 31s → 19s (−38%) - Trips where a bed didn't fit: 120 → 3 Jev came out ahead in 14 of 16 scenarios. ### Limitations - It's a simulation; the physics and traffic mix are assumptions. - I wrote the test requests myself, so Jev's accuracy on real hospital language is untested. - The baseline is a textbook dispatcher, not a commercial controller. The claim is "the same optimizer with vs. without semantic inputs," not "better than industry systems." ## What's next Test on requests written by real clinical staff; use Jev's confidence scores to handle uncertain requests conservatively; compare against published dispatch algorithms. The broader pattern is to take optimization we've already solved numerically and give it the semantics it's missing. It applies anywhere meaning changes the right answer: hospital porters, ambulances, warehouse robots, job queues.
Keep exploring what builders shipped.
HackerSquad project
Painting Band
A live band you conduct with paintings: arrange artworks on a musical staff, and every bar an AI conductor (TypeSafe Jev) decides how the band plays while Google's Lyria RealTime generates the music. # Painting Band 🎨🎶 **Arrange paintings on a staff. A playhead sweeps across. Every bar, an AI conductor decides how the band plays, and an AI music model plays it live.** Nothing is pre-recorded. The music is generated live from what's on the canvas. ## How it works 1. **See:** Gemini looks at each painting and writes how it should sound: mood words, sound ideas (e.g. "cascading koto arpeggios"), instruments, and the painting's musical tradition (Japanese, Hindustani, Western…). Upload your own image and it's described in about 2–3 s. 2. **Arrange:** Drag paintings onto the staff. - **Left → right** = when a painting plays - **Height** = register (high or low) - **Size** = how strongly its mood and sounds lead 3. **Conduct:** Every bar (~2.7 s), **TypeSafe Jev** answers up to 12 typed questions in parallel in ~150–300 ms: - how loud each painting should be, and the mood and energy - drums, bass and the lead instrument - two extra sounds and the transition - which culture leads when traditions mix Jev never plays notes; it only decides. 4. **Play:** Jev's choices become weighted text prompts plus density, brightness and mute settings for **Google Lyria RealTime**, which streams AI-generated 48 kHz audio and blends toward each new decision. The music changes when you move, resize, add or remove a painting. ## Architecture ``` Canvas → scene as words → Jev (decides) → translator → Lyria RealTime (plays) ↘ Strudel (backup engine) Images → Gemini vision → mood, sound ideas, instruments, culture ``` - **Deciders never make sound; engines never make decisions.** Code sits in between. - **Deadline-safe:** if Jev is later than 150 ms before the next bar, the band reuses the last bar's choices, so the music never stops. - **Always playing:** if Lyria stalls, the app switches to **Strudel** (a browser-based live-coding music engine) mid-song, and you can switch back with one click. - **Explainable:** the `</>` panel shows each bar's questions and Jev's odds for every option, the exact prompts sent to Lyria, what Gemini saw in each painting, and a live log of every model call. ## Features - Drag, resize and delete paintings; draggable playhead (Home = start) - Silence where there's no painting under the playhead - Upload any image; Gemini describes it (with automatic model fallback when busy) - Cultural awareness: each painting's musical tradition shapes the sound, and Jev picks which tradition leads - Jev vs. Rules toggle (keys J/R) to hear the difference judgement makes - Live stats: Jev latency, missed bars, and cost (~$0.00001 per bar) ## Tech stack - **Vite + React + TypeScript** - **TypeSafe Jev:** per-bar decisions (`/v1/systemone`, typed choice answers with confidence) - **Google Gemini:** image understanding (structured JSON output) - **Google Lyria RealTime:** streaming music generation (`@google/genai`) - **Strudel:** fallback engine (`@strudel/web`, General MIDI soundfonts) - API keys stay server-side behind a Vite proxy (except Lyria, which streams from the browser in this local demo) ## Run it ```bash npm install cp .env.example .env.local # add JEV_KEY, JEV_BASE_URL, VITE_GEMINI_KEY npm run dev ``` Open http://localhost:5173 and drag a painting onto the staff. ## Paintings Seven public-domain works from Wikimedia Commons: Hokusai, Monet, Van Gogh, Bruegel, Seurat, Rembrandt and Raja Ravi Varma.
HackerSquad project
Reinforcement Learning for Enemy ai
a 2D platformer where every decision and every physics tick goes through jev, a physics/AI backend (currently a local mock, swappable for the real service). You have 30 seconds to reach the flag as many times as possible. Deaths respawn you — the clock doesn't stop. High score persists across sessions. Everything runs through jev: - step — all physics: player, bullets, monsters (gravity, velocity, AABB collision) - aim — two turrets that study your recent movement history and adapt after misses (leading runners, ambushing campers, shooting landing spots of jumpers) - decide — two flying monsters that dash every second in 2D, intercepting where your velocity says you'll be - reset — wipes all learned state on a new game (N); respawns keep the memory — the enemies keep learning mid-run Controls: ←→/A/D move · Space jump · R respawn · N new game How the game talks to jev The context stream — history Every frame, game.js appends one sample: ```js { t: 12.483, x: 340.2, y: 464, vx: 320, vy: 0 } ``` It's a rolling 12-second ring buffer (HISTORY_SECS), ~720 samples of your position and velocity — the raw material for every enemy decision. Nothing else about you goes over the wire; habits are computed from this stream, on jev's side. The three decision channels (all async, all JSON request/response): ``` game.js jev ───────────────────────────────────────────────────────── step({ body, solids, dt }) → { x, y, vx, vy, onGround, touchingWall, stats } aim({ id, muzzle, history, now, { fire, dir, target, mode } report }) decide({ id, offset, pos, → { action:'dash'|'idle', history, now }) dir:{x,y}, vx, vy } reset({}) → {} ``` step — physics. The game never moves anything itself. Player, both monsters, and every bullet are each submitted as {x, y, w, h, vx, vy, noGravity?} plus the level's solid rects and dt. jev returns resolved positions and contact flags; the game applies them verbatim. noGravity: true on a body = flight (monsters, bullets share the same solver, gravity skipped). aim — the shooters. Per frame, per turret: the request carries the turret's id and muzzle, the full history buffer, now, and report — the outcome of its last shot ({hit: true|false}). That's the feedback loop: jev answers fire: false while its 2 s cooldown runs, or {fire: true, dir, target, mode} where mode names the tactic it picked (lead runner-prediction, zone bombardment of your favorite territory, anti-jump at your landing spot). Each turret has an independent cooldown by id, but hit/miss learning is shared — what one learns, both use. decide — the dashers. Per frame, per monster: id + offset give each its own 1-second cadence, phase-staggered (m1 is offset 0.5 s so they don't dash in lockstep). The request has the monster's pos and the same history. jev reads the last ~1 s of samples, averages your vx/vy, and returns a normalized 2D dir plus the impulse — it intercepts where you're heading, including vertically (swoops up at jumpers, dives at fallers). idle between pulses; the game dampens velocity 0.94×/frame. The loop in one breath: the game is a sensor array and a renderer — it records what you do, asks jev what everything should do next, and draws the verdict. The mock computes the brains locally; set endpoint in jev.config.js and the identical JSON POSTs to {endpoint}/step|aim|decide|reset. The tactic word in the HUD — zone, lead, or anti-jump changes based on what you just did (standing still → zone, running → lead, jumping → anti-jump) - Shots get more accurate over a run — every miss feeds back to jev, which adjusts where the next bullet aims; the target coordinates in the HUD shift after each miss - N resets it — new game wipes the memory and the enemies go back to firing dumb straight shots That's the whole story: the turret's aim line in the HUD is literally jev telling you what it learned.
HackerSquad project
Sreak
Real-time persuasion training game — talk your way past an AI guard, investor, or friend, and every sentence is instantly scored and reacted to.