Classroom Memory

An AI that tells a teacher what to teach next — and proves why.

Most education software gives a class a syllabus. Classroom Memory gives the class a memory, and gives the teacher a plan.

Live demo: classroom-memory.vercel.app · Demo video: YouTube · Repository: GitHub

The one-line difference

Every analytics dashboard in education can tell a teacher what is broken. None of them tell the teacher what to do on Monday morning.

A normal dashboard says: "The class is failing recursion."

Classroom Memory says: "This week, teach functions. The class is failing recursion the hardest, but they are not ready for it yet. Functions is the foundation that unblocks it, and it opens up thirteen more concepts."

That is the difference between a dashboard and a system that reasons. It is the whole project in two sentences.

Problem Statement

Indian higher-education classrooms run at 60 to 120 students per teacher. In that setting, three failures are structural, not accidental:

The teacher is flying blind. Attendance and end-of-term marks are lagging indicators. By the time a teacher learns that half the class never understood functions, the syllabus has already moved on to decorators and async.
Remediation is aimed at the wrong thing. When a gap does surface, the instinct is to re-teach the topic students failed. But students usually fail a topic because they are missing its prerequisite. Re-teaching recursion to a class that never learned functions wastes the lecture and confirms the students' belief that they are "bad at programming."
Weak students are invisible until they drop out. No teacher can hold sixty individual learning states in their head. Students who fall behind quietly stay behind, and the first formal signal is a failed exam.

The result is a system that measures learning after it has already failed, and intervenes in the wrong place when it does.

Proposed Solution

Classroom Memory gives every student a private, persistent memory of what they know, and gives the teacher one view that reasons across all of those memories at once.

Each student has an isolated long-term memory, an adaptive mastery graph, a personal recall surface, and an auto-generated report card.
The teacher gets a class-level heat map over the same curriculum graph, a graph-reasoned teaching plan, and one-click targeted interventions for the specific students who need them.
The curriculum is modelled as a prerequisite graph, not a flat topic list. Because the system knows that recursion requires functions, it can find the real root cause of a class-wide failure instead of the loudest symptom.

The teaching plan does not rank concepts by failure rate. It ranks them by readiness × unblocking power: which concept can this class actually learn right now, and how many downstream concepts does learning it open up. That is a decision, not a chart.

Expected Impact

Who	What changes
Teacher	Stops guessing. Gets a ranked, justified answer to "what do I teach next week," backed by every student's actual state. Remediation is aimed at the prerequisite, not the symptom.
Student	Gets a private tutor that knows their history — what they mastered, what they are forgetting, what they are ready for — instead of the same lecture as sixty other people.
Institution	Learning gaps become visible weeks before exams, not after. Dropout risk becomes an early signal instead of a post-mortem statistic.

The measurable claim is narrow and testable: intervene on the prerequisite instead of the failed topic, and remediation lectures stop being wasted. A pilot can validate this in one semester by comparing post-intervention mastery between a prerequisite-targeted section and a symptom-targeted control.

Scalability

The architecture was built multi-tenant from the first commit, which is what makes classroom-to-institution scaling a configuration change rather than a rewrite.

Per-student isolation by design. Every learner is a separate cloud dataset. Adding students adds datasets; it does not contend with existing ones.
Subject-agnostic. The engine reasons over a prerequisite graph, not over Python. Any subject with dependencies — mathematics, accounting, biology, data structures — works by importing a different JSON curriculum through the UI. Nothing in the reasoning layer is language-specific.
Curriculum import is a product feature, not a migration. A department uploads its own syllabus as a prerequisite graph, the system validates concept IDs, prerequisites, question structure and answer indexes, and the class is live.
Deployed, not theoretical. The live instance runs a FastAPI backend on Render, a static SPA on Vercel, and hosted graph memory — a stack that scales horizontally without architectural change.

Adoption and Sustainability Model

Deliberately institution-first, not student-first: the buyer with the budget and the retention problem is the college.

Pilot — one department, one semester, free. Success metric agreed up front: measured mastery lift in the remediated cohort.
Institutional license — per-department annual subscription covering unlimited students, curriculum import, and the teacher analytics layer. Priced against what a single dropout costs the institution in lost fees, which is the honest comparison.
Why it defends itself — the value compounds with use. A college that has run three semesters through the system owns a validated prerequisite graph for its own syllabus plus longitudinal mastery data on its own students. That asset does not transfer to a competitor.

