DEV Community: Srigouri Siddani

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

Srigouri Siddani — Sun, 04 Oct 2026 18:29:32 +0000

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.

Starting with the investigation concept The first version was focused on the basic incident dashboard:
incident overview
timeline
evidence
conflicting claims
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.
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.

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 🚀

CrisisIQ: An AI Investigation Agent That Doesn't Guess Where Its Evidence Came From

Srigouri Siddani — Fri, 02 Oct 2026 06:28:30 +0000

A submission for the Sanity Challenge — Path One: Ship an Agent That Queries Real Content

🚨 The Problem:

When an investigation depends on multiple sources, the difficult part isn't generating another AI answer.

It's knowing why the answer should be trusted.

A useful investigation agent needs to answer questions like:

What does the source actually say?
Which evidence supports this conclusion?
Are two sources contradicting each other?
Where did this particular claim come from?
Can another person inspect the evidence behind the answer? That's what I built CrisisIQ to explore.

🧠 What I Built:

CrisisIQ is an AI-powered investigation interface that turns source material into a structured investigation.

Instead of asking an LLM:

“What happened?”

and trusting whatever comes back, CrisisIQ is designed around:

SOURCE
↓
SANITY KNOWLEDGE BASE
↓
STRUCTURED CONTENT
↓
AGENT QUERY
↓
EVIDENCE + CLAIMS
↓
INVESTIGATION RESULT

The important part is that the agent isn't operating on a pile of unstructured text.

It can work against content that has structure and provenance.

👀 The Interface:

The main interface is intentionally built like an investigation workspace rather than a generic chatbot.

You can see:

active investigations
evidence
source information
findings
conflicting claims
investigation status

The goal was to make the evidence trail part of the interface instead of hiding it behind the AI response.

🔎 The Interesting Part: Sanity Context

This is where the project becomes a Path One project rather than simply an AI app.

I pointed Sanity Context at the content used by the investigation.

That content is distilled into a Knowledge Base that the agent can query through MCP.

Instead of manually dumping documents into the prompt, the agent can retrieve relevant structured content when it needs it.

          Sanity
            │
            ▼
    ┌────────────────┐
    │ Knowledge Base │
    └───────┬────────┘
            │
            │ MCP
            ▼
    ┌────────────────┐
    │ CrisisIQ Agent │
    └───────┬────────┘
            │
            │ relevant content
            ▼
    ┌────────────────┐
    │ Investigation  │
    └────────────────┘

🧩 Why Structure Matters:

This was the part I found most interesting.

A normal keyword search can often answer:

“Find documents mentioning X.”

But an investigation isn't always that simple.

Consider:

Source A
────────
"The incident started at 14:05."

Source B
────────
"The first alert appeared at 14:17."

Those aren't necessarily interchangeable facts.

CrisisIQ can preserve them as separate pieces of evidence instead of flattening everything into one generated paragraph.

That gives the agent something more useful to reason over:

Claim
├── Evidence
│ └── Source
│
└── Conflicting Evidence
└── Source

That's the reason I wanted the content to be structured in the first place.

🤖 What the Agent Actually Does:

The agent isn't just a chatbot sitting beside the content.

A typical investigation looks like:

User:

"What evidence supports the reported timeline?"
↓
Agent queries Sanity Context
↓
Relevant content retrieved
↓
Agent identifies supporting evidence
↓
Sources remain attached
↓
CrisisIQ presents the investigation

The important part is the middle.

The agent retrieves the content instead of relying entirely on what was placed in its initial prompt.

⚔️ When Sources Disagree:

This is where I wanted the project to go beyond a simple RAG demo.

Suppose the Knowledge Base contains:

Claim A

Source A reports that the event occurred at 14:05.

Claim B

Source B reports that the first observed event was at 14:17.

CrisisIQ doesn't need to pretend one sentence magically resolves the disagreement.

Instead, the conflicting evidence can remain visible:

14:05 — Source A

14:17 — Source B

That makes the uncertainty part of the investigation rather than something the model quietly hides.

🏗️ The Data Model:

The structured content behind the experience looks roughly like:

Incident Case
│
├── Incident ID
├── Summary
├── Severity
├── Status
│
├── Evidence[]
│ ├── Detail
│ ├── Source
│ ├── Source URL
│ └── Confidence
│
├── Timeline[]
│
├── Findings[]
│ ├── Finding
│ ├── Reasoning
│ └── Sources
│
└── Contradictions[]
├── Claim A
├── Claim B
└── Resolution

This is important because the agent isn't simply retrieving a giant blob of text.

It is working with relationships between pieces of information.

🧪 A Real Investigation:

I started with a question that required information from the underlying content rather than something that could be answered from the UI itself.

Then the agent queried the available content.

The useful part was seeing the answer come back with the underlying information still connected to its source.

The final interface presents the result as an investigation rather than just a chat response.

💻 The Code:

The project is open source:

CrisisIQ on GitHub

The important pieces are separated into:

CrisisIQ/
│
├── api/
│ └── chat
│
├── path-two/
│ ├── schemaTypes/
│ ├── src/
│ └── sanity.config.ts
│
└── ...

The application handles the investigation experience, while Sanity handles the structured content layer.

🌐 Demo:

Live demo:

vercel.com

Repository:

Srigouri08 / CrisisIQ

AI-powered incident investigation agent using Gemini and Sanity Context MCP.

CrisisIQ

CrisisIQ is an incident investigation dashboard for turning scattered operational records into a clear, evidence-grounded investigation. It helps teams reconstruct what happened, compare conflicting accounts, and keep uncertainty visible instead of jumping to an unsupported root cause.

