DEV Community: Gopika

# 🛡️ DecisionShield: Building an AI That Checks Decision Readiness Before Recommending a Choice

Gopika — Tue, 13 Oct 2026 05:56:27 +0000

ai #gemma #opensource #hackathon

Don't just ask AI what to choose. Ask AI whether you have enough evidence to choose.

We use AI every day to help us solve problems and make decisions.

Which technology should we use?

Should we change our database?

Which cloud platform fits our requirements?

Are we choosing the right vendor?

Should we build a solution ourselves or use an existing one?

Modern AI assistants can answer these questions in seconds. Their answers may sound logical and convincing, but there is an important problem: a confident recommendation does not necessarily mean we have enough evidence to make the right decision.

What if AI could do something more useful than simply recommending an option?

What if it could identify our assumptions, highlight missing information, evaluate risks, and help us understand whether we are actually ready to make that decision?

That question inspired us to build DecisionShield, an AI-powered Decision Readiness and Risk Audit Platform.

We developed this project with our team, Wakie Wakie, during the Hacktoberfest Hack Day Coimbatore, organized by INIT Club and IDEA Club.

This article explains the problem, our approach, the architecture, the technologies we used, and what makes DecisionShield different from a conventional AI chatbot.

🔗 Project Links

Resource	Link
💻 GitHub Repository	DecisionShield on GitHub
🎥 Demo Video	Watch the project demo
📊 Presentation	View the project presentation

🤔 The Problem: AI Can Answer Before We Are Ready

Imagine asking an AI assistant:

Should our startup migrate from PostgreSQL to MongoDB?

A typical AI assistant might explain that MongoDB offers a flexible document model and can support horizontal scaling.

That response might be reasonable, depending on the application's requirements.

But before making the decision, we should ask a few more questions.

What do our database query patterns look like?
How important are transactions and data consistency?
Does our application depend on complex relational queries?
How much downtime can we tolerate during migration?
What will the total infrastructure cost be over the next three years?
Does our engineering team have experience with the new database?
What risks could arise during migration?

Without this information, choosing a database based on a general recommendation could introduce unnecessary complexity, unexpected costs, or operational problems.

The issue is not that AI cannot provide useful answers.

The issue is that AI may provide an answer even when important information is missing.

DecisionShield is designed to address this gap by examining the decision and the evidence behind it before presenting a readiness assessment.

💡 Our Idea: What Is DecisionShield?

DecisionShield is an AI-powered Decision Readiness and Risk Audit Platform.

Instead of immediately selecting an option for the user, it analyzes the decision context and identifies the information that supports or weakens the decision.

The platform organizes its analysis into several categories:

✅ Facts: Information supported by the provided context.
⚠️ Assumptions: Statements that have not been sufficiently verified.
❓ Unknowns: Important information that is currently unavailable.
📌 Claims: Statements that require further verification.
🚨 Risks: Potential problems that could affect the outcome.
🔍 Missing Evidence: Information needed to evaluate the decision more confidently.
🧪 Stress-Test Scenarios: Hypothetical changes that could affect decision readiness.

The structured analysis is then passed to a deterministic decision engine, which calculates a Decision Readiness Score.

For example, an assessment might look like this:

Decision Readiness: 64/100 — NOT READY

The system could identify three critical pieces of missing evidence that should be investigated before the decision is finalized.

This is an illustrative example of the intended assessment workflow, not a guarantee that every decision will receive the same result.

The important difference is that DecisionShield does not simply tell users what to choose. It helps them understand what they need to investigate before choosing.

🔄 How DecisionShield Works

The platform follows a structured pipeline that combines AI reasoning with deterministic scoring.

                USER DECISION
                     |
                     v
              Decision Context
                     |
                     v
               Gemma 4 E4B
              Semantic Reasoning
                     |
                     v
           Structured AI Analysis
                     |
          +----------+----------+
          |          |          |
          v          v          v
        Facts    Assumptions   Risks
          |          |          |
          +----------+----------+
                     |
                     v
              Missing Evidence
                     |
                     v
             Structured JSON
                     |
                     v
             Pydantic Validation
                     |
                     v
          Deterministic Decision Engine
                     |
                     v
           Decision Readiness Score
                     |
                     v
                Stress Testing
                     |
                     v
              Decision Stability
                     |
                     v
                Decision Audit

The workflow separates language-model analysis from numerical evaluation.

Gemma processes the decision context and generates structured findings. The backend validates the resulting data and passes it to the decision engine.

This separation helps make the scoring process more consistent, testable, and easier to inspect.

🧠 Why Not Build Another AI Chatbot?

One of our central design decisions was to go beyond a simple question-and-answer interface.

A conventional AI assistant typically follows this pattern:

User Question
     |
     v
    LLM
     |
     v
Text Recommendation

DecisionShield follows a more structured process:

Decision Context
       |
       v
Evidence Extraction
       |
       v
Information Classification
       |
       v
Risk Analysis
       |
       v
Missing Evidence Detection
       |
       v
Deterministic Scoring
       |
       v
Stress Testing
       |
       v
Decision Audit Report

The difference is the focus of the analysis.

A chatbot primarily responds to the question.

DecisionShield examines the quality and completeness of the information behind the decision.

