This case study is about a disagreement, a proof, and what happened when the proof was generalized and released.
It is also about the specific kind of frustration that happens when you have the right architectural idea and cannot get anyone to test it with you.
The Project
A team was building a self-improvement game — a PWA where players move through a fantasy world represented by a hand-drawn map. Each location on the map is a psychological territory: Jungle of Power Games, Desert of Self-Knowledge, Swamps of Toxicity, Alchemy Bay. Players begin at a starting node, draw a quest card, complete the quest through a combination of LLM conversation and real-world action, and on success are moved to the next location. The map is the world. The world is a therapeutic framework made playable.
The map was hand-drawn. Richly detailed. Entirely bitmap.
The Disagreement
The team had a developer. The developer looked at the hand-drawn map and said: vector graphics are required. Without vector source files, navigation on the map is not possible. The project cannot be built as specified.
The counter-argument was simple: a vector overlay on the bitmap is sufficient. The image carries the visual world. A transparent coordinate layer on top carries the navigation logic. The two systems don't need to be the same file. The developer did not want to hear it.
This is a specific and common failure mode in technically-gated projects. The person with implementation knowledge mistakes an implementation constraint for an architectural impossibility. "I don't know how to do this with a bitmap" becomes "this cannot be done with a bitmap." The person with the product vision, who doesn't code, has no way to prove the distinction — and usually backs down.
The decision here was not to back down. The decision was to prove it.
The Proof of Concept
Codex was given the problem, the assets, and a structured specification: what the system needed to do, what the map represented, what a player state looked like, what a quest card cycle needed to produce. The architectural decision — vector overlay on bitmap using normalized x/y coordinates — was defined before any code was written. That decision was human. The implementation was Codex's.
What was built in an afternoon:
A working PWA with two-player support. Players are placed at starting nodes on the map. Each player has a state: their current location, their active quest, their movement path. A card cycle handles quest drawing, quest resolution (success or failure), and node advancement. An event log records every movement, meeting, and resolution in real time. A path tracing tool allows map edges — the routes between nodes — to be defined by clicking directly on the map image and saved as JSON coordinate arrays.
The path tracing tool is the architectural proof. Each edge is stored as a series of normalized x/y points mapped against the bitmap dimensions. When a player moves from Alchemy Bay to Jungle of Power Games, the system interpolates along those points. The hand-drawn lines on the image become the actual paths. No vector file. No conversion. No special tooling. A coordinate overlay on a bitmap, exactly as proposed.
The event log from the first test run:
movement:arrived | player:p1 | ava-greeblin | alchemy_bay → jungle_power_games
card:quest_drawn | player:p1 | "Travel to Alchemy Bay" | destination: alchemy_bay
cycle:advanced | player:p1 | reason: quest_success
quest:resolved | player:p1 | success:true | "Travel to Jungle of Power Games"
avatars:met | player:p1 + player:p2 | position: {x:0.4, y:0.4}Two players. Moving. Meeting. Quests resolving. The system working.
What HITM Made Possible Here
The developer's objection was implementation-first thinking: I cannot build this, therefore it cannot be built. HITM is architecture-first thinking: here is what the system needs to do, here are its boundaries, now find an implementation that fits within them.
The architectural decision — overlay, not conversion — was made before touching any code. It was made from product understanding, not technical knowledge. The implementation question ("how do you put a coordinate system on a bitmap?") was delegated entirely to Codex. The answer turned out to be straightforward: normalized coordinates, a transparent canvas layer, click-to-trace tooling for edge definition. Nothing exotic. Nothing that required vector source files.
This is what the Human-in-the-Middle model protects: the product vision from implementation gatekeeping. The human defines what the system must do and what constraints it must respect. The AI finds the path within those constraints. The developer's certainty that something is impossible is not automatically an architectural fact — sometimes it is just an implementation assumption that hasn't been tested.
The POC tested it. The POC was correct.
Generalizing the Proof
The original POC used a specific hand-drawn map from a specific project. But the architecture doesn't care what the map is. Any image can be the world. Any set of named nodes can be the locations. Any edge definition can be the paths between them.
To demonstrate this cleanly — and to make the proof available to anyone who wants to build on it — the map has been swapped for one generated with Azgaar's Fantasy Map Generator, an open-source tool for generating detailed fantasy cartography. The system works identically. The hand-drawn specificity of the original map is replaced by the procedural richness of the generated one. The architecture is unchanged.
The result is a generalized, open-source proof of concept: a quest-and-movement engine that can take any map image, any node definition, and any edge trace, and turn it into a navigable game world.
[Live demo → LINK TO BE ADDED] [Source code → LINK TO BE ADDED]
Fork it. Drop in your own map. Define your own nodes. Trace your own edges. Build your own world.
What This Case Study Demonstrates
Architectural intuition is a professional skill. Knowing that a vector overlay on a bitmap is sufficient — without being able to implement it yourself — is a valid and valuable form of technical knowledge. It is the kind of knowledge that product designers, UX architects, and systems thinkers carry and often cannot defend against implementation-first resistance. HITM gives that intuition a path to proof.
A proof of concept is a complete argument. The working event log, the path tracing tool, the player state machine — these are not mockups. They are running code that answers the question "is this possible?" with a live demonstration. The answer to "that can't be done with a bitmap" is not a longer explanation. It is a link.
Generalization is more valuable than the specific build. The original POC was built for one project with one map. The generalized version, built in additional hours by swapping one asset and confirming the architecture holds, is available to anyone. Open-source proofs of method compound in ways that client deliverables do not.
The methodology scales across domains. This is a game engine. The previous case studies cover an emissions compliance workflow (CO2Calc) and a street ritual application (Spiegel des Universums). The architecture in all three cases is the same: research is human, structure is human, AI executes stepwise, nothing ships without review. The domain does not determine whether the method works. The method works regardless of the domain.
Technical Appendix
Map layer: Bitmap image (PNG/JPG). Any dimensions. Displayed at full container width. Coordinate system normalized 0–1 on both axes, independent of display size.
Node system: Named nodes with x/y positions on the normalized coordinate system. Each node maps to a location on the map image. Node definitions stored as JSON.
Edge system: Named edges connecting two nodes, defined as arrays of intermediate x/y points. Points traced directly on the map image using the built-in path tracing tool. Edge definitions stored as JSON. Player movement interpolates along edge points.
Player state: Per-player state machine tracking current node, active quest, movement status. Supports multiple simultaneous players. Avatar collision detection for player meetings.
Card cycle: Quest cards with destination node targets. Draw, resolve (success/fail), and advance cycle. Card resolution triggers node movement along the defined edge path.
Event log: Real-time structured log of all system events: movement starts and arrivals, card draws and resolutions, cycle advances, avatar meetings.
Stack: Plain HTML/CSS/JS. No framework. Runs as a PWA. No server required for the core engine.
Map source for demo: Azgaar's Fantasy Map Generator (MIT license).
The Human-in-the-Middle methodology is documented at jba.schmidtpabst.com. More case studies at context.schmidtpabst.com.