RK's Rambling

Racecraft · Technical Deep Dive · Sensor Fusion & Gemma Generalization Fusing 100+ On-Device Sensors at 130 MPH , And Why Gemma Didn't Need Fine-Tuning Inside Racecraft's real-time telemetry engine: multiplexing AiM CAN bus, RaceBox BLE, OBDLink, and 6-DOF IMU streams on Android, zero-shot corner doctrine generalization, and benchmarking Gemma 4 E2B on Tensor G5 silicon. A few days ago after sharing early results from Racecraft (Project Koru) , a question popped up in one of the comments that immediately caught my attention: "Curious how your team handled real-time fusion of 100+ sensors on-device. Did Gemma need race-specific fine-tuning, or did general coaching logic generalize?" It's the exact right question to ask. When people hear "AI race coach running on a phone in real time at Sonoma Raceway," they usually picture one of two extremes: either a brittle set of hardcoded if (speed < 40) statements, o...

Aegis-Chaos · Post 1 of 1 · → View on GitHub From “Vibe Coding” to Closed-Loop SRE How zero-trust policies, Git isolation, and math-based budget guardrails let an autonomous agent say “no” — and mean it. Aegis-Chaos: An autonomous SRE control plane with real-time zero-trust guardrails. Most AI coding assistants today operate on trust. You prompt, they generate, and you ship. That works—until it doesn’t. A single destructive command, an uncaught runaway loop, or a stale approval can turn an autonomous agent into a production incident. Project Aegis-Chaos was built to answer a simple question: what happens when the AI says “no”? This post walks through the zero-trust architecture, parallel isolation strategy, math-based budget guardrails, and end-to-end visual verification pipeline that make up our closed-loop SRE control plane—designed for the Google Developer Expert Sprint and built on the Antigravity SDK. The Decla...

Racecraft · Part 3 of 5 · ← Prologue Splitting the Brain to Beat the Clock How a "brake!" lands in 5 milliseconds while a cloud model thinks for five seconds — in the same app, on the same frame, without ever colliding. Two posts in, we have a coach that knows who's driving and what to say. This post is about the only thing that lets it say anything useful: structure. Specifically, the decision to give the system not one brain but three, each on its own clock, with an ironclad rule about which one is allowed to make the driver wait. I call it the Split-Brain engine , and the whole design collapses out of one observation. The three jobs a coach does — react, strategize, prepare — have wildly different deadlines. Trying to serve all three from one code path means the fastest job inherits the latency of the slowest. That's the original sin of every cloud-first coaching app. So I refused to let them share a path. The Spli...

Racecraft · Part 2 of 5 · ← Prologue Teaching the Coach to Read the Driver The best instructors don't coach the car. They coach you , and they figure out who you are in about two laps. Here's how we taught software to do the same. In Part 1 I argued that trust is the only metric that matters, and that it's mostly a latency problem. That's true , but there's a second half I glossed over. The same sentence, delivered at the exact same millisecond, can build trust or destroy it depending on who's listening. Tell a nervous first-timer "brake spike detected, modulate your input" and you've just handed them a stack trace mid-corner. Tell a fast amateur "squeeze the brakes, don't stab" for the tenth time and they'll mute you out of sheer irritation. The words have to match the driver. So before Racecraft can say anything, it has to answer a question a human coach answers instinctively: how good is this person, rig...