It is not intended to replace human judgment. Instead, it aims to give decision-makers a clearer understanding of the available evidence, possible risks, and unresolved questions.

🧩 Core Features

1. Decision Workspace

The Decision Workspace is where users define the decision they want to evaluate.

Users can provide:

Decision title
Decision description
Available options
Background context
Requirements
Constraints
Existing evidence

For example:

Decision: Should our startup migrate from PostgreSQL to MongoDB?

Options:

Continue using PostgreSQL.
Migrate to MongoDB.

Context:

Our startup currently stores approximately 2 TB of data and expects significant growth over the next three years.

Constraints:

Small engineering team.
Limited migration budget.
Need to minimize operational disruption.

Providing context and constraints helps the system analyze the decision against the situation described by the user rather than treating the question in isolation.

2. AI-Powered Evidence Analysis

DecisionShield uses Gemma 4 as its semantic reasoning layer.

The model analyzes the supplied context and separates the information into categories that support the remaining workflow.

Facts

Facts are statements directly supported by the supplied context.

For our database example:

PostgreSQL is the current database.
The existing data volume is approximately 2 TB.
The team expects future growth.

Assumptions

Assumptions are statements that may be true but have not been sufficiently established.

Examples:

MongoDB will automatically solve our scalability challenges.
Switching databases will reduce operational complexity.
Migration will reduce long-term costs.

These statements require investigation rather than automatic acceptance.

Unknowns

Unknowns are important details that have not been supplied.

Examples:

Query workload patterns.
Transaction requirements.
Data consistency requirements.
Expected peak traffic.
Acceptable migration downtime.

Claims

Claims are statements that require verification before they can be relied upon.

For example:

"MongoDB will be cheaper over the next three years."

The system identifies such claims as items requiring supporting evidence.

The resulting classification provides the foundation for identifying risks and evaluating decision readiness.

3. Decision Readiness Score

DecisionShield calculates a score on a scale of 0 to 100.

The scoring process can consider dimensions such as:

Evidence quality.
Requirement coverage.
Evidence completeness.
Risk coverage.
Assumption load.
Unknown information.
Decision stability.

A key architectural principle is that Gemma does not directly generate the final numerical score.

Instead, the workflow is:

Gemma 4
   |
   v
Semantic Analysis
   |
   v
Structured JSON
   |
   v
Pydantic Validation
   |
   v
Python Decision Engine
   |
   v
Readiness Score

The language model is responsible for semantic analysis, while the backend handles validation and scoring.

For example, an illustrative report could contain:

        DECISION READINESS

              64 / 100

             NOT READY

Evidence Quality        72%
Requirement Coverage    80%
Risk Coverage           55%
Evidence Completeness   61%
Decision Stability      68%

These numbers are illustrative rather than universal thresholds or a claim that every category directly maps to the overall score.

The goal is to provide a structured assessment that helps users identify areas requiring further investigation.

4. Missing Evidence Detection

One of the most useful questions DecisionShield asks is:

What information are we missing that could materially change this decision?

For the PostgreSQL-to-MongoDB example, the platform might identify the following priorities.

Critical information to investigate

Current query workload and query performance.
Transaction and consistency requirements.
Expected peak traffic and workload characteristics.

Other important information

Migration downtime tolerance.
Infrastructure and maintenance costs over three years.
Team experience with the target database.

The workflow goes beyond listing unknowns.

It can also identify verification actions that help users investigate them.

For example:

Missing evidence: Expected peak traffic.

Suggested verification action: Measure current peak requests per second, examine traffic patterns, and estimate expected workload growth over the next three years.

This turns an abstract concern into a practical next step.

5. Risk Analysis

A decision can appear reasonable under normal conditions but still introduce significant risks.

DecisionShield identifies potential risks associated with the supplied decision context.

Risk information can include:

Severity.
Likelihood.
Impact.
Confidence.
Supporting evidence.

Consider the database migration example.

Potential risk: Complex relational workloads

If the application relies heavily on relational joins and complex queries, moving to a document-oriented database may require substantial data-model and application changes.

Other possible risks include:

Migration downtime.
Unexpected infrastructure costs.
Team learning curve.
Application compatibility issues.
Data consistency challenges.

The backend incorporates risk-related information into the readiness assessment according to the implemented scoring logic.

These findings should be treated as potential risks to investigate, not proof that a particular database is unsuitable.

6. Decision Stress Testing

A decision that appears reasonable today may become less suitable when its assumptions change.

DecisionShield includes a stress-testing concept to examine how hypothetical scenarios can affect the decision assessment.

Example scenarios include:

Scenario 1: Traffic increases by 10×

Would the proposed architecture continue to satisfy performance and availability requirements?

Scenario 2: Infrastructure budget decreases by 50%

Would the decision remain financially practical?

Scenario 3: New data residency requirements are introduced

Would the proposed solution meet the updated compliance constraints?

Scenario 4: The engineering team loses its existing database expertise

Would the team still be able to maintain and troubleshoot the system effectively?

Scenario 5: Data volume doubles

Would the current assumptions about storage, performance, and cost remain reasonable?

These scenarios allow users to explore how changing conditions could affect their decision.

📉 Understanding Decision Stability

Suppose a hypothetical decision has an initial readiness score of 72/100.

Stress testing might produce the following illustrative results:

Scenario	Readiness Score
Current conditions	72
Traffic increases 10×	68
Budget decreases by 50%	65
New compliance requirement	43
Team expertise changes	61

The large reduction under the new compliance scenario suggests that the decision may be sensitive to changing requirements.

The system can use such comparisons to highlight decision stability concerns.

A high initial score does not automatically mean a decision will remain suitable under every possible condition.

Note: These figures are illustrative examples, not measured benchmark results.

🧠 Why Gemma 4?

DecisionShield uses Gemma 4 E4B as its semantic reasoning layer rather than treating the model as a generic chatbot.

The model's role is to analyze unstructured decision context and help produce structured findings.

The process can be represented as:

Unstructured Decision Context
             |
             v
        Gemma 4 E4B
             |
             v
       Semantic Analysis
             |
      +------+------+------+
      |      |      |      |
      v      v      v      v
    Facts Assumptions Risks Unknowns
             |
             v
      Claims and Missing
           Evidence
             |
             v
       Structured Output

The backend then validates and processes the structured output to generate measurable decision metrics.

Separation of Responsibilities

Component	Responsibility
Gemma 4 E4B	Semantic reasoning and classification
Pydantic	Structured output validation
Python Decision Engine	Deterministic readiness scoring
FastAPI	Backend API and orchestration
React	User interface and visualization
User	Final decision and judgment

This division of responsibilities is important because language-model analysis and numerical calculations serve different purposes.

The model interprets context. The backend validates the data and performs the scoring. The human remains responsible for the final decision.

⚙️ Technical Architecture

DecisionShield uses a frontend-backend architecture with separate AI analysis and scoring responsibilities.

                 +----------------------+
                 |    React + Vite UI   |
                 |                      |
                 | Decision Workspace   |
                 | Dashboard            |
                 | Evidence Explorer    |
                 | Stress Testing       |
                 | Audit Report         |
                 +----------+-----------+
                            |
                         REST API
                            |
                            v
                 +----------------------+
                 |       FastAPI        |
                 |       Backend        |
                 +----------+-----------+
                            |
                 +----------+-----------+
                 |                      |
                 v                      v
       +------------------+  +-------------------+
       |   Gemma 4 E4B    |  | Decision Engine   |
       |                  |  |                   |
       | AI Reasoning     |  | Deterministic     |
       | Classification   |  | Scoring           |
       | Risk Discovery   |  | Stability Analysis|
       +--------+---------+  +---------+---------+
                |                      |
                +----------+-----------+
                           |
                           v
                 +----------------------+
                 | Structured Decision  |
                 | Analysis Result      |
                 +----------+-----------+
                            |
                            v
                 +----------------------+
                 |   Decision Audit     |
                 |       Report         |
                 +----------------------+

The frontend communicates with the backend through REST APIs.

The backend coordinates the analysis workflow, validates structured data, and calculates the readiness assessment.

The resulting analysis is presented through the user interface as a decision audit.

🛠️ Technology Stack

Frontend

React
Vite
Tailwind CSS
Recharts
Framer Motion

Backend

Python
FastAPI
Pydantic
Uvicorn

AI

Gemma 4 E4B
4-bit quantization
Local inference

Architecture

REST API.
Structured JSON.
Deterministic scoring engine.
In-memory decision storage for the MVP.
AI provider and demo-provider fallback workflow.

The technology choices support a modular architecture in which the user interface, AI analysis, validation, and scoring logic have distinct responsibilities.

💻 Running DecisionShield Locally

The following steps describe the setup documented for the project. Depending on your environment and model configuration, additional setup may be necessary.

Prerequisites

You will need:

Python 3.x.
Node.js and npm.
Git.
An NVIDIA GPU is recommended for local Gemma inference.
Approximately 16 GB of RAM.
Approximately 6 GB of VRAM for the target E4B 4-bit configuration.

Actual memory requirements depend on the model implementation, quantization format, runtime, and inference settings.

1. Clone the Repository

git clone https://github.com/Praveen-Raj-Thulasi/DecisionAI/
cd DecisionShield

Make sure the directory name matches the actual folder created by your clone operation.

2. Set Up the Backend

cd backend
python -m venv .venv

On Windows:

.venv\Scripts\activate

On Linux or macOS:

source .venv/bin/activate

Install the backend dependencies:

pip install -r requirements.txt

3. Configure the Environment

Create the environment configuration file using the supplied example:

cp .env.example .env

On Windows, you can copy the file using your preferred terminal or file explorer.

Configure the required settings, including the model path and other environment-specific values.

4. Start the Backend

uvicorn app.main:app --reload

Run the command from the backend directory.

5. Start the Frontend

Open another terminal:

cd frontend
npm install
npm run dev

Open the local address printed by Vite in your terminal.

For exact dependency requirements and configuration options, refer to the repository's README and environment example.

🧪 Demo Scenario: PostgreSQL vs MongoDB

For a simple demonstration, consider this decision:

Should our startup migrate from PostgreSQL to MongoDB?

The user provides context about current data volume, expected growth, team size, and operational constraints.

DecisionShield then follows the analysis workflow:

Decision Input
      |
      v
Facts
      |
      v
Assumptions
      |
      v
Unknowns
      |
      v
Risks
      |
      v
Missing Evidence
      |
      v