An open-core path stays available: the reasoning engine and curriculum format can remain public while hosted multi-tenant deployment, institutional analytics and support are the commercial layer.

Verified Working System

This is a deployed product, not a slideware concept. On the live instance:

22-concept prerequisite graph, 12 private student memories, one dense class graph of roughly 290 relationship edges.
A 12-check automated verification that runs the full memory lifecycle against the real tenant.
Durable state, class setup, student enrollment, curriculum import, and a teacher workflow that can be driven end to end by a stranger.

Both services are live and can be checked right now:

curl https://classroom-memory.vercel.app/api/health

Core Idea

Most education software stores content. Classroom Memory stores learning state.

A teacher does not only need another quiz or another chatbot. A teacher needs to know:

what each student has mastered;
what each student is forgetting;
what each student is ready to learn next;
what the whole class is stuck on;
which students need targeted review;
why the system is recommending a specific next lesson.

Classroom Memory treats those questions as a memory problem. Each student becomes a separate Cognee Cloud memory. The teacher view reads across those memories to produce a class heat map, a graph-reasoned teaching plan, and targeted interventions.

What the Product Does

Student Experience

Select or enroll a student.
Start an adaptive quiz.
Watch the student's concept graph update live as answers change mastery.
Ask the student's memory questions such as explain closures to me.
See the next recommended concept and the graph reason behind it.
Inspect the learning timeline, cloud memory contents, session log, and concept details.
Generate a progress report from the student's own memory.
Retire mastered concepts from active practice.
Reset a student as a transfer-student or fresh-start workflow.

Teacher Experience

Ask a class-level question across the class memory.
View a full class heat map over the same curriculum graph.
See a graph-reasoned teaching plan that prioritizes concepts students are ready to learn, not merely the concepts with the highest raw failure rate.
Assign review to every student who is red or rusty on a concept.
Drill into an individual student's graph from the teacher page.
Set up a class roster in one action.
View students in a scrollable roster with current mastery summary.

Curriculum Experience

Use the built-in Python fundamentals curriculum.
Import a new curriculum from JSON through the UI.
Validate concept IDs, prerequisites, question structure, and answer indexes.
Reset the class onto the imported curriculum after validation.

How It Works: Many Memories, Not One

Everything from here down is the technical approach. The sections above are the product.

The important architectural choice is not simply that the app is hosted or uses an AI memory API. The important choice is that the classroom is modeled as many memories, not one.

Classroom Memory uses Cognee Cloud in three layers:

Private student memories: each student has an isolated dataset such as student_alice.
Shared class memory: the teacher can query a dense class graph that summarizes all students and concepts.
Intervention memory: teacher-assigned reviews are written to class_interventions.

This structure makes the teacher view cloud-native. A single local graph can show one memory. This product needs many private memories and a teacher view that reads across them.

Why a Graph, Not a Vector Database

Multi-tenancy is why this needs the cloud. Graph memory is why it needs Cognee specifically.

A vector database only knows that two things are similar. The entire product depends on a different relationship: one concept requires another. "Recursion requires functions" is not a similarity, it is a directed edge, and the teaching logic is impossible without it.

Cognee builds an actual knowledge graph from plain relationship sentences. When the app seeds a student with "learning recursion requires functions and conditionals," Cognee extracts the concepts as entities and the prerequisite as a real edge. Recall then does graph traversal, not keyword matching: ask a student's memory "what must I learn before decorators?" and it answers "functions and closures" by walking the edges to the nodes those edges point to.

That is why plain vector search or RAG would not have worked here. A vector hit finds similar text and misses the prerequisite structure. Cognee gives the graph, the extraction, and the hosted multi-tenant storage in one layer, which is exactly the combination this product needs.

Memory Layer Lifecycle Usage

The graph memory layer is provided by Cognee Cloud. This table maps each capability to the product behavior it powers.

Memory capability	Product usage
`serve()`	Connects the backend to the authenticated Cognee Cloud tenant. The UI badge reports the live cloud connection state.
`remember()`	Seeds each student dataset with a relationship-rich curriculum document. Also writes mastery traces, progress snapshots, class overview memory, teaching-plan memory, and teacher interventions.
`remember(session_id=...)`	Stores quiz attempts as session memory so recent learning events can be attached to the current student session without forcing every attempt into permanent graph memory.
`remember(node_set=...)`	Tags memories as `curriculum`, `progress`, `mastery-trace`, `class-overview`, `teaching-plan`, or `teacher-intervention` so the cloud console shows structured memory activity.
`recall()`	Powers the student ask box, student report generation, class ask flow, and fallback multi-dataset class recall.
Multi-dataset recall	Supports the teacher's ability to query across multiple student datasets when the combined class graph is not used.
`forget()`	Deletes a student's active cloud dataset during reset and removes a mastered concept from active practice through the retire workflow.
`improve()`	Honest limitation: on the tenant used during development, Cognee Cloud's remote `improve()` endpoint returned 404, so mastery re-weighting runs app-side with the same feedback-weight semantics and is persisted in the SQLite ledger. The provider boundary is written so native cloud `improve()` drops in with no UI change the day the remote endpoint is available. Stating this plainly is deliberate: the goal was a working product, not a faked capability.

Product Architecture

Browser SPA
  Student view
    mastery summary
    adaptive quiz
    personal ask box
    concept graph
    learning timeline
    report card
    cloud memory contents

  Teacher view
    class ask box
    graph-reasoned teaching plan
    intervention workflow
    student roster
    class heat map
    per-student drill-down

        REST/JSON

FastAPI backend
  CloudProvider
    Cognee Cloud through cognee.serve()
    async SDK bridged into sync FastAPI endpoints

  SQLite ledger
    students
    mastery weights
    seeded datasets
    interventions
    intervention_students
    tenant metadata

        Cognee SDK

Cognee Cloud tenant
  student_alice
  student_bob
  student_cara
  ...
  class_graph
  class_interventions

Backend Design

The backend is a FastAPI application in backend/app.py. The CloudProvider handles the real Cognee Cloud integration and the SQLite persistence layer, and exposes a clean JSON API to the frontend.

Main API Surface

Endpoint	Purpose
`GET /api/health`	Cloud connection status, active curriculum, concept count, seeded students, ledger name.
`GET /api/students`	Roster with mastery counts and gap counts.
`GET /api/student/graph`	Student concept graph, frontier, next step, explainability, assignments, and session memory count.
`GET /api/student/timeline`	Learning history reconstructed from concept practice timestamps and decay state.
`GET /api/student/report`	Progress report generated from the student's own Cognee Cloud memory via recall.
`POST /api/quiz/next`	Next adaptive question for the student's graph frontier.
`POST /api/quiz/answer`	Updates mastery weight, session memory, cursor, graph state, and cloud traces.
`GET /api/class/heatmap`	Class-wide concept heat map with red, amber, green, and average mastery signals.
`GET /api/teacher/plan`	Graph-reasoned teaching plan ranked by readiness and downstream unlock value.
`POST /api/ask`	Student-level recall from that student's memory.
`POST /api/class/ask`	Teacher-level recall from the class graph or multiple student datasets.
`POST /api/teacher/assign-review`	Creates a targeted review assignment for red or rusty students.
`POST /api/student/add`	Adds one student with a fresh mastery graph.
`POST /api/class/setup`	Adds a roster of students in one action.
`POST /api/curriculum/import`	Validates and activates a new curriculum JSON.
`POST /api/retire`	Retires a mastered concept from active practice.
`POST /api/reset-student`	Resets local mastery and deletes the active cloud dataset when connected.

Mastery Model

Each concept has a floating mastery weight:

Weight range	Band	Meaning
`< 0.35`	red	gap
`0.35` to `0.75`	amber	learning
`> 0.75`	green	mastered

Correct answers move mastery upward:

w = w + 0.35 * (1 - w)

Wrong answers move mastery downward:

w = w - 0.15 * w

A fresh concept starts at 0.2. Three correct answers move a concept from 0.2 to approximately 0.78, which marks it green.

Mastered concepts can become rusty in the view layer after 14 days untouched. The top navigation includes an age +30d control so the demo can show forgetting without mutating the underlying timestamps.

Graph-Native Learning Logic

The curriculum is not treated as a flat question bank. Each concept has prerequisites in requires, forming a directed concept graph.

The quiz chooses a student's frontier:

Ignore retired concepts.
Ignore already mastered concepts.
Keep concepts whose prerequisites are at least amber.
Prioritize amber concepts before opening new red concepts.

The student report explains this decision with:

the frontier rule;
the selected next concept;
prerequisite readiness;
the concept chain that led to the recommendation.

The teacher plan applies a class-level version of the same graph reasoning. It scores a concept higher when many students are stuck on it, those students are ready for it, and the concept unlocks many downstream concepts. This prevents the teacher plan from recommending advanced concepts before the class is prepared for their prerequisites.

Data Persistence

Cloud mode uses backend/mastery_ledger.sqlite. The file is ignored by Git because it is runtime state.

SQLite stores:

students;
exact mastery weights;
concept timestamps;
retired flags;
seeded Cognee datasets;
tenant metadata;
teacher interventions;
intervention-student assignments.

The app previously supported cloud_state.json; the ledger contains a migration helper that can import that legacy file once if present.

Cognee Dataset Strategy

Student Datasets

Each student gets a dataset name:

student_<student_id>

For imported non-Python curricula, the domain is included:

student_<domain>_<student_id>

Each student seed is a relationship-rich document. It anchors the student as an entity, names the active course, describes every concept, and states prerequisite relationships as explicit sentences. This makes Cognee's graph extraction useful for both concept recall and student-specific progress recall.

Class Graph

The teacher can use a combined class dataset:

class_graph

This dataset is intentionally dense. It contains:

student entities;
concept entities;
prerequisite relationships;
one sentence per student-concept mastery relation;
class-level progress signals.

The teacher's ask the class workflow prefers this combined class graph. If it is unavailable, the backend falls back to recall across seeded per-student datasets.

Intervention Dataset

Teacher review assignments are written to:

class_interventions

They are tagged with teacher-intervention and the active curriculum domain.

Frontend Design

The frontend is a static browser app served from frontend/. It uses:

vis-network for graph rendering;
lucide for icons;
plain JavaScript for state and API calls;
CSS in frontend/style.css.

The main pages are:

student: student mastery, quiz, graph, report, timeline, cloud memory contents;
teacher: class ask, teaching plan, intervention workflow, roster, heat map;
about: project explanation, architecture, product readiness, and proof points.

The student and teacher pages are intentionally arranged as stacked full-width work areas so the graph and reports have enough space during a live demo.

Curriculum Format

The built-in curriculum lives at curriculum/python.json.

Each curriculum has:

{
  "domain": "python",
  "title": "Python fundamentals -> async",
  "concepts": [
    {
      "id": "variables",
      "name": "Variables & assignment",
      "summary": "Names bound to objects; Python variables are references, not boxes.",
      "requires": [],
      "questions": [
        {
          "q": "After `a = [1]; b = a; b.append(2)`, what is `a`?",
          "options": ["[1]", "[1, 2]", "[2]", "error"],
          "answer": 1
        }
      ]
    }
  ]
}

The validator checks:

domain format;
non-empty title;
non-empty concept list;
valid concept IDs;
duplicate concept IDs;
required names and summaries;
prerequisite references;
question text;
options;
answer indexes.

Imported curriculum files are written under curriculum/imported/, which is ignored by Git as runtime state.

Sample Class Data

The app seeds a class-sized roster with different mastery profiles so the teacher view is meaningful from the first second:

alice: fresh student, all concepts red;
bob: mid-progress;
cara: advanced but rusty on older mastered concepts;
additional students with varied progress patterns.

Recursion and async-related concepts are intentionally class-wide gaps so the teacher heat map and teaching plan are meaningful immediately.

Running the Project

Prerequisites

Python 3.11
FastAPI and Uvicorn available in the Python environment
Cognee SDK available in the Python environment for cloud mode
Browser with internet access for CDN-loaded frontend libraries

The commands below use the existing local virtual environment path used in this workspace:

D:\cognee\.venv\Scripts\python.exe

Adjust that path if your Python environment is elsewhere.

Configure and Run

Create backend/.env:

CLASSROOM_MODE=cloud
COGNEE_CLOUD_URL=https://your-tenant.aws.cognee.ai
COGNEE_CLOUD_API_KEY=your_api_key

Run:

cd ClassroomMemory\backend
..\.venv\Scripts\python.exe -m uvicorn app:app --port 8002 --host 127.0.0.1

For a phone demo on the same network:

cd ClassroomMemory\backend
..\.venv\Scripts\python.exe -m uvicorn app:app --port 8002 --host 0.0.0.0

Then open:

http://<your-LAN-IP>:8002

Verification

Product Logic Smoke Test

This validates the product's graph, mastery, and teaching logic deterministically:

cd ClassroomMemory
.venv\Scripts\python.exe backend\test_demo.py

This validates:

health endpoint;
class-sized roster;
student graph shape;
frontier explanation;
quiz progression from red to green;
wrong-answer downgrade;
class heat map;
graph-reasoned teaching plan;
rusty decay view;
retire guard;
ask box;
reset;
direct quiz-answer cursor behavior;
class ask;
teacher intervention workflow;
enrollment and validation;
class setup;
curriculum import and prerequisite validation;
404 guard.

Live Cognee Cloud Verification

cd ClassroomMemory
.venv\Scripts\python.exe backend\verify_cloud.py

This validates against the configured tenant:

serve() authentication and connection;
remember() ingestion into a verification dataset;
recall() answer from the cloud graph;
dataset provenance on recall results;
remember(session_id=...) session-memory write;
remember(node_set=...) node-set tagging;
one recall across multiple datasets;
forget() dataset deletion;
deterministic product arc from red to green;
teacher heat-map signal;
frontier explanation.

Suggested Demo Flow

Start the app and show the cognee cloud badge.
Open Alice in the student view.
Answer three quiz questions correctly and show one concept move to mastered.
Point to the student report: next step, explanation, timeline, and cloud memory contents.
Ask Alice's memory: explain closures to me.
Generate a report card.
Switch to the teacher page.
Show the graph-reasoned teaching plan.
Ask the class: who has mastered recursion?
Assign review from a recommended class gap.
Drill into Alice from the teacher roster and return to the class heat map.
Open the Cognee Cloud console and show student datasets, class_graph, and class_interventions.
Run backend\verify_cloud.py for executable proof.

Cloud Console Proof Points

In the Cognee Cloud console, the following should be visible after using the app in cloud mode:

student_alice, student_bob, student_cara, and any enrolled students;
curriculum memory tagged as curriculum;
progress snapshots tagged as progress;
mastery traces tagged as mastery-trace;
the dense class_graph dataset;
teacher intervention memory in class_interventions;
search answers from a selected student dataset.

These are not frontend-only artifacts. They are written by the backend through the Cognee SDK.

Project Structure

ClassroomMemory/
  README.md
  backend/
    app.py              FastAPI app and REST endpoints
    providers.py        CloudProvider, mastery logic, Cognee Cloud integration
    ledger.py           SQLite persistence layer
    test_demo.py        Product logic smoke test
    verify_cloud.py     Live Cognee Cloud verification
  curriculum/
    python.json         Built-in prerequisite graph and quiz bank
  frontend/
    index.html          Student, teacher, about views and modals
    app.js              Frontend state, API calls, graph rendering, UI wiring
    style.css           Full visual system and responsive layouts

Runtime files ignored by Git:

backend/.env
backend/mastery_ledger.sqlite
backend/cloud_state.json
curriculum/imported/

Engineering Notes

The browser stores no mastery state.
Cloud calls are async, while FastAPI endpoints are sync; CloudProvider runs Cognee calls on a dedicated background event loop.
Slow or non-critical cloud writes use fire-and-forget wrappers so the UI stays responsive.
Student reset handles Cognee's asynchronous dataset deletion by falling back to versioned dataset names when needed.
Class setup and enrollment seed cloud datasets in the background.
Teacher recommendations are computed from the prerequisite graph and class mastery state, then written back into class memory.

Roadmap

Honest about what exists and what does not:

Built and live — prerequisite-graph reasoning, per-student memory, adaptive quizzing, class heat map, teaching plan, targeted interventions, curriculum import, automated verification.
Next — LMS import so a college does not hand-author its prerequisite graph; spaced-repetition decay so "forgetting" is modelled over real time rather than inferred from attempts; teacher-facing mobile view.
Pilot-blocking — institutional SSO, per-college data isolation and retention policy, and an evaluation harness to measure mastery lift against a control section.

Final Notes

Classroom Memory is a working classroom intelligence layer, not a dashboard:

one private memory per student;
one teacher view that reasons across all of them;
graph-native prerequisite reasoning that finds root causes, not symptoms;
live recall from student and class memory;
durable mastery state that survives restarts;
targeted interventions aimed at named students;
automated verification that proves the whole lifecycle runs.

The result is a project that can be run locally, verified automatically, demonstrated live at a URL, and extended into a real classroom pilot next semester.

Name		Name	Last commit message	Last commit date
Latest commit History 23 Commits
backend		backend
curriculum		curriculum
frontend		frontend
.gitignore		.gitignore
README.md		README.md
render.yaml		render.yaml
requirements.txt		requirements.txt
vercel.json		vercel.json

Folders and files

Latest commit

History

Repository files navigation