1. Overview
Implement the complete backend Curriculum & Learning Content domain for the Artificial Teacher system.
This domain is responsible for representing the educational structure that the rest of the backend will use to understand what the student is supposed to learn.
The domain must support the hierarchy:
Subject
↓
Topic
↓
Lesson
↓
Learning Objective / Content
The implementation must cover the complete backend flow:
Database
↓
Models
↓
Schemas
↓
CRUD / Repository
↓
Services
↓
API Routes
↓
Validation
↓
Tests
The domain must be designed around the project's intended use of Tanzania's syllabus/curriculum, while keeping the implementation flexible enough to support additional subjects, topics, lessons, and curriculum versions later.
- Objective
Build a reliable backend curriculum system that allows the application to:
- Store subjects.
- Organize subjects into topics.
- Organize topics into lessons/subtopics.
- Store learning objectives.
- Store educational content associated with lessons.
- Associate lessons with appropriate academic levels/forms.
- Retrieve curriculum structures efficiently.
- Provide curriculum information to the assessment and learning domains.
- Provide structured curriculum context to the Artificial Teacher later.
- Prevent invalid or orphaned curriculum relationships.
- Domain Ownership
The developer responsible for this issue owns the complete Curriculum domain:
- Database models
- Relationships
- Pydantic schemas
- CRUD/repositories
- Services
- API routes
- Validation
- Database migrations
- Seed/reference curriculum data
- Error handling
- Tests
- API documentation
The developer should deliver a functional curriculum subsystem, not merely create the database tables.
- Curriculum Structure
The core relationship should be:
Academic Level / Form
↓
Subject
↓
Topic
↓
Lesson
↓
Learning Objective
Example:
Form I
│
└── Mathematics
│
└── Algebra
│
├── Introduction to Algebra
├── Algebraic Expressions
└── Linear Equations
The exact hierarchy should follow the project's selected Tanzania curriculum structure.
- Subject Model
Implement the Subject domain.
A subject should contain appropriate fields such as:
- Subject ID
- Subject name
- Subject code where applicable
- Description
- Academic level applicability
- Active status
- Created timestamp
- Updated timestamp
Example:
Mathematics
Physics
Chemistry
Biology
English
The system should prevent unintended duplicate subjects.
- Topic Model
Implement topics belonging to subjects.
A topic should contain information such as:
- Topic ID
- Subject ID
- Topic name
- Description
- Sequence/order
- Active status
- Created timestamp
- Updated timestamp
Relationship:
Subject
└── Topic 1
└── Topic 2
└── Topic 3
A topic must not exist without a valid subject.
- Lesson Model
Implement lessons belonging to topics.
A lesson should support:
- Lesson ID
- Topic ID
- Lesson title
- Description
- Content
- Sequence/order
- Estimated learning time
- Active status
- Created timestamp
- Updated timestamp
Relationship:
Topic
├── Lesson 1
├── Lesson 2
└── Lesson 3
The lesson should represent the structured educational material that can later be consumed by the learning and Artificial Teacher systems.
- Learning Objectives
The curriculum should support explicit learning objectives.
For example:
Topic:
Linear Equations
Learning Objective:
The student should be able to solve a linear equation
with one unknown.
A learning objective should be associated with the appropriate curriculum element.
At minimum support:
- Objective ID
- Related topic/lesson
- Objective description
- Sequence/order
- Active status
The objective should later provide the learning target against which assessment and mastery can operate.
- Academic Level / Form
The curriculum must be associated with the appropriate student academic level.
For example:
Form I
Form II
Form III
Form IV
Do not hard-code academic levels throughout the services.
Represent them in a maintainable manner so that curriculum data can be expanded later.
The implementation should allow the system to answer:
«"Which Mathematics topics are applicable to this student's academic level?"»
- Curriculum Ordering
Curriculum elements should preserve their intended order.
For example:
Mathematics
├── Topic 1
│ ├── Lesson 1
│ ├── Lesson 2
│ └── Lesson 3
│
├── Topic 2
│ ├── Lesson 1
│ └── Lesson 2
│
└── Topic 3
Implement an explicit ordering/sequence mechanism rather than relying on database insertion order.
This becomes important later when determining:
- Next topic
- Previous topic
- Learning progression
- Recommendations
- Prerequisites
- Curriculum Relationships
The database relationships should enforce valid hierarchy.
For example:
Subject
↓
Topic
↓
Lesson
↓
Learning Objective
The backend must prevent situations such as:
Lesson → nonexistent Topic
Topic → nonexistent Subject
Use appropriate foreign keys and constraints.
- Curriculum CRUD / Repository
Implement repository/CRUD operations for:
Subjects
- Create
- Retrieve
- Update
- List
- Deactivate where appropriate
Topics
- Create
- Retrieve
- Update
- List by subject
- Deactivate where appropriate
Lessons
- Create
- Retrieve
- Update
- List by topic
- Deactivate where appropriate
Learning Objectives
- Create
- Retrieve
- Update
- List by lesson/topic
- Deactivate where appropriate
The implementation should avoid placing database logic directly inside API routes.
- Curriculum Services
Create services responsible for curriculum business logic.
For example:
SubjectService
TopicService
LessonService
CurriculumService
The services should handle things such as:
- Validating relationships
- Preventing duplicate curriculum entries
- Maintaining ordering
- Checking academic-level compatibility
- Retrieving nested curriculum structures
- Handling inactive curriculum items
- Curriculum API
Provide backend endpoints following the project's API conventions.
A reasonable structure is:
GET /subjects
GET /subjects/{subject_id}
GET /subjects/{subject_id}/topics
GET /topics/{topic_id}
GET /topics/{topic_id}/lessons
GET /lessons/{lesson_id}
GET /lessons/{lesson_id}/objectives
If curriculum management is restricted to authorized users in the current MVP, creation/update endpoints should be protected accordingly.
Do not introduce a large administrative system merely to manage curriculum.
- Student Curriculum Access
The backend should support retrieving curriculum relevant to an authenticated student's academic level.
For example:
GET /students/me/curriculum
The service should determine the student's academic level and return the appropriate curriculum.
Example:
Student: Form I
↓
Available curriculum
↓
Mathematics
├── Algebra
├── Geometry
└── ...
The API must not trust an arbitrary "student_id" supplied by the client when determining the current student's curriculum.
Use the authenticated identity from the Student domain.
- Curriculum Navigation
The backend should allow the frontend and future learning services to navigate:
Subject
↓
Topics
↓
Lessons
↓
Learning objectives
For example:
GET /subjects/{id}/topics
returns topics for a subject.
Then:
GET /topics/{id}/lessons
returns lessons for that topic.
This creates a clean foundation for the student's learning flow.
- Tanzania Curriculum Seed Data
Provide development seed data for the selected Tanzania syllabus/curriculum.
The seed should contain real structured curriculum data appropriate to the project's selected syllabus, not arbitrary placeholder content.
For example:
Form I
└── Mathematics
└── [Official curriculum topic]
└── [Relevant lesson/objective]
The exact syllabus data should be verified against the project's chosen official curriculum source before being treated as authoritative.
Keep seed data separate from application logic.
- Versioning Consideration
Do not build an unnecessarily complicated curriculum-management platform.
However, the data model should not make future curriculum changes impossible.
At minimum, structure the system so that curriculum data can later distinguish different curriculum versions if Tanzania's syllabus changes.
For the MVP, a simple active/current curriculum representation is sufficient.
- Database Migration
Create the required Alembic migrations for:
- Academic levels/forms
- Subjects
- Topics
- Lessons
- Learning objectives
- Required relationships and constraints
Verify the migration from a clean database:
alembic upgrade head
The curriculum should be reproducible entirely from migrations + seed data.
- Integration Boundaries
This domain should provide information to other backend domains.
Assessment will consume:
Subject
Topic
Lesson
Learning Objective
Learning/Progress will consume:
Topic
Lesson
Learning Objective
Adaptive Learning will consume:
Curriculum structure
Topic ordering
Learning objectives
Recommendation will consume:
Topics
Lessons
Learning objectives
Progression information
Artificial Teacher will eventually consume:
Subject
Topic
Lesson
Learning objective
Curriculum content
Therefore, Curriculum is a foundation domain.
- What This Domain Must NOT Implement
Do not put the following into this issue:
- AI/Gemma
- Prompt engineering
- AI-generated questions
- Student mastery calculation
- Adaptive decision-making
- Recommendations
- Student answer evaluation
- Teacher guidance
- Frontend UI
- Authentication implementation
Those belong to other domains.
This issue answers only:
«"What is the student supposed to learn?"»
- Call Chain
The normal curriculum retrieval flow should look like:
API Request
↓
Schema / Parameter Validation
↓
Curriculum Service
↓
Repository / CRUD
↓
PostgreSQL
↓
Curriculum Response
For student-specific curriculum:
Authenticated Student
↓
Student Academic Level
↓
Curriculum Service
↓
Relevant Subjects
↓
Topics
↓
Lessons
↓
Learning Objectives
- Tests
The implementation must include automated tests for:
Subject
- Create subject
- Retrieve subject
- List subjects
- Duplicate prevention
- Invalid subject handling
Topic
- Create topic
- Topic belongs to correct subject
- Invalid subject rejected
- Topic retrieval
- Topic ordering
Lesson
- Create lesson
- Lesson belongs to correct topic
- Invalid topic rejected
- Lesson retrieval
- Lesson ordering
Learning objectives
- Create objective
- Correct lesson/topic association
- Invalid association rejected
Academic level
- Curriculum filtering by academic level
- Student receives curriculum appropriate to their level
Security
- Unauthenticated protected operations rejected
- Unauthorized curriculum-management operations rejected where applicable
Database
- Alembic migration succeeds
- Foreign-key constraints work
- Seed data loads correctly
- Definition of Done
This issue is complete when:
- Expected Result
At the end of this issue, the backend should be able to answer questions such as:
What subjects does this student study?
What topics belong to Mathematics?
What lessons belong to this topic?
What should a student learn from this lesson?
Which curriculum applies to Form I?
What is the next topic/lesson in the curriculum?
The backend will then have a reliable educational foundation for the next domain:
Curriculum
↓
Assessment & Questions
↓
Student Attempts
↓
Mastery / Progress
↓
Adaptive Learning
↓
Recommendations
This is the issue I would assign next. It is backend-only, fits your existing architecture ("subject.py", "topic.py", "lesson.py", schemas, services, Alembic), and gives the later adaptive components something concrete to work with.
1. Overview
Implement the complete backend Curriculum & Learning Content domain for the Artificial Teacher system.
This domain is responsible for representing the educational structure that the rest of the backend will use to understand what the student is supposed to learn.
The domain must support the hierarchy:
Subject
↓
Topic
↓
Lesson
↓
Learning Objective / Content
The implementation must cover the complete backend flow:
Database
↓
Models
↓
Schemas
↓
CRUD / Repository
↓
Services
↓
API Routes
↓
Validation
↓
Tests
The domain must be designed around the project's intended use of Tanzania's syllabus/curriculum, while keeping the implementation flexible enough to support additional subjects, topics, lessons, and curriculum versions later.
Build a reliable backend curriculum system that allows the application to:
The developer responsible for this issue owns the complete Curriculum domain:
The developer should deliver a functional curriculum subsystem, not merely create the database tables.
The core relationship should be:
Academic Level / Form
↓
Subject
↓
Topic
↓
Lesson
↓
Learning Objective
Example:
Form I
│
└── Mathematics
│
└── Algebra
│
├── Introduction to Algebra
├── Algebraic Expressions
└── Linear Equations
The exact hierarchy should follow the project's selected Tanzania curriculum structure.
Implement the Subject domain.
A subject should contain appropriate fields such as:
Example:
Mathematics
Physics
Chemistry
Biology
English
The system should prevent unintended duplicate subjects.
Implement topics belonging to subjects.
A topic should contain information such as:
Relationship:
Subject
└── Topic 1
└── Topic 2
└── Topic 3
A topic must not exist without a valid subject.
Implement lessons belonging to topics.
A lesson should support:
Relationship:
Topic
├── Lesson 1
├── Lesson 2
└── Lesson 3
The lesson should represent the structured educational material that can later be consumed by the learning and Artificial Teacher systems.
The curriculum should support explicit learning objectives.
For example:
Topic:
Linear Equations
Learning Objective:
The student should be able to solve a linear equation
with one unknown.
A learning objective should be associated with the appropriate curriculum element.
At minimum support:
The objective should later provide the learning target against which assessment and mastery can operate.
The curriculum must be associated with the appropriate student academic level.
For example:
Form I
Form II
Form III
Form IV
Do not hard-code academic levels throughout the services.
Represent them in a maintainable manner so that curriculum data can be expanded later.
The implementation should allow the system to answer:
«"Which Mathematics topics are applicable to this student's academic level?"»
Curriculum elements should preserve their intended order.
For example:
Mathematics
├── Topic 1
│ ├── Lesson 1
│ ├── Lesson 2
│ └── Lesson 3
│
├── Topic 2
│ ├── Lesson 1
│ └── Lesson 2
│
└── Topic 3
Implement an explicit ordering/sequence mechanism rather than relying on database insertion order.
This becomes important later when determining:
The database relationships should enforce valid hierarchy.
For example:
Subject
↓
Topic
↓
Lesson
↓
Learning Objective
The backend must prevent situations such as:
Lesson → nonexistent Topic
Topic → nonexistent Subject
Use appropriate foreign keys and constraints.
Implement repository/CRUD operations for:
Subjects
Topics
Lessons
Learning Objectives
The implementation should avoid placing database logic directly inside API routes.
Create services responsible for curriculum business logic.
For example:
SubjectService
TopicService
LessonService
CurriculumService
The services should handle things such as:
Provide backend endpoints following the project's API conventions.
A reasonable structure is:
GET /subjects
GET /subjects/{subject_id}
GET /subjects/{subject_id}/topics
GET /topics/{topic_id}
GET /topics/{topic_id}/lessons
GET /lessons/{lesson_id}
GET /lessons/{lesson_id}/objectives
If curriculum management is restricted to authorized users in the current MVP, creation/update endpoints should be protected accordingly.
Do not introduce a large administrative system merely to manage curriculum.
The backend should support retrieving curriculum relevant to an authenticated student's academic level.
For example:
GET /students/me/curriculum
The service should determine the student's academic level and return the appropriate curriculum.
Example:
Student: Form I
↓
Available curriculum
↓
Mathematics
├── Algebra
├── Geometry
└── ...
The API must not trust an arbitrary "student_id" supplied by the client when determining the current student's curriculum.
Use the authenticated identity from the Student domain.
The backend should allow the frontend and future learning services to navigate:
Subject
↓
Topics
↓
Lessons
↓
Learning objectives
For example:
GET /subjects/{id}/topics
returns topics for a subject.
Then:
GET /topics/{id}/lessons
returns lessons for that topic.
This creates a clean foundation for the student's learning flow.
Provide development seed data for the selected Tanzania syllabus/curriculum.
The seed should contain real structured curriculum data appropriate to the project's selected syllabus, not arbitrary placeholder content.
For example:
Form I
└── Mathematics
└── [Official curriculum topic]
└── [Relevant lesson/objective]
The exact syllabus data should be verified against the project's chosen official curriculum source before being treated as authoritative.
Keep seed data separate from application logic.
Do not build an unnecessarily complicated curriculum-management platform.
However, the data model should not make future curriculum changes impossible.
At minimum, structure the system so that curriculum data can later distinguish different curriculum versions if Tanzania's syllabus changes.
For the MVP, a simple active/current curriculum representation is sufficient.
Create the required Alembic migrations for:
Verify the migration from a clean database:
alembic upgrade head
The curriculum should be reproducible entirely from migrations + seed data.
This domain should provide information to other backend domains.
Assessment will consume:
Subject
Topic
Lesson
Learning Objective
Learning/Progress will consume:
Topic
Lesson
Learning Objective
Adaptive Learning will consume:
Curriculum structure
Topic ordering
Learning objectives
Recommendation will consume:
Topics
Lessons
Learning objectives
Progression information
Artificial Teacher will eventually consume:
Subject
Topic
Lesson
Learning objective
Curriculum content
Therefore, Curriculum is a foundation domain.
Do not put the following into this issue:
Those belong to other domains.
This issue answers only:
«"What is the student supposed to learn?"»
The normal curriculum retrieval flow should look like:
API Request
↓
Schema / Parameter Validation
↓
Curriculum Service
↓
Repository / CRUD
↓
PostgreSQL
↓
Curriculum Response
For student-specific curriculum:
Authenticated Student
↓
Student Academic Level
↓
Curriculum Service
↓
Relevant Subjects
↓
Topics
↓
Lessons
↓
Learning Objectives
The implementation must include automated tests for:
Subject
Topic
Lesson
Learning objectives
Academic level
Security
Database
This issue is complete when:
At the end of this issue, the backend should be able to answer questions such as:
What subjects does this student study?
What topics belong to Mathematics?
What lessons belong to this topic?
What should a student learn from this lesson?
Which curriculum applies to Form I?
What is the next topic/lesson in the curriculum?
The backend will then have a reliable educational foundation for the next domain:
Curriculum
↓
Assessment & Questions
↓
Student Attempts
↓
Mastery / Progress
↓
Adaptive Learning
↓
Recommendations
This is the issue I would assign next. It is backend-only, fits your existing architecture ("subject.py", "topic.py", "lesson.py", schemas, services, Alembic), and gives the later adaptive components something concrete to work with.