Don't ask AI what to choose. Ask AI if you're ready to choose.
We use AI every day to make decisions.
Which technology should we use?
Should we migrate our database?
Which cloud platform should we choose?
Which vendor is better?
Should we build or buy?
The problem is that AI assistants are often very good at giving us an answer β even when the information behind the decision is incomplete.
That led us to a different question:
What if AI didn't immediately tell us what to choose, but first checked whether we actually had enough evidence to make the decision?
That's the idea behind DecisionShield.
π Project Links
| Resource | Link |
|---|---|
| π» GitHub Repository | https://github.com/Praveen-Raj-Thulasi/DecisionAI |
| π₯ Demo Video | https://drive.google.com/file/d/1WADhxrbvxrPhcrXLVeSE0215SyG1gwe5/view?usp=sharing |
π€ The Problem
Imagine asking an AI:
"Should our startup migrate from PostgreSQL to MongoDB?"
A conventional AI assistant might respond:
"MongoDB could be a better choice because it provides flexibility and horizontal scalability."
Sounds convincing.
But what if we don't know:
- What our query patterns look like?
- How many transactions require strong consistency?
- Whether complex joins are important?
- What the migration downtime tolerance is?
- What the three-year cost looks like?
- Whether our team has the required expertise?
The AI may have given us a reasonable answer.
But we still weren't ready to make the decision.
This is the problem DecisionShield tries to solve.
π‘ The Idea
DecisionShield is an AI-powered Decision Readiness & Risk Audit Platform.
Instead of immediately recommending an option, DecisionShield analyzes the decision itself.
It separates the information into:
- β Facts
- β οΈ Assumptions
- β Unknowns
- π Claims
- π¨ Risks
- π Missing Evidence
- π§ͺ Stress-Test Scenarios
Then a deterministic decision engine calculates a Decision Readiness Score.
The result isn't simply:
"Choose Option A."
Instead, it might say:
Decision Readiness: 64/100 β NOT READY
Three critical pieces of evidence are missing before this decision should be finalized.
That's a very different approach to AI-assisted decision making.
π How DecisionShield Works
The complete workflow is:
USER DECISION
β
βΌ
Decision Context
β
βΌ
βββββββββββββββ
β Gemma 4 β
β Reasoning β
ββββββββ¬βββββββ
β
βΌ
Structured AI Analysis
β
ββββββββββββββΌβββββββββββββ
βΌ βΌ βΌ
Facts Assumptions Risks
β β β
ββββββββββββββΌβββββββββββββ
β
βΌ
Missing Evidence
β
βΌ
Deterministic Scoring
β
βΌ
Decision Readiness Score
β
βΌ
Stress Testing
β
βΌ
Decision Stability
β
βΌ
Decision Audit
π§ Why Not Just Build Another AI Chatbot?
This was one of the most important design decisions behind the project.
A traditional AI assistant looks like:
User Question
β
LLM
β
Text Recommendation
DecisionShield looks like:
Decision
β
Evidence Extraction
β
Classification
β
Risk Analysis
β
Missing Evidence
β
Deterministic Scoring
β
Stress Testing
β
Decision Audit
The goal isn't to replace the human decision maker.
The goal is to improve the quality of the reasoning and evidence available to the human decision maker.
π§© Core Features
1. Decision Workspace
The user starts by describing the decision.
They can provide:
- Decision title
- Decision description
- Options
- Context
- Requirements
- Constraints
- Existing evidence
For example:
Decision:
Should our startup migrate from PostgreSQL to MongoDB?
Options:
β’ Stay with PostgreSQL
β’ Migrate to MongoDB
Context:
Our startup currently has approximately 2 TB of data
and expects significant growth over the next three years.
Constraints:
β’ Small engineering team
β’ Limited migration budget
2. AI Evidence Analysis
Gemma analyzes the decision context and separates information into different categories.
Facts
Information directly supported by the provided context.
β Current database is PostgreSQL
β Current data volume is approximately 2 TB
β Engineering team is small
Assumptions
Statements that may be true but aren't sufficiently supported.
β MongoDB will automatically solve scalability problems.
β Migration will reduce operational complexity.
Unknowns
Important information that wasn't provided.
? Query workload patterns
? Transaction requirements
? Data consistency requirements
? Peak traffic
Claims
Statements that require verification.
? "MongoDB will be cheaper over three years."
This classification becomes the foundation of the rest of the analysis.
3. Decision Readiness Score
DecisionShield calculates a score from 0β100.
The score considers multiple dimensions such as:
Evidence Quality
Requirement Coverage
Evidence Completeness
Risk Coverage
Assumption Load
Unknown Information
Decision Stability
The important architectural decision here is:
Gemma does not generate the final score.
Instead:
Gemma
β
Semantic Analysis
β
Structured JSON
β
Pydantic Validation
β
Python Decision Engine
β
Readiness Score
This makes the scoring process deterministic and reproducible.
Example:
DECISION READINESS
64
/100
βββββββββββββββββββββββββββββ
β NOT READY β
βββββββββββββββββββββββββββββ
Evidence Quality 72%
Requirements 80%
Risk Coverage 55%
Evidence Completeness 61%
Decision Stability 68%
4. Missing Evidence Detection
One of the most important features is asking:
"What information are we missing that could materially change this decision?"
For the PostgreSQL vs MongoDB example, DecisionShield might identify:
π΄ CRITICAL
1. Query workload analysis
2. Transaction requirements
3. Data consistency requirements
π HIGH
4. Migration downtime tolerance
5. Three-year infrastructure cost
But it doesn't stop there.
For each missing piece of information, the system generates a verification action.
For example:
Missing Evidence:
Expected peak traffic
Verification Action:
Estimate current peak requests per second and project
expected traffic over the next three years.
This converts AI analysis into an actionable workflow.
5. Risk Analysis
DecisionShield identifies risks associated with the decision.
Each risk can include:
- Severity
- Likelihood
- Impact
- Confidence
- Supporting evidence
Example:
π¨ HIGH RISK
Complex relational workloads
MongoDB may introduce additional complexity
if the application's workload depends heavily
on complex relational queries and joins.
The backend then incorporates risk information into the deterministic readiness calculation.
6. Decision Stress Testing
A decision shouldn't only be evaluated under today's conditions.
So DecisionShield allows users to ask:
"What happens if the assumptions change?"
Example scenarios:
Scenario 1
Traffic increases 10Γ.
Scenario 2
The infrastructure budget decreases by 50%.
Scenario 3
Strict data residency becomes mandatory.
Scenario 4
The engineering team loses its existing database expertise.
Scenario 5
Data volume doubles.
The system analyzes how these scenarios affect the decision.
π Decision Stability
Suppose the current readiness score is:
72 / 100
Stress testing might produce:
Current Decision 72
10Γ Traffic 68
50% Budget 65
New Compliance 43
Team Expertise Loss 61
The system can then identify:
β οΈ Decision Stability: LOW
because one plausible change significantly alters the decision's readiness.
This is important because a decision can have a high current score but still be fragile.
π§ Why Gemma 4?
Gemma is not being used as a generic chatbot inside DecisionShield.
It is used as the semantic reasoning layer.
Gemma performs tasks such as:
Unstructured Decision Context
β
Gemma 4 E4B
β
Semantic Analysis
β
ββββββββββββΌβββββββββββ
βΌ βΌ βΌ
Facts Assumptions Risks
βΌ βΌ βΌ
Unknowns Claims Missing Evidence
The backend then converts this structured analysis into measurable decision metrics.
Separation of responsibilities
| Component | Responsibility |
|---|---|
| Gemma 4 | Semantic reasoning |
| Pydantic | AI output validation |
| Python Decision Engine | Deterministic scoring |
| FastAPI | Backend orchestration |
| React | Visualization |
| User | Final decision |
This separation was intentional.
βοΈ Technical Architecture
βββββββββββββββββββββββ
β React + Vite UI β
β β
β Decision Workspace β
β Dashboard β
β Evidence Explorer β
β Stress Testing β
β Audit Report β
ββββββββββββ¬βββββββββββ
β
REST API
β
βΌ
βββββββββββββββββββββββ
β FastAPI β
β Backend β
ββββββββββββ¬βββββββββββ
β
βββββββββββββββββ΄βββββββββββββββ
β β
βΌ βΌ
ββββββββββββββββββββ ββββββββββββββββββββ
β Gemma 4 E4B β β Decision Engine β
β β β β
β AI Reasoning β β Deterministic β
β Classification β β Scoring β
β Risk Discovery β β Stability β
ββββββββββ¬ββββββββββ ββββββββββ¬ββββββββββ
β β
ββββββββββββββββ¬ββββββββββββββββ
βΌ
ββββββββββββββββββββ
β Decision Analysisβ
β Structured β
β Result β
ββββββββββ¬ββββββββββ
β
βΌ
ββββββββββββββββββββ
β Decision Audit β
β Report β
ββββββββββββββββββββ
π οΈ Tech 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 store for the MVP
π» Running Locally
Prerequisites
You will need:
- Python 3.x
- Node.js
- npm
- NVIDIA GPU recommended for local Gemma inference
- Approximately 16 GB RAM
- Approximately 6 GB VRAM for the target E4B Q4 setup
Clone the Repository
git clone https://github.com/Praveen-Raj-Thulasi/DecisionAI/
cd DecisionShield
Backend
cd backend
python -m venv .venv
Windows
.venv\Scripts\activate
Linux/macOS
source .venv/bin/activate
Install dependencies:
pip install -r requirements.txt
Create environment configuration:
cp .env.example .env
Configure the Gemma model path and other required settings.
Start the backend:
uvicorn app.main:app --reload
π¨ Frontend
cd frontend
npm install
npm run dev
π§ͺ Demo Scenario
For the first demonstration, we use:
Should our startup migrate from PostgreSQL to MongoDB?
The system begins with a simple decision.
It then progressively reveals why the decision isn't as straightforward as it initially appears.
Decision
β
Facts
β
Assumptions
β
Unknowns
β
Risks
β
Missing Evidence
β
Readiness
β
Stress Test
β
Decision Stability
This demonstrates the central philosophy of DecisionShield:
A confident decision isn't necessarily a well-supported decision.
π¬ Example Analysis
Input
Our startup has 2 TB of PostgreSQL data.
We expect rapid growth and believe MongoDB
will make scaling easier.
Our team is small and we want to reduce
operational complexity.
DecisionShield might identify:
Facts
β PostgreSQL is currently used
β Data volume is approximately 2 TB
β Team size is limited
β Growth is expected
Assumptions
β MongoDB will automatically improve scalability
β MongoDB will reduce operational complexity
Unknowns
? Query patterns
? Transaction requirements
? Consistency requirements
? Peak workload
? Migration downtime
Risks
π¨ Complex relational queries
π¨ Migration downtime
π¨ Learning curve
Missing Evidence
π Query workload analysis
π Transaction requirements
π Three-year cost comparison
Result
Decision Readiness
64 / 100
β NOT READY
Instead of blindly recommending a database, DecisionShield tells the user what they should investigate first.
ποΈ Project Structure
DecisionShield/
β
βββ frontend/
β βββ components/
β βββ pages/
β βββ services/
β βββ ...
β
βββ backend/
β βββ app/
β β βββ api/
β β βββ ai/
β β βββ engine/
β β βββ schemas/
β β βββ services/
β β βββ ...
β β
β βββ tests/
β βββ requirements.txt
β
βββ docs/
β
βββ README.md
βββ ...
π Reliability by Design
A major design principle of DecisionShield is separating AI reasoning from numerical decision logic.
We don't want:
Gemma:
"I think the decision readiness is 87."
Instead:
Gemma
β
Facts / Assumptions / Risks / Unknowns
β
Validated JSON
β
Python Decision Engine
β
Readiness Score
This provides a more reproducible scoring process and makes the system easier to inspect and debug.
π§ͺ Demo Mode
Local AI models can sometimes introduce practical problems during a hackathon:
- model loading
- VRAM limitations
- CUDA issues
- inference failures
- environment configuration
To keep the application demonstrable, DecisionShield includes a fallback/demo provider.
AI Analysis
β
ββββββββββ΄βββββββββ
β β
Gemma 4 Demo Provider
β β
ββββββββββ¬βββββββββ
βΌ
Same JSON Schema
βΌ
Same Decision Engine
This means the rest of the application doesn't depend on whether the local model happens to load successfully during a demonstration.
The application clearly identifies whether the result came from Gemma or demo mode.
π Why This Could Matter
Decision making isn't only about having more information.
It's about knowing:
- which information is reliable
- which assumptions are untested
- which information is missing
- which risks matter
- which scenarios could invalidate the decision
DecisionShield tries to turn those questions into a repeatable workflow.
The goal is not:
AI makes the decision.
The goal is:
AI helps humans understand whether their decision is ready to be made.
π Future Roadmap
DecisionShield is currently an MVP.
Possible future improvements include:
π Evidence Ingestion
Upload:
- PDFs
- documents
- spreadsheets
- reports
and automatically extract evidence.
π Evidence Provenance
Track where every fact came from.
Fact
β
Source
β
Document
β
Page / Section
π§ Advanced Decision Graphs
Represent relationships between:
Evidence
β
Assumption
β
Risk
β
Requirement
β
Decision
π₯ Collaborative Decision Rooms
Allow teams to collaboratively audit a decision.
π Decision History
Track how decisions change over time.
π External Knowledge
Use trusted external sources to verify missing evidence.
π§ͺ Advanced Simulations
Introduce more sophisticated scenario and sensitivity analysis.
π’ Domain-Specific Audits
Create specialized templates for:
- software architecture
- business decisions
- procurement
- hiring
- cloud infrastructure
- product strategy
β οΈ Limitations
DecisionShield is a decision-support system.
It does not guarantee that a decision is correct.
AI-generated classifications may be imperfect.
Missing evidence suggestions may not be exhaustive.
Stress tests are scenarios, not predictions.
The Decision Readiness Score is an analytical indicator, not an objective measure of truth.
For high-stakes decisions, users should consult qualified professionals and verify important evidence independently.
π± Open Source
DecisionShield is being developed as an open-source project.
The goal is to make the architecture transparent and allow developers to experiment with:
- local AI
- Gemma
- structured reasoning
- deterministic scoring
- decision intelligence
- human-in-the-loop systems
Contributions
Contributions, ideas, issues and improvements are welcome.
Repository:
[ADD GITHUB REPOSITORY URL]
Issues:
[ADD GITHUB ISSUES URL]
Pull Requests:
[ADD CONTRIBUTION GUIDELINES / PR URL]
π₯ Team
Team Name
[ADD TEAM NAME]
Members
- [NAME] β [ROLE]
- [NAME] β [ROLE]
- [NAME] β [ROLE]
- [NAME] β [ROLE]
Responsibilities
| Member | Contribution |
|---|---|
| [NAME] | AI / Gemma Integration |
| [NAME] | Backend / FastAPI |
| [NAME] | Frontend / UI |
| [NAME] | Architecture / Testing |
π Hackathon
Built for:
Hacktoberfest Hack Day Coimbatore x (INIT Club & IDEA Club)
Additional Challenge:
Gemme 4
π₯ Demo
Watch the complete DecisionShield demonstration:
The demo covers:
Create Decision
β
AI Analysis
β
Evidence Classification
β
Readiness Score
β
Missing Evidence
β
Stress Testing
β
Decision Stability
β
Final Audit
π Links
GitHub
https://github.com/Praveen-Raj-Thulasi/DecisionAI
Demo Video
https://drive.google.com/file/d/1WADhxrbvxrPhcrXLVeSE0215SyG1gwe5/view?usp=sharing
Presentation
Team
Wakie Wakie
π Final Thoughts
The most interesting part of building DecisionShield wasn't getting an AI model to generate a recommendation.
It was asking a different question:
What if the most useful thing AI can tell us isn't what to choose β but what we're missing before we choose?
That idea became DecisionShield.
Instead of:
"What should I choose?"
we ask:
"Do I have enough evidence to choose?"
And if the answer is no, the system tells us why.

Top comments (0)