CrisisIQ: An AI Investigation Workspace for Incidents That Don't Agree With Each Other

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange
What I Built
Incident investigations rarely fail because there isn't enough information.
They fail because there is too much information, coming from different places, with different versions of what happened.
So I built CrisisIQ, an incident investigation workspace that uses structured Sanity content as its evidence layer and Gemini as an investigation agent.
Instead of simply asking an AI:
"What caused this incident?"

CrisisIQ is designed around a different question:
"What does the available evidence actually support?"

The app lets an investigator:

• reconstruct an incident timeline
• inspect individual evidence records
• compare conflicting claims
• identify contradictions
• keep uncertainty visible
• ask an AI investigation agent questions about the underlying Sanity knowledge base
• retrieve relevant structured content before generating an answer The first case is a fictional incident called PulsePay: The 37-Minute Outage.

Demo
🚀 Live Demo:
https://crisis-chmb8ibjr-northstar-e8ce.vercel.app/

The deployed app contains:
Authentication → Investigation Workspace → Timeline → Evidence → Contradiction Analysis → AI Investigation

Main investigation workspace
The interface was intentionally designed to feel more like an internal investigation tool than a generic AI chatbot.
The investigator can move between the incident overview, timeline and evidence without losing the context of the case.
Evidence & contradiction view

One of the important design decisions was to show competing explanations instead of forcing a single root cause.
For example, a deployment record may indicate that a rollback happened at one time while monitoring data suggests the incident started earlier.
The UI makes that disagreement visible.
AI Investigation

The investigation agent is not supposed to simply answer from the information displayed in the frontend.
Its intended flow is:

Investigator
↓
CrisisIQ
↓
Gemini
↓
Sanity Context MCP
↓
Sanity Knowledge Base
↓
Retrieved evidence
↓
Evidence-grounded response

That distinction was important to the project.
Code
The complete project is available here:
GitHub:
CrisisIQ GitHub Repository
The repository contains the frontend, API route and deployment configuration used for the project.
My Build Process
This is probably the most interesting part of the project.
I didn't start with a perfectly designed architecture.
I started with a rough idea:
"What if an AI could investigate an incident instead of just summarizing it?"

From there, I used an AI-native development workflow to progressively turn the idea into a working application.

1. Starting with the investigation concept The first version was focused on the basic incident dashboard:
2. incident overview
3. timeline
4. evidence
5. conflicting claims
6. investigation interface The goal was to make the product feel like a tool an actual incident analyst might use. I deliberately avoided making it look like another generic chatbot with a text box in the middle of the screen.
7. Giving the content structure The next step was figuring out what the AI should actually investigate. Instead of putting everything directly into frontend code, the project separates the case interface from the knowledge used for investigation. That led to the Sanity layer. The conceptual content model became: Content Purpose Incident Main investigation context Timeline Event Reconstruct what happened Evidence Store supporting source material Claim Represent an explanation or statement Contradiction Connect competing evidence Investigation Context Provide structured information to the agent

This made Sanity more than a place to store text.
It became the knowledge layer behind the investigation experience.

1. Going beyond a normal Sanity frontend This was where the project became more interesting. Instead of building: Sanity → React → Display Content

I wanted:
Sanity
↓
Context retrieval
↓
AI investigation
↓
Custom investigation interface

The application uses a server-side investigation route and connects the AI layer with the Sanity Context MCP.
The intended architecture is:
CrisisIQ Investigation Flow

CrisisIQ Investigation UI
↓
Investigation API
↓
Gemini Investigation Agent
↓
Sanity Context MCP
↓
Sanity Knowledge Base

CrisisIQ Investigation UI
Users ask questions, explore incidents, review evidence, timelines, contradictions, and AI-generated insights.

Investigation API
Handles investigation requests, manages context, and securely connects the application to Gemini and Sanity.

Gemini Investigation Agent
Analyzes the retrieved context, compares evidence, identifies contradictions, and generates evidence-grounded investigation answers.

Sanity Context MCP
Retrieves relevant structured incident content, evidence, timelines, claims, and related records from Sanity.

Sanity Knowledge Base
Stores the structured investigation data, including incidents, evidence, timeline events, claims, contradictions, and supporting sources.