Case #001

The first dashboard case is fictional PulsePay — The 37-Minute Outage. Its timeline and evidence panels are demonstration content; the investigation agent does not receive those panels as evidence and determines conclusions from content retrieved through Sanity Context.

Investigation workflow

Evidence retrieval: collect relevant source material through Sanity Context.
Timeline reconstruction: arrange reported events into a sequence.
Contradiction analysis: compare conflicting claims and the records that support or challenge them.
Uncertainty detection: keep gaps and competing explanations visible rather than hardcoding a root cause.

Architecture

CrisisIQ → Gemini → Sanity Context MCP → Sanity Knowledge Base → evidence

The browser chat sends messages to POST /api/chat. Locally, Vite…

View on GitHub

Demo note: Some investigation functionality depends on the configured model/API credentials.

🧠 What Sanity Changed About the Build:

The biggest thing I learned from this project is that retrieval isn't the interesting part by itself.

The interesting part is what happens when the retrieved information already has structure:

content
↓
relationships
↓
provenance
↓
retrieval
↓
reasoning

That gives the agent something much better to work with than a flat collection of documents.

🛠️ What I Would Improve Next:

There are still things I'd like to take further:

richer source provenance
more complex conflicting-claim resolution
larger Knowledge Bases
better investigation timelines
stronger evaluation of retrieved evidence
more automated investigation workflows

But the core experiment works:

Can an agent become more useful when it queries structured, source-linked content instead of treating the web or documents as one giant text box?

That's what I wanted to explore with CrisisIQ.

📌 Sanity Project Details:

Sanity Project ID:
0cub7gdo

Dataset:
production

Sanity Context:
CrisisIQ uses Sanity Context MCP to retrieve structured incident-investigation content from the Sanity Knowledge Base. The agent queries this content during investigations and uses the retrieved sources to compare evidence, identify conflicting claims, and ground its responses in the underlying Sanity content.

What if a Journal Could Help You Reflect? Building MindMate with Google Gemini

Srigouri Siddani — Wed, 16 Sep 2026 17:29:10 +0000

What if a Journal Could Help You Reflect?

Student life can get noisy.

Between classes, deadlines, assignments, exams, friendships, and everything happening in between, sometimes you just need a quiet place to put your thoughts.

That idea became MindMate — a simple AI-powered journaling application I built to make everyday journaling a little more meaningful.

Instead of only storing what you write, MindMate uses Google Gemini to provide a small moment of reflection after you journal.

🌱 The idea behind MindMate

Journaling is already a way to slow down and understand your thoughts.

I wanted to explore a simple question:

What if a journal could help you reflect on what you wrote?

MindMate lets users write private journal entries and then receive an AI-generated reflection covering:

💭 Mood
📝 A short summary
🔎 Main topics
💜 A supportive suggestion

The goal isn't to replace human connection or professional support.

It's simply to create a small pause between “I wrote this” and “I understand this.”

✨ What I built

MindMate combines a private journaling experience with an AI reflection layer.

🔐 Private by design

Users sign in through Firebase Authentication, while journal entries are stored in Cloud Firestore.

Firestore security rules restrict access so authenticated users can access their own journal data.

✍️ Write naturally

There is no complicated format to follow.

Users can simply open their journal and write whatever is on their mind.

💭 AI-powered reflection

After submitting an entry, MindMate sends the journal content to the backend, where Google Gemini analyzes it and generates a structured reflection.

The response includes the user's mood, a short summary, important topics, and a supportive suggestion.

🤖 Where Google Gemini comes in

Google Gemini is the core AI component of MindMate.

The application uses Google's GenAI SDK from the backend to send journal content for analysis.

The basic flow looks like this:

Journal Entry → Node.js + Express Backend → Google Gemini → AI Reflection

I kept the Gemini API key on the backend using environment variables rather than exposing it in the frontend.

This was also an important part of the project for me: I didn't just want to make something that worked — I wanted to understand how to integrate an AI API responsibly into a real application.

🛠️ Under the hood

Here is the technology stack behind MindMate:

Part	Technology
Frontend	React + Vite
Authentication	Firebase Authentication
Database	Cloud Firestore
Backend	Node.js + Express
AI	Google Gemini
API SDK	Google GenAI
Deployment	Render

The frontend and backend are deployed separately, with the backend handling the Gemini API interaction.

👩‍💻 Building this as a student

One of the most interesting parts of building MindMate wasn't just the AI integration.

It was everything around it.

I had to work with authentication, database security rules, API routes, environment variables, CORS, deployment, and connecting multiple services together.

It made the project feel less like a small coding exercise and more like a real application.

There were definitely moments where something broke and I had absolutely no idea why. 😭

But fixing those problems was probably where I learned the most.

🔮 What's next?

MindMate is still a small project, and there is a lot I would like to explore.

Some ideas for future versions include:

More detailed journaling insights
Long-term reflection patterns
Better accessibility
A more polished mobile experience
More ways to organize and revisit journal entries
Stronger privacy-focused features

For me, the project is less about building a “perfect” AI product and more about exploring how AI can fit naturally into something people already do.

🌸 Try MindMate

You can try the live application here:

https://mindmate-1sxd.onrender.com

And the source code is available on GitHub:

https://github.com/Srigouri08/MindMate

Final thoughts

MindMate started with a simple idea: make journaling feel a little more reflective.

Building it taught me that AI doesn't always need to be complicated or flashy.

Sometimes, a useful AI experience can start with something as simple as giving someone a better way to understand what they already wrote.

Build small. Learn loudly. ✦

MindMate is a student-built project and is not a substitute for professional mental-health care.