Readiness Assessment
      |
      v
Stress Testing
      |
      v
Decision Stability
      |
      v
Final Decision Audit

For example, the system might identify that the team expects rapid growth but has not supplied sufficient information about query workloads, transaction requirements, or long-term infrastructure costs.

Instead of assuming that a migration is necessary, the platform highlights what should be investigated.

That is the central idea behind DecisionShield: a decision should be evaluated using the available evidence and the risks that remain unresolved.

🔬 Example Analysis

Let's examine a sample decision context.

Input

Our startup currently has approximately 2 TB of PostgreSQL data.

We expect rapid growth and believe MongoDB will make scaling easier.

Our engineering team is small, and we want to reduce operational complexity.

Facts

PostgreSQL is the current database.
The data volume is approximately 2 TB.
The team expects significant growth.
The team wants to reduce operational complexity.

Assumptions

MongoDB will automatically improve scalability.
Migrating will reduce operational complexity.
The new database will be cheaper over the long term.

Unknowns

Query patterns.
Transaction requirements.
Consistency requirements.
Peak workload.
Migration downtime tolerance.

Potential Risks

Additional complexity for relational workloads.
Migration-related downtime.
Learning curve for the engineering team.
Unanticipated infrastructure costs.

Missing Evidence

Query workload analysis.
Transaction and consistency requirements.
Three-year cost comparison.
Expected peak traffic.
Migration and rollback strategy.

Illustrative Result

Decision Readiness: 64 / 100

Status: NOT READY

Recommended next step:
Investigate the critical missing evidence
before finalizing the migration decision.

The score and status above are examples used to explain the concept, not an independently verified assessment of an actual production decision.

The purpose of this analysis is not to claim that PostgreSQL or MongoDB is universally better. It is to identify the evidence needed to determine which option best fits the application's requirements.

🏗️ Project Structure

The documented project structure follows a frontend-backend separation.

DecisionShield/
|
+-- frontend/
|   +-- components/
|   +-- pages/
|   +-- services/
|   +-- ...
|
+-- backend/
|   +-- app/
|   |   +-- api/
|   |   +-- ai/
|   |   +-- engine/
|   |   +-- schemas/
|   |   +-- services/
|   |   +-- ...
|   |
|   +-- tests/
|   +-- requirements.txt
|
+-- docs/
|
+-- README.md

The frontend contains the interface and visualization components.

The backend separates API handling, AI integration, schemas, scoring logic, and supporting services. This structure helps keep the system modular and makes individual components easier to test and maintain.

🔐 Reliability by Design

One important design principle is the separation between AI-generated analysis and numerical decision logic.

We do not want the model to simply return an unsupported statement such as:

Gemma:
"I think the decision readiness is 87."

Instead, the intended workflow is:

Gemma
  |
  v
Facts / Assumptions / Risks / Unknowns
  |
  v
Structured JSON
  |
  v
Pydantic Validation
  |
  v
Python Decision Engine
  |
  v
Readiness Score

This makes it easier to validate the structure of the analysis, inspect the scoring process, and test the backend independently of the model.

However, deterministic calculations do not automatically guarantee that the final result is correct. The quality of the assessment still depends on the supplied evidence, the classification, and the scoring rules.

🧪 Demo Mode and AI Fallback

Local AI inference can introduce practical challenges during development and hackathons.

These may include:

Model loading failures.
GPU memory limitations.
CUDA or runtime configuration issues.
Inference errors.
Environment setup problems.

DecisionShield includes a fallback/demo-provider approach intended to keep the application demonstrable when local model inference is unavailable.

The documented flow is:

                AI Analysis
                     |
             +-------+-------+
             |               |
             v               v
          Gemma 4        Demo Provider
             |               |
             +-------+-------+
                     |
                     v
             Structured Output
                     |
                     v
             Decision Engine
                     |
                     v
             Audit Report

Both providers are designed to feed the same downstream processing workflow through a common structured-output format.

The application distinguishes whether an analysis comes from the actual AI provider or demo mode. This distinction matters because demonstration output should not be mistaken for a live model-generated analysis.

🌍 Why DecisionShield Could Matter

Making decisions is not only about collecting more information.

It is also about understanding the quality and limitations of the information we already have.

Before committing to a decision, it is useful to know:

Which facts support the decision?
Which assumptions still need testing?
What important information is missing?
Which risks could affect the outcome?
What would happen if the original constraints changed?

DecisionShield aims to turn these questions into a repeatable decision-review workflow.

Rather than presenting AI as the final authority, the platform treats it as a tool for examining the reasoning and evidence behind a decision.

The objective is simple:

AI should help people make better-informed decisions, not encourage them to follow recommendations blindly.

🚀 Future Roadmap

DecisionShield is an MVP, and several enhancements could make the platform more useful.

📄 1. Evidence Ingestion

Allow users to upload documents, PDFs, spreadsheets, and reports.

The system could extract relevant information and use it as supporting evidence for a decision assessment.

🔗 2. Evidence Provenance

Track where each fact originated.

For example:

Fact
 |
 v
Source Document
 |
 v
Page or Section
 |
 v
Supporting Evidence

This would help users inspect the source behind important findings rather than relying only on generated summaries.

🧠 3. Advanced Decision Graphs