This was the part I cared about most.
I didn't want the AI to pretend it knew the answer.
I wanted it to retrieve evidence first and reason from that evidence.
The Prompts That Worked
One of the biggest lessons from the build was that vague prompts produced vague implementations.
Prompts became much more useful when I described the behavior I wanted, rather than just the technology.
For example:
Build the investigation experience around evidence and contradictions. The AI should not invent a root cause when the available evidence is incomplete. Show competing explanations and make uncertainty visible.

That produced much better product decisions than simply saying:
"Make an incident management dashboard."

Another useful pattern was asking the AI to work on one system at a time:
Build the evidence model.
↓
Build the timeline.
↓
Build contradiction analysis.
↓
Connect Sanity.
↓
Connect the investigation API.
↓
Connect Gemini.
↓
Deploy.
↓
Debug.

The Prompts That Didn't Work 😭
Not everything worked on the first try.
And honestly, that became one of the most useful parts of the project.
At different stages I ran into issues involving:

• deployment configuration
• authentication routes
• environment variables
• Sanity Context credentials
• Gemini API configuration
• Vercel deployment behavior
• the investigation API returning no answer
• UI state not matching the backend state At one point the application itself was working, but the investigation agent returned: "The investigation service is missing server credentials."

That turned out not to be a frontend problem at all.
The missing server-side configuration was:
SANITY_API_READ_TOKEN
GOOGLE_GENERATIVE_AI_API_KEY

That debugging process changed how I thought about AI-native development.
The AI can generate a huge amount of code very quickly.
But shipping the product means repeatedly testing what it actually does, reading the error, finding the boundary where it failed, and prompting again.
Course-Correcting Instead of Starting Over
Rather than throwing away the project whenever something broke, I kept narrowing the problem.
For example:
"AI investigation doesn't work"
↓
"API returns no answer"
↓
"Server credentials missing"
↓
"Sanity token / Gemini key configuration"
↓
"Verify Vercel environment"
↓
"Redeploy"
↓
"Test actual investigation request"

That iterative loop became a major part of the build.
Why Sanity Matters Here
I didn't want Sanity to be a decorative CMS sitting behind the project.
The idea is that the investigation agent should have access to structured knowledge about an incident rather than relying entirely on whatever happens to be visible in the frontend.
That creates an important separation:
Frontend content
→ what the investigator sees
Sanity content
→ what the investigation system can retrieve
Gemini
→ reasons about the retrieved information
That separation is what makes CrisisIQ more than a dashboard with an AI button attached to it.
What I Focused On
The project was built around four principles:
Principle Why
Evidence first Reduce unsupported AI conclusions
Contradictions matter Real incidents rarely have one clean story
Uncertainty is data Missing evidence should remain visible
AI should investigate, not just summarize Make the AI useful inside an actual workflow

What I Would Build Next
If I continued developing CrisisIQ beyond the challenge, I'd take the investigation workflow even further.
Some ideas:

• approval states for investigation conclusions
• human review of AI-generated findings
• incident-to-incident comparison
• automatic evidence clustering
• investigation history
• richer Sanity workflows
• real-time collaborative investigations
• automated incident reports
• evidence confidence scoring The interesting part is that the content model already gives the application somewhere to grow. Sanity Project Details Sanity Project ID: PASTE YOUR SANITY PROJECT ID HERE

Dataset:
production

Sanity Context:
Sanity Context MCP
Read-only investigation knowledge retrieval

The project uses Sanity as the structured knowledge layer for the investigation agent.
Important: I am intentionally not including private API tokens or credentials in this post.

Agent Session

Agent Session:
PASTE YOUR PUBLIC DEV AGENT SESSION LINK HERE
The transcript is particularly useful for showing the iterative part of the build: the prompts, failed attempts, debugging and course corrections.
A Few Screens From the Build
Investigation workspace

Evidence comparison

AI investigation

Final Thoughts
The original idea was simple:
Give an AI an incident and ask it to investigate.
But the more I built, the more I realized that the difficult part isn't generating an answer.
It's knowing why you should trust that answer.
That's what I wanted CrisisIQ to explore.
Instead of:
AI says this happened.

The goal is:
Here is what the evidence says. Here is what conflicts. Here is what is missing. And here is what the AI thinks based on the available evidence.

That felt like a much more interesting thing to build with Sanity.
Built with: React · TypeScript · Vite · Sanity · Sanity Context MCP · Gemini · Vercel
Path: Sanity Challenge — Path Two: Vibe-Code Something Strange 🚀