Lesson planning is the piece of teaching work that never appears on a timetable. It happens on a Sunday evening, or in a free period, or not at all. When a school asks teachers to submit plans, the plans get written for the file rather than for the classroom, and everyone involved knows it.
EdunodeX approaches this as two separate problems that get confused with each other. One is the single lesson: what happens in one period, on one topic. The other is the term: which chapters get covered in which week, and whether the class will actually finish the syllabus before the exam. Different data, different cadence, different screens.
What a lesson plan actually costs a teacher
A usable lesson plan needs a hook, a way of drawing out what students already know, an explanation sequence, practice, and a check for understanding. Written honestly, that is twenty to forty minutes of thinking per period. A teacher with five periods a day and a syllabus deadline does not have that time five times a day.
The realistic ask is not to remove the teacher from planning. It is to remove the blank page. A draft that is structurally complete and topically correct can be read, corrected and made personal in a few minutes. That is the workflow EdunodeX builds for.
The 5E structure EdunodeX generates
The lesson plan generator produces a plan in the 5E shape — engage, explore, explain, elaborate, evaluate — because it is the structure most Indian in-service training already uses, so a head of department reading the output does not have to learn a new format.
The teacher supplies the topic, the grade and the subject. The service embeds the topic, retrieves grounding material, renders a prompt from a stored template, and asks the model for strict structured output. The result is parsed into a stored lesson plan record inside the school’s own schema and also rendered as readable Markdown, so the same plan can be edited on screen and exported to PDF for a file copy.
Worksheets run through a near-identical pipeline with one addition: a Bloom’s taxonomy target. The generator is given a percentage distribution across the six cognitive levels — an easier worksheet weights recall and understanding, a harder one weights analysis and evaluation — and the generated paper is checked so that the section marks add up to the total the teacher asked for.
Grounding plans in the NCERT textbook
A general-purpose model asked about photosynthesis will write something reasonable and generic. It will not know which figure the Class 7 textbook uses or which terms that chapter introduces.
So the generator retrieves first. The topic is turned into an embedding, and a semantic search runs against indexed NCERT content filtered by board, grade and subject. The retrieved passages are interpolated into the prompt, and the page references come back attached to the plan.
Two things about this are worth stating plainly. First, the citations are the retrieval’s citations, not the model’s — they point at what was actually fed in. Second, when retrieval fails or returns nothing relevant, the system logs a warning and generates the plan anyway with an empty citation list. It does not fabricate a page number to fill the field, and it does not fail the request, because a teacher who asked for a plan still wants a plan.
Teaching plans: pacing a whole term, not one period
The term-level planner solves a different problem: syllabus completion. It reads two structures out of the school’s own data.
The first is the syllabus tree for the subject — nodes with a parent, a depth, a sequence, estimated teaching hours, a difficulty level and declared prerequisites. The second is the exam schedule for that class and academic year, with dates, types and maximum marks.
Given a start date, an end date and a pace setting, the planner distributes syllabus nodes across the available weeks so that prerequisites come before the topics that depend on them, difficulty ramps rather than spikes, and each unit lands before the exam that assesses it. A generated proposal can then be turned into dated plan items, and progress against those items is what the teaching diary and the daily view read from.
That link matters more than the generation does. Once a plan exists as dated items, the system can tell a teacher — and a principal — that a class is behind: a plan item whose planned end date has passed while its status is still not complete.
Draft, review, confirm: where the teacher stays in charge
The teaching plan API makes the human step structural rather than advisory. One endpoint generates a proposal. A different endpoint confirms it and creates the plan. Between those two calls the proposal exists only in the response the teacher is looking at.
This is the same pattern EdunodeX uses for AI-generated question papers, for extracted marks and for graded answer sheets. It is a deliberate constraint: no AI output becomes school record because a model produced it. It becomes school record because a named user, on a specific date, chose to save it.
What the lesson planner does not do
It does not model International Baccalaureate or Cambridge assessment structures. EdunodeX’s seeded grading systems are a CBSE nine-point scale, a percentage scale and a five-point letter scale, and the planner is written against Indian board syllabi and NCERT content. A school running an international programme will find the lesson structure usable and the syllabus and assessment mapping unsuitable.
It does not observe the classroom. The plan is a proposal for a period; whether the period went that way is what the teaching diary and the lesson log record, and the teacher enters those.
It does not write itself into the timetable. Scheduling stays where it is, in the timetable module, and the plan attaches to it.
And it is not on for every school by default. AI classroom generation sits behind its own entitlement, separate from the classroom module, so a school can run classes, attendance and marks in EdunodeX with the AI generators switched off entirely.