Represent relationships between evidence, assumptions, risks, requirements, and decisions.

Evidence
   |
   v
Assumption
   |
   v
Risk
   |
   v
Requirement
   |
   v
Decision

A decision graph could make it easier to understand how one unresolved assumption affects multiple parts of an assessment.

👥 4. Collaborative Decision Rooms

Allow teams to evaluate decisions together, contribute evidence, discuss risks, and compare assessments.

📚 5. Decision History

Maintain a history of decisions and their assessments so users can understand how a decision changes as new evidence becomes available.

🌐 6. External Knowledge Verification

Integrate trusted external sources to help users investigate missing evidence and verify important claims.

🧪 7. Advanced Stress Testing

Expand scenario analysis to explore more complex constraints and evaluate how sensitive a decision is to changes in assumptions.

🏢 8. Domain-Specific Audits

Introduce specialized decision templates for areas such as:

Software architecture.
Cloud infrastructure.
Procurement.
Hiring.
Business strategy.
Product planning.

These are potential future improvements, not claims that all these capabilities are already implemented.

⚠️ Limitations

DecisionShield is intended to support decision-making, not guarantee a correct outcome.

There are several limitations to consider:

AI-generated classifications may be imperfect.
Missing-evidence suggestions may not cover every important factor.
Results depend on the quality and completeness of the supplied context.
Stress-test scenarios are hypothetical analyses, not predictions of future events.
A readiness score is an analytical indicator, not an objective measure of truth.
A deterministic scoring engine can still produce misleading results if its inputs or scoring rules are inadequate.

For high-impact decisions, users should verify important claims, consult appropriate experts, and use independent evidence before acting.

🌱 Open Source and Community Contributions

DecisionShield is being developed as an open-source project.

We want the project to provide an opportunity to explore ideas around:

Local AI inference.
Gemma-based reasoning.
Structured AI outputs.
Deterministic scoring.
Decision intelligence.
Human-in-the-loop systems.

Developers interested in the project can explore the source code, share feedback, suggest improvements, and contribute to future development.

Repository: https://github.com/Praveen-Raj-Thulasi/DecisionAI

Please refer to the repository for available contribution instructions and current project issues.

👥 Our Team

Team Name: Wakie Wakie

Team Members & Contributions

Member	Contribution
Naveensri V	Full-stack development, AI integration, and system architecture
Prithivi Raj T J	Frontend development, UI/UX, and dashboard implementation
Praveen Raj Thulasi S	Backend development, decision engine, and API integration
Gopika B	AI prompting, testing, documentation, and presentation

DecisionShield was developed collaboratively during the Hacktoberfest Hack Day Coimbatore.

Working together gave us an opportunity to discuss the problem, explore technical approaches, integrate components, and learn from the challenges of building an AI-powered application.

Teamwork was an important part of the experience, and the project reflects our shared effort to explore a different approach to AI-assisted decision-making.

🏆 Hackathon Experience

Event: Hacktoberfest Hack Day Coimbatore

Organizers: INIT Club & IDEA Club

Additional Challenge: Gemma 4

Building DecisionShield during an in-person hackathon was a valuable learning experience.

Hackathons bring a different kind of challenge. There is limited time to understand a problem, design a solution, implement the main workflow, and bring different components together.

This project encouraged us to think beyond generating AI responses and focus on how AI reasoning could be combined with structured validation and deterministic logic.

It was also an opportunity to collaborate with teammates, exchange ideas, solve problems, and learn through implementation.

I'm grateful to my teammates and everyone involved in organizing the event for making this experience possible.

🎥 Project Demo

Watch the project demonstration:

DecisionShield — Demo Video

The demonstration introduces the main decision-review workflow:

Create a Decision
       |
       v
AI Analysis
       |
       v
Evidence Classification
       |
       v
Readiness Assessment
       |
       v
Missing Evidence
       |
       v
Stress Testing
       |
       v
Decision Stability
       |
       v
Decision Audit

For the full source code, visit the GitHub repository.

🙌 Final Thoughts

The most interesting part of building DecisionShield was not simply getting an AI model to generate an answer.

It was exploring a different question:

What if the most useful thing AI could tell us wasn't what to choose, but what we were missing before we chose?

That question is at the heart of DecisionShield.

Instead of asking only:

"What should I choose?"

We can also ask:

"Do I have enough evidence to make this decision?"

And if the answer is no, we should understand what information is missing, which assumptions need verification, and what risks deserve attention.

Building this project with Team Wakie Wakie at Hacktoberfest Hack Day Coimbatore was a meaningful step in learning, collaborating, and experimenting with open-source AI.

We look forward to learning more, improving the project, and exploring how AI can support more transparent and evidence-based decisions.

Built with ❤️ using open-source AI and Gemma 4.

What do you think AI's role in decision-making should be: recommending an answer, or helping us understand whether we're ready to make the decision?

I'd love to hear your thoughts in the comments!

OUTCURIO

Gopika — Sun, 11 Oct 2026 05:11:31 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

OUTCURIO is an AI-powered real-world curiosity companion designed to help people spend less time scrolling and more time exploring the world around them.

We often pick up our phones whenever we feel bored. A quick check turns into endless scrolling, and we miss the interesting things happening around us.

