# Teaching & Feedback


A course is content; teaching is what happens when the work comes back. This chapter is
about that loop: the assignment you attach to a lesson, the hand-in a student sends,
the feedback the AI writes within seconds from your own material, the Light the student
raises when they are stuck, and the board that tells you who to call. It is the most
human chapter in the manual, and the one with the fewest tools: your assistant can set
assignments up, but reading a hand-in and answering it is yours.

A path such as *Customers → Mentor Board* names a group in the admin's navigation and the
page under it.

## Concepts

**An assignment asks for work.** It is attached to exactly one scope — a lesson, a module
or the whole course — and that placement decides where the student meets it and what it
counts for: a lesson's assignment sits on the lesson page and is part of finishing that
lesson; a module's gets its own page after the module's lessons; a course's shows on the
course home. The assignment carries *rating criteria*: one text that both the AI and your
staff read when they judge a hand-in. It also decides whether every hand-in must carry a
Light and whether staff are emailed on each hand-in. New assignments are drafts until you
publish them.

**A hand-in is text, a file, or both.** PDF, image, audio, video, or a plain-text file, up
to 500 MB. A student can hand in more than once; each submission is rated on its own.
Hand-ins are private to the student and your staff.

**The rater answers first, from your teaching.** When a hand-in lands, the AI rates it at
once against the criteria. It reads what the student wrote and attached — text, PDFs and
images directly, audio and video through their transcripts — and it reads *your*
material in the assignment's scope: lesson descriptions, text blocks, checklist items,
uploaded files and the transcripts of your recordings. It also reads the student's
participant folder (the next chapter), so feedback remembers them. It never reads your
mentor notes and never quotes them. The student sees the AI's feedback immediately,
before you have; that is deliberate, so nobody waits on you for a first answer.

**Check-ins and Lights.** An assignment that *asks for a check-in light* turns into a
recurring self-report: with every hand-in the student says how it is going — green
(clear and moving), yellow (slowed or unsure), red (stuck, needs help). The Light is the
student's own word, never derived from their text or progress; the AI acknowledges it
and never grades it. A weekly check-in is a habit your program keeps, not a schedule the
platform enforces. When you have read a Light you *confirm* it — one click that records
who saw it and when — and an unconfirmed red is the thing the board exists to show you.

**Finishing a lesson includes handing in.** Completion is derived from content: a lesson
with an assignment is complete when the student has opened it, ticked its checklist,
watched its videos, and handed in. On a sequentially gated course that is what opens the
next module. Adding an assignment later adds a requirement for students not yet done; it
never un-completes anyone.

## Hands-on

### Ask for work

Mira says: *"Add an assignment to the Week 1 lesson: hand in your time audit. Rate it on
whether they listed at least five repeated tasks with a time each and picked one to
automate. Ask for a check-in light. Publish it."*

`omumu_assignment_create` attaches it to the lesson with the description and criteria,
`omumu_assignment_update` publishes it (the Courses & Content chapter has the tools). In
the admin, the course overview's *Assignments* card lists them; *New Assignment* takes
the title, description, rating prompt, where it is attached, the check-in light switch
and *Email staff when a student hands in* (on by default), and lands on the list as a
draft; *Edit* has the *Status* switch that publishes.

Below the form, *What the rater can read* lists every item in the assignment's scope —
lesson descriptions, text, recordings, files, checklist items, links — as readable or not,
with the reason: a recording with no transcript, a scanned PDF, a file linked from outside
Omumu. Recordings can be transcribed from there; the page says how many of your plan's
minutes it will use before it starts. If the rater's feedback misses your method, this
list is where to look.

### What the student does

On the lesson page, under the content and the checklist, the student sees the
assignment's brief, the Light choice if asked, a text box and a file field; *Submit*. The
file uploads at once and shows its name. After submitting, the AI's feedback appears on
the submission page within seconds, with every earlier submission underneath. A student
with a Light can hand in again each week and watch the thread grow.

### What the AI does with a hand-in

Say Mira's rating prompt asks for encouragement and a concrete next step. A student hands
in a yellow check-in with a list of five tasks and a note that she is unsure which to
automate. The feedback names the tasks, points at the easiest first win, acknowledges the
yellow without arguing with it, and suggests a next step. A file-only hand-in of a PDF or a
screenshot is read like text; a video is read through its transcript. The rater writes
sourced facts into the student's folder as it goes, so the next feedback starts from what
it already knows.

### Read, confirm, write

Mira opens the hand-in and reads the AI's feedback above the form. She writes her own —
*Feedback* and an optional score from 1 to 10 — and *Save feedback*; her words show above
the AI's. If the hand-in carries a Light, *Confirm I have seen this Light* records that a
human has read it. Two separate actions today: writing feedback does not confirm the
Light by itself.

Getting to the hand-in: *Customers → Users*, the student, *Submissions*, and the entry
you want — each marked seen or not seen. There is no page yet that lists hand-ins
waiting for feedback across students; the staff email on each hand-in is the queue in the
meantime.

### Run the board

*Customers → Mentor Board* shows every participant with their latest Light and its date,
whether it is seen, days since their last hand-in, and progress, filtered by course. An
unconfirmed red at the top of the list is who you call this week; a long gap since the
last hand-in is who has gone quiet. *Mark seen* confirms a Light from the board.

### Who hears what

Staff are emailed on every hand-in, with yellow and red called out in the subject — a
per-assignment switch, on by default. The student is emailed when a staff member writes
feedback (not for the AI's), a site-wide setting under *Settings → Business Details →
Notifications* that is on by default and can be turned off. For anything else — a tag
when work comes in, a sequence after a review — the Submission Received, Rated and
Reviewed triggers in the Automations chapter do it.

### What you cannot do yet

Stated plainly: there are no tools for hand-ins — your assistant can create and publish
assignments but cannot read a submission, write feedback or confirm a Light. There is no
review queue across students; no due dates; no quizzes inside a course (quizzes live under
Sales and marketing and are for finding out who someone is, not for checking what they learned).
*Delete* on the people list disables the account rather than erasing the person's data;
permanent erasure is coming. And the Mentor Board counts you, the Headmaster, as a
participant of your own courses.

## Reference

No MCP tools cover this chapter's capabilities yet.