"A honest account of the decisions that actually matter when the clock is running."
There is a moment in every hackathon where the project you planned to build and the project you are actually going to submit stop being the same thing.
For me, that moment arrived at 5:43 AM.
The Project
oourmind.io is a real-time interpretability lab that visualizes the internal reasoning state of a large language model as a navigable 3D environment. The idea: instead of reading model outputs, you feel them. Three personas — the Architect (logical, structured), the Oracle (creative, associative), and the Shadow (adversarial, edge-case) — occupy three zones in a Three.js scene. As the model reasons, the visualization moves.
The philosophical foundation is simple and it is large: right now, nobody can see inside the models they depend on. oourmind makes that visible — not for researchers, but for anyone.
That is the vision. Here is what happened at 5:43 AM.
The Message
Backend consultant, who spent two days thinking through the technical architecture — sent me this:
"I don't think I will be able to complete the python backend on my own for the hackathon; as the mistral models and the open weights seems to be currently in development and not suitable for mechanistic interpretability, if we swap the model I can do so much. Let me know how to proceed from here, as I am currently feeling overwhelmed to make a decision regarding the backend."
Honest. Clear. And exactly the kind of message that forces a founder to make a decision they were hoping to avoid.
Before that message, he had already done something genuinely valuable. He had mapped out the two possible architectures with precision:
Scenario A vs Scenario B — The Real Technical Decision
Scenario A — API (No Activation Layers)
Using the Mistral API, which is a closed black box. It returns a text response and a finish_reason but no log_probs. You can ask the model to score its own response across Oracle, Architect, and Shadow dimensions — but that is exactly the problem. The coordinates become self-reported, not extracted from the model's internals. Fast, works now, but the mechanistic interpretability is approximate. The model is telling you what it thinks it is doing. Not what it is actually doing.
Scenario B — Local Model (Real Activation Layers)
Run Ministral-3B directly on the laptop. Full access to every layer's internal state. Extract actual activation values from three layer groups and use those as the x/y/z coordinates for the Three.js visualization. The problem: TransformerLens does not support this model's architecture yet — issues with the Mistral 3 config, which is still early in development. Solution: use raw PyTorch hooks instead. The tradeoff is it runs on CPU, meaning you pre-generate the point cloud offline in approximately three minutes and serve a static points.json to the Three.js visualization.
Scenario B is the right answer scientifically. Scenario A is the right answer for a hackathon with less than 24 hours left.
The Decision Nobody Tells You About
Here is what the hackathon documentation does not prepare you for: the moment when you have to choose between the project you believe in and the project you can actually ship tonight.
Scenario B is oourmind as it should exist. Real activation layers. Genuine mechanistic interpretability. The model's internal state extracted, not reported. That is the product. That is what makes the visualization honest.
But Scenario B requires a backend that is not built, a library that does not yet support the architecture, and a CPU runtime that takes three minutes to generate a point cloud — on a deadline measured in hours.
Scenario A ships tonight. Scenario B ships in three weeks.
I chose Scenario A.
What This Actually Means for the Project
Here is the thing that this analysis made clear, even if neither of us said it explicitly at the time:
The gap between Scenario A and Scenario B is the product.
The model telling you what it thinks it is doing versus what it is actually doing inside — that gap is the entire problem oourmind exists to solve. It is what Michael Burry was writing about when he surfaced an 1880 Smithsonian presentation about a deaf-mute who reasoned about the origin of the universe before he had any language. It is what Foucault meant when he wrote that power is tolerable only on condition that it mask a substantial part of itself.
The self-reported coordinates of Scenario A are a perfect metaphor for the current state of AI transparency. The model gives you a number. You have no way to verify it. You trust it because it is the only option available.
oourmind is being built to make Scenario B the default. For everyone. Not just for researchers with local GPU clusters and three minutes to spare.
What You Actually Do With Less Than 24 Hours
You stop building the product and start building the argument.
The Three.js scene works. The Blue Grid is merged into main. The personas are visible in space. That is enough for a demo.
What you spend the remaining hours on is making sure the person watching the demo understands why it matters. The founder statement. The submission description. The one sentence that lands before anything else:
"Every AI model has a shadow. Nobody shows you when it activates."
The code is the proof of concept. The argument is the submission.
A Note on Collaboration Under Pressure
The decision I made at 5:43 AM — Scenario A, frontend only, submit the argument — is the right decision. I know that because making it felt like giving something up. The best hackathon decisions usually do.
What Comes Next
oourmind.io is the vision. The next step is Scenario B — real activation layers, genuine interpretability, the model's internal state made spatial and felt rather than self-reported and approximate.
*Built for the Mistral AI Hackathon, March 2026. *
Find me in the wild: humiin.io
Top comments (2)
Sounds intense!
It was indeed 🤓