I wanted to explore a different idea: What if AI didn't try to keep us on our screens, but actually encouraged us to put them down?

That's the idea behind OUTCURIO.

Instead of providing endless digital content, OUTCURIO turns a user's surroundings, interests, and curiosity into small real-world experiences.
🌎 How it works

Snap My World 📸

Users take or upload a photo of their surroundings, such as a room, desk, classroom, or park. The vision-AI workflow is designed to understand the scene and use visible objects and spatial relationships to inspire a relevant activity.

Give Me Something ✨

Users choose their available time, mood, and preferred activity. OUTCURIO generates a real-world challenge suited to their preferences.

Surprise Me 🎲

Users can discover an unexpected activity instead of deciding what to do themselves.

Put Your Phone Down 🌱

OUTCURIO encourages users to step away from the screen, observe their surroundings, solve a small challenge, draw something, make a prediction, or explore something new.

Return, Reflect, and Discover 🔍

Users return to record their observations, answers, or evidence. The experience history and personalization features are designed to make future activities more relevant.

Who is it for?

OUTCURIO is for students, curious minds, people who get bored easily, and anyone who wants to turn idle moments into opportunities for discovery.

The goal isn't to eliminate technology. It's to use technology intentionally, so that more of life happens beyond the screen.

Our philosophy: AI should help you experience the world, not replace experiencing it.

Demo

outcurio-ghxu7gq5t-gopika6.vercel.app

Code

https://github.com/Gopika252006/OUTCURIO

How I Built It

OUTCURIO combines a conventional full-stack application with an open-weight AI integration.

Technology stack

Backend: Java 21, Spring Boot 3, Maven

Frontend: React, TypeScript, Vite

Database: SQLite with Spring Data JPA and Hibernate

Authentication: Spring Security, JWT, and BCrypt

AI inference: Ollama with configurable text and vision models

Communication: REST APIs between the frontend and backend

Architecture

The frontend provides the user experience, while the Spring Boot backend manages authentication, profiles, experience generation, persistence, and submissions.

The AI integration is designed around a provider abstraction, allowing local models to be configured without scattering model-specific logic throughout the application.

For Snap My World, the intended workflow is:

Photo → Vision analysis → Scene understanding → Experience generation → Validation → Real-world activity

The experience lifecycle then continues:

Activity → User response → Evaluation → History → Personalization

A fallback experience mechanism is intended to keep basic activities available when local AI inference is unavailable. AI-generated results and fallback results should be distinguished clearly.

The application also emphasizes safe activities, varied challenges, and a screen-off interaction model rather than an endless feed.

Why Does Open Innovation Matter?

Open innovation makes OUTCURIO possible in a way that goes beyond simply connecting an application to an AI API.

Using open-weight models through local inference offers several advantages:

More control: Developers can choose and configure models for text generation and vision tasks.

Local-first potential: Core experiences and local data can remain on the user's device or local machine, depending on deployment.

Privacy-conscious design: Photos of personal surroundings can be processed locally when the selected model and configuration support it.

Experimentation: Developers can modify prompts, validation rules, and model choices without depending entirely on a closed API.

Accessibility: A local inference path can reduce dependence on paid, usage-limited cloud services, although hardware requirements still apply.

Most importantly, open innovation supports the philosophy behind OUTCURIO: technology should empower people to experiment, build, and engage with the real world.

I want OUTCURIO to demonstrate that AI can be useful without demanding constant attention.

The screen is the starting point, not the destination.

Prize Categories

SkillPilot: An AI That Learns How You Learn

Gopika — Sun, 04 Oct 2026 17:41:34 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built SkillPilot — Your AI-powered personal learning intelligence, a personalized learning system designed for a friend who is already serious about becoming a better developer.

My friend solves coding problems regularly, studies technical concepts, explores new technologies, and prepares for technical interviews. The problem was not a lack of learning resources. The problem was that his learning journey was scattered across coding platforms, notes, PDFs, screenshots, documentation, AI conversations, and different practice sessions.

SkillPilot brings these activities into one personal learning intelligence system.

Instead of behaving like a generic AI tutor, SkillPilot builds an evolving understanding of the user's technical journey.

It connects:

Coding practice and AI code analysis
Personal Technical Memory
Knowledge Vault for notes, documents, screenshots, formulas and code
Context-aware AI conversations
Adaptive weekly planning
Technical assessments
Timed aptitude practice
Adaptive interview practice
Career skill-gap analysis

The core idea is simple:

Learn → Practice → Analyze → Remember → Adapt → Improve

As the user practices, makes mistakes, completes assessments, and improves, SkillPilot uses that evidence to adapt future questions, revision priorities, assignments, and weekly plans.

Demo

Deployed Link: https://skillpilot-alpha.vercel.app/

Code

GitHub Repository: https://github.com/Gopika252006/skillpilot

How I Built It

SkillPilot is built around open-weight AI and local inference.

Tech Stack

Frontend

React
Vite
Tailwind CSS
Framer Motion
Recharts

Backend

Python
FastAPI
Pydantic
SQLAlchemy
SQLite

Ollama
Open-weight local models
AI orchestration layer
Structured AI outputs with validation
Deterministic fallback when the local model is unavailable

Architecture

The application follows a layered architecture:

React UI → FastAPI API → Service Layer → Database / AI Orchestrator

For AI-powered features:

User Context → Knowledge Memory → Context Builder → AI Orchestrator → Local Model → Structured Output → Validation → Database / UI

SkillPilot maintains a distinction between:

Knowledge Vault — information the user has saved.

and

Personal Technical Memory — evidence about what the user has actually practiced, understood, struggled with, or needs to revise.

This distinction is important because saving a PDF should not automatically mean that the user understands its contents.

Why Does Open Innovation Matter?

Open innovation matters because a personal learning system should not require sending someone's entire learning history to a closed AI service.

SkillPilot explores a different approach:

local AI + open-weight models + user-controlled data

Using local inference makes it possible to build a system where:

Personal learning context can remain local
Users have more control over their data
The AI model can be changed without rebuilding the entire application
The system can work without depending entirely on a proprietary API
Developers can inspect and modify the AI pipeline
The application can evolve with different open-weight models
AI costs can be reduced during development and experimentation

The open approach also gives developers more control over the complete AI pipeline — from context construction and prompting to validation, fallback behavior, and persistence.

For SkillPilot, this is especially important because the system is designed to understand a user's long-term technical journey.

The goal is not simply:

"Ask an AI a question."

The goal is:

"Build an AI system that learns from the user's learning evidence while keeping the user in control."

Prize Categories

RENDER

I Built AgentVerse: An Agentic Analytics Platform Using AI Agents and MCP

Gopika — Fri, 02 Oct 2026 14:19:37 +0000

What if you could ask your analytics dashboard a simple question:

"Why did sales decrease last month?"

Instead of manually filtering charts, exploring datasets, and writing database queries, imagine a system that could understand your question, generate a query, validate it, analyze the results, and present the findings with a visualization.

That idea inspired me to build AgentVerse, an agentic analytics platform that combines AI agents, MongoDB, and the Model Context Protocol (MCP).

I built this project to explore how AI agents can make data analysis more interactive and how we can build systems that are not only intelligent but also easier to control, debug, and understand.

Here are some of the things I explored while building it.

🚀 What is AgentVerse?

AgentVerse is a natural-language analytics platform designed to let users explore data by asking questions in plain English.

For example, instead of writing a MongoDB query, a user could ask:

Show monthly sales for the last 12 months.
Show the top 5 products by revenue.
Compare sales across different regions.
Why did sales decrease last month?

The platform translates these questions into an analytics workflow.

At a high level, the workflow looks like this:

User Question
      ↓
Orchestrator Agent
      ↓
Analytics Query Agent
      ↓
Query Guardian
      ↓
MCP Server
      ↓
MongoDB
      ↓
Evidence Engine
      ↓
Insight Agent
      ↓
Visualization

The goal is not just to generate an answer. It is to make the process behind that answer more structured and observable.

Figure 1: AgentVerse architecture — showing how AI agents, Query Guardian, MCP, and MongoDB work together to transform natural-language questions into evidence-based insights.

🧠 Why use multiple agents?

A simple approach to building an AI analytics application might look like this:

User → LLM → Database → Answer

But this approach combines several responsibilities into one step. The system needs to understand the question, identify the relevant fields, generate a query, interpret the results, and decide how to present the answer.

For AgentVerse, I explored separating these responsibilities into specialized components.

Orchestrator Agent: Understands the request and coordinates the workflow.
Analytics Query Agent: Generates MongoDB aggregation pipelines.
Query Guardian: Validates queries before execution.
Evidence Engine: Performs deterministic calculations on query results.
Insight Agent: Turns the available evidence into a natural-language explanation.
Visualization: Selects an appropriate chart or other visual representation.

This separation makes each part easier to inspect and helps establish clearer boundaries between AI-generated decisions and normal application logic.

One important lesson: adding more agents does not automatically make a system better. Each component needs a clear purpose.

🔌 MCP: Connecting AI Agents to Data

One of the concepts I explored in this project was Model Context Protocol (MCP).

I wanted a structured way for the AI workflow to interact with database capabilities without giving the model unrestricted access to MongoDB.

Instead of connecting the agent directly to the database, the architecture uses an MCP server as an intermediary:

AI Agent
   ↓
MCP Server
   ├── get_schema
   └── execute_query
           ↓
        MongoDB

The get_schema tool helps the workflow discover the available data structure, while execute_query provides a controlled way to request query execution.

This separates two important responsibilities:

AI reasoning: Understanding the question and proposing a query.
Data access: Validating and executing database operations through application-controlled tools.

For me, this was one of the most interesting architectural aspects of the project. MCP is not just about connecting an AI model to tools; it also provides a structured interface between the model and external capabilities.

🛡️ The challenge: Can we trust AI-generated queries?

Generating a MongoDB aggregation pipeline is only one part of the problem.

The next question is: Should we execute whatever the LLM generates?

No. A generated query can contain invalid fields, unsupported operators, or operations that are inappropriate for an analytics application.

To address this, I implemented a component called Query Guardian.

Its responsibility is to validate generated queries before they reach the database.

The validation process checks things such as:

Allowed aggregation stages and operators
Collection and field names
Pipeline structure and length
Result limits
Forbidden operations

The analytics workflow is designed around read-only query execution rather than allowing the AI to modify stored data.

The general flow is:

LLM Generates Query
        ↓
   Query Guardian
        ↓
     Validation
        ↓
    ┌───┴────┐
    ↓        ↓
  Valid    Invalid
    ↓        ↓
 Execute   Repair or
           Reject

Invalid queries can go through a controlled repair and re-validation process.

This taught me an important lesson:

LLM output should be treated as untrusted input, not executable truth.

The model can propose an action, but application code should enforce the rules governing whether that action is allowed.

📊 From a question to an insight

Let's consider the question:

"Why did sales decrease last month?"

Here is how the workflow is designed to handle it.

1. Understand the question

The Orchestrator identifies the request as a root-cause analysis task.

2. Discover the schema

The workflow retrieves the relevant database structure through MCP.

3. Generate the query

The Analytics Query Agent creates a MongoDB aggregation pipeline to retrieve the required data.

4. Validate and execute

Query Guardian checks the pipeline before the MCP execution tool sends the permitted operation to MongoDB.

5. Analyze the evidence

The Evidence Engine calculates measurable changes in the returned data, such as differences between periods or across regions and product categories.

6. Generate an explanation

The Insight Agent uses the available evidence to produce a natural-language explanation.

There is an important distinction here: identifying a region with declining sales does not automatically prove that the region caused the overall decline.

The system should distinguish observed changes from possible explanations instead of presenting unsupported causal claims as facts.

That distinction matters whenever AI is used for data analysis.

📈 Turning insights into visualizations

An analytics response should be more than a paragraph of text.

AgentVerse uses a React frontend with Recharts to present analytical results visually.

Depending on the data and the analytical task, suitable visualizations might include:

Analytical task	Possible visualization
Sales trends over time	Line chart
Comparing regions	Bar chart
Showing category proportions	Pie chart
Displaying a single metric	KPI card

The overall flow is:

Question
   ↓
Query
   ↓
Data
   ↓
Evidence
   ↓
Insight
   ↓
Visualization

The aim is to help users understand both the result and the information supporting it.

🔍 Making the workflow observable

Another thing I wanted to explore was how to debug an application where several AI-related steps happen before the final response.

If the system returns an incorrect result, inspecting only the final answer may not tell us where the problem occurred.

Was the intent misunderstood? Was the query incorrect? Did validation reject something? Did the database return unexpected data? Was the explanation inconsistent with the evidence?

AgentVerse includes an execution-trace interface that helps expose the stages of the analytics workflow.

The backend also includes audit logging for information such as the request, generated pipeline, validation status, returned row count, and execution duration.

Together, these features help make the workflow easier to inspect and debug.

🧰 Tech stack

Here is the technology stack I used for AgentVerse.

Frontend

React
TypeScript
Vite
Tailwind CSS
Recharts
Axios

Backend

Node.js
Express
TypeScript
MongoDB
Mongoose

AI and tools

Ollama
LLM-based agents
Model Context Protocol (MCP)
Structured JSON generation
Multi-agent orchestration

I used Ollama to work with a locally hosted language model. The model and Ollama endpoint can be configured through environment variables, which is useful when experimenting with different local setups.

💡 What I learned

Building AgentVerse helped me explore several practical challenges in agentic AI development.

1. Not everything needs an LLM.

Query validation, result limits, percentage calculations, and other deterministic operations are better handled by application code.

2. Generated output needs validation.

A query that looks correct is not necessarily safe or valid. The application needs independent checks before execution.

3. More agents mean more complexity.

Each additional component introduces communication, debugging, and failure-handling requirements. Agents should have clear responsibilities.

4. Observability matters.

Execution traces and audit logs make it easier to investigate what happened between the user's question and the final answer.

5. Evidence matters more than a fluent explanation.

An answer can sound convincing without being correct. Analytical explanations should be grounded in actual query results and distinguish evidence from assumptions.

These are areas I will continue exploring as I improve the project.

🚧 What's next?

There are several areas I would like to develop further:

Supporting additional data sources
Expanding MCP tool capabilities
Improving query validation and error handling
Evaluating the accuracy of generated queries and insights
Exploring streaming responses
Improving anomaly detection
Strengthening observability
Exploring deployment options

One question I particularly want to investigate is:

How can we reliably evaluate an agentic analytics system?

A fluent response is not necessarily an accurate response. Measuring the correctness of the query, the quality of the evidence, and the reliability of the final explanation is an important part of building a useful system.

🎯 Final thoughts

Working on AgentVerse has encouraged me to think beyond simply choosing an LLM and writing a prompt.

I now pay more attention to the architecture surrounding the model: the tools it can access, the validation rules it must follow, the evidence used to generate answers, and the mechanisms that help us understand failures.

LLM
 ↓
Tools
 ↓
Validation
 ↓
Data
 ↓
Evidence
 ↓
Insights
 ↓
Observability

For me, that is an important part of building agentic applications: combining the flexibility of AI with the reliability of well-designed software.

AgentVerse is an ongoing project, and I look forward to exploring these ideas further.

If you've worked with AI agents or MCP, what has been the most challenging part for you: orchestration, tool integration, security, or evaluation?

I'd love to hear your thoughts!

Tech stack: React · TypeScript · Node.js · Express · MongoDB · Ollama · MCP · Recharts

AI #AgenticAI #MCP #LLM #MongoDB #React #TypeScript