Engineering
Building Shiv
Engineering an Intelligence Layer for Student Performance
Engineering Case Study • AI Infrastructure • Student Intelligence
Built while developing Learnzy.
| Project Type | Engineering Case Study |
| Category | Intelligence Layer · AI Infrastructure · Student Performance |
| Built For | Learnzy |
| Author | Himanshu Gupta |
| Status | Active |
| Part of | LearnzyLabs |
Overview
Shiv is Learnzy’s intelligence layer.
It is not a chatbot.
It is not an AI wrapper.
It is the reasoning system that sits on top of every piece of student data inside Learnzy.
While large language models provide reasoning capabilities, Shiv provides identity, memory, context, safety, and product behavior. The language model is only one component inside a much larger architecture designed specifically for student performance.
This document explains both why Shiv exists and how it is engineered.
The Problem
While building Learnzy, I noticed something that almost every education platform had in common.
They collected enormous amounts of student data.
They knew:
- completed revisions
- missed revisions
- mock test performance
- chapter progress
- mistake history
- weak subjects
- study streaks
- upcoming schedules
Yet none of that data was actually useful during the moment a student needed help.
If a student asked:
How am I doing?
or:
Why do I keep making the same mistakes?
the application couldn’t answer.
Not because the information didn’t exist.
Because nothing connected it together.
Every feature existed independently.
There was no intelligence layer capable of reasoning across the entire preparation journey.
That became the real problem.
The Original Vision
The goal was never to build another chatbot.
The goal was to build something that understood the student.
Not only their questions.
Their preparation.
Their mistakes.
Their habits.
Their progress.
Eventually their wellness.
Their physiology.
Their recovery.
Instead of students opening five different screens to understand themselves, there should be one intelligence layer capable of reasoning across everything Learnzy knows.
That became Shiv.
First Attempt
Initially, I considered building Shiv as a custom language model.
I experimented with the idea of fine-tuning smaller open-source models and explored whether a domain-specific SLM could become Learnzy’s intelligence engine.
The idea was attractive.
- Complete ownership.
- Custom reasoning.
- Full control over behavior.
But after evaluating the tradeoffs, it became obvious that this was solving the wrong problem.
- Training infrastructure.
- GPU costs.
- Model deployment.
- Inference optimization.
- Continuous maintenance.
None of those improved the product itself.
The bottleneck wasn’t language generation.
It was product validation.
The Realization
I didn’t need a better model.
I needed a better system.
Instead of building intelligence from scratch, I could build an architecture around an existing reasoning model.
The language model would become interchangeable.
Everything valuable would live above it.
This completely changed the architecture.
Instead of asking:
How do I build an AI model?
I started asking:
How do I build an intelligence system?
That question shaped Shiv.
Why “Shiv”
The name wasn’t chosen because I wanted an assistant with a human name.
During the period I was building Learnzy, I spent a great deal of time reflecting on ideas of surrender, calmness, and clarity. Those ideas influenced how I approached engineering problems and product decisions.
When the intelligence layer needed an identity, “Shiv” felt natural.
Today, students interact with Shiv.
Internally, Shiv represents the reasoning system that connects every part of Learnzy together.
Core Philosophy
Large language models answer questions.
Products solve problems.
Shiv exists to bridge those two worlds.
The more context the system understands, the less context the student has to explain.
A student should never need to repeatedly describe:
- their weak chapters
- their revision backlog
- previous mistakes
- study history
- recent mock tests
- emotional state
The application already knows those things.
Shiv simply reasons over them.
System Evolution
Version 1
flowchart TD
A[Student] --> B[Chatbot]
B --> C[LLM]
C --> D[Answer]
A traditional chatbot.
Little context.
No memory.
No product understanding.
Version 2
flowchart TD
A[Student] --> B[Shiv]
B --> C[Student Context]
C --> D[Preparation History]
C --> E[Mistake Notebook]
C --> F[Revision Engine]
C --> G[Calendar]
C --> H[Wellness]
C --> I[LLM]
I --> J[Response]
Instead of answering questions in isolation, Shiv reasons over structured student data before producing a response.
The model became only one component inside the architecture.
High-Level Architecture
flowchart TD
A[Student] --> B[Android App]
A --> C[WhatsApp]
A --> D[Voice Future]
B --> E[Shiv Runtime Layer]
C --> E
D --> E
E --> F[Persona Engine]
E --> G[Safety Layer]
E --> H[Prompt Orchestration]
E --> I[Context Builder]
E --> J[Memory Manager]
F --> K[Student Intelligence Context]
G --> K
H --> K
I --> K
J --> K
K --> L[Mistake Notebook]
K --> M[Revision History]
K --> N[Calendar]
K --> O[Mock Tests]
K --> P[Weak Topics]
K --> Q[Wellness]
K --> R[Future Physiology]
K --> S[Previous Conversations]
K --> T[Profile]
K --> U[Cloud Run AI Gateway]
U --> V[Vertex AI Gemini]
V --> W[Final Response]
Runtime Architecture
The runtime is intentionally layered.
Every user request passes through multiple stages before reaching the model.
flowchart TD
A[Student Message] --> B[Authentication]
B --> C[Persona Resolution]
C --> D[Context Selection]
D --> E[Memory Retrieval]
E --> F[Safety Evaluation]
F --> G[Prompt Assembly]
G --> H[Cloud Gateway]
H --> I[Vertex AI]
I --> J[Post Processing]
J --> K[Student]
Each stage has a single responsibility.
This keeps the architecture modular while allowing future model replacements without changing product behavior.
Persona Layer
The language model is never exposed directly.
Students always interact with Shiv.
The Persona Layer defines:
- identity
- tone
- boundaries
- capabilities
- safety rules
- behavioral consistency
Regardless of which model powers the response, the experience remains Shiv.
Context Builder
The Context Builder is the most important part of the architecture.
Instead of sending the entire database into every request, Shiv dynamically constructs only the context required for the current conversation.
Examples include:
- latest revision statistics
- recent mock performance
- weak topics
- mistake categories
- study streak
- profile information
- previous conversations
- wellness summaries
Different questions require different context depths.
This minimizes token usage while maximizing relevance.
Memory Architecture
Memory exists on three levels.
| Memory Layer | Purpose | Examples |
|---|---|---|
| Conversation Memory | Recent chat history | Current conversation, recent intent, short-term continuity |
| Student Memory | Long-term preparation information | Mistakes, revision habits, mock trends, preferred study style |
| Product Memory | Static knowledge about Learnzy | Revision methodology, spaced repetition, wellness protocols, product behavior |
flowchart TD
A[User Request] --> B[Conversation Memory]
A --> C[Student Memory]
A --> D[Product Memory]
B --> E[Context Builder]
C --> E
D --> E
E --> F[Shiv Response]
AI Gateway
The mobile application never communicates directly with the model.
flowchart TD
A[Android] --> B[Supabase Edge Function]
B --> C[Cloud Run Gateway]
C --> D[Vertex AI]
D --> E[Response]
Benefits include:
- secure API key handling
- centralized prompt orchestration
- logging
- rate limiting
- model abstraction
- provider replacement
Safety Architecture
Before any request reaches the model, it passes through safety and scope checks.
flowchart TD
A[Input] --> B[Crisis Detection]
B --> C[Identity Rules]
C --> D[Scope Validation]
D --> E[Context Injection]
E --> F[Model]
The objective is simple.
Students should always receive safe, consistent, and predictable behavior.
Multi-Surface Design
Shiv is designed once.
Delivered everywhere.
flowchart TD
A[Shared Intelligence Layer] --> B[Android]
A --> C[WhatsApp]
A --> D[Voice]
B --> E[Same Persona]
C --> E
D --> E
E --> F[Same Memory]
F --> G[Same Context]
Different interfaces.
One intelligence system.
Engineering Principles
Several principles guided every technical decision.
Models are replaceable. Product intelligence is not.
The underlying model can change without changing what Shiv is.
Context is more valuable than parameters.
Understanding the student’s journey produces better responses than increasing model size.
Identity should be deterministic.
Students interact with Shiv, not whichever model happens to generate the response.
Product logic belongs outside the LLM.
The model reasons.
The application decides behavior.
Memory should feel helpful, never intrusive.
Student data is surfaced only when it improves the conversation.
Every architecture decision should preserve iteration speed.
The fastest way to improve Shiv is improving the layers around the model rather than rebuilding the model itself.
Lessons Learned
The biggest realization from building Shiv was that intelligence is rarely created by the model alone.
The real value comes from everything surrounding it.
Identity.
Memory.
Context.
Architecture.
Safety.
Product design.
Those layers transform a general-purpose reasoning model into something that feels personal, consistent, and genuinely useful.
Future Direction
Shiv is currently focused on academics.
Over time, the same architecture will expand to reason across additional dimensions of student performance, including wellness, physiological signals, behavioral patterns, and long-term learning progress.
The underlying model may change.
The intelligence layer should not.
That is the long-term vision.
Project Outcome
Shiv became the architecture that connects Learnzy’s product systems into one reasoning layer.
Where Synthesis organizes knowledge, Reason organizes thinking, and Intelligence organizes student signals, Shiv brings those layers into the student experience.
The important insight was simple:
An AI product is not defined by the model alone.
It is defined by the context, identity, memory, safety, and product behavior built around the model.