Skip to Content

Task Delivery

When a child sits down to practice, the platform selects a task and serves it. The selection is precise: the platform looks at the child’s current skill focus, their scaffold level for that skill, the task mode, and the difficulty range, and finds a stored item in the bank that matches. It serves the item exactly as it was authored. Nothing is composed, modified, or generated at this step.

The item-bank-only principle

All tasks that reach children come from a pre-built, pre-validated bank of items. Each item in the bank was written and reviewed offline, passed through validation checks, and was cleared by a subject-matter expert before being marked ready to use. By the time an item appears in a session, it has already been checked for Arabic correctness, appropriate difficulty, and language safety.

This means the delivery step itself is deliberately simple. The platform does not assemble new content at runtime, does not call a language model to generate or adapt a task, and does not improvise based on how the session is going. The same stored task, served to different children, is identical across both of them. What changes is which task is selected, not what the task says.

How selection works

Every task request specifies a context. The delivery engine applies a set of filters against the pool of ready items and narrows it to candidates that fit. The filters applied, in combination, are:

Sub-skill match. The task must target the exact reading sub-skill being practiced or assessed. There are no approximate matches; a task for one sub-skill is not substituted for a task for a different one.

Task mode. Tasks come in three modes: practice, quick check, and probe. Each mode has its own purpose and its own rules about how it is presented, what scaffolding it includes, and how the result is used. A practice task is not the same as an assessment probe, and the two are never interchanged.

Scaffold level. For practice and quick-check tasks within an active support plan, the delivery engine looks up the child’s scaffold level for the relevant skill. It filters to tasks authored at that specific level. A child at Foundation level receives tasks designed for Foundation. A child at Independence level receives tasks for that level. The engine does not choose a level at runtime; it looks up the level that was set by the plan and confirmed by the teacher.

Probe tasks used for assessment are an exception: they select without a scaffold-level filter because the point of a probe is to observe the child’s performance without structural support, regardless of where they are in a plan.

Difficulty band. The bank records an estimated difficulty for each item based on its linguistic properties: the reading level of its vocabulary, the cognitive demand of the question, the sentence length, and the answer format. Items are grouped into five bands from very easy through very hard. The delivery engine requests a band or a range of bands appropriate for the child’s current context. This is a preference, not a hard gate: if the exact target band has no eligible item, the engine looks for the closest match within the eligible candidates, not across sub-skills.

Dialect and language form. Items may be tagged for Modern Standard Arabic, for a regional dialect, or left untagged, which makes them agnostic. An untagged item is eligible for any session. Tagged items are filtered to match the session’s language context.

Audio. Some task modes require audio. When audio is required, only items with a recorded audio file are eligible.

Recent history. Items served to the same child in the recent past are excluded. This prevents the same item from appearing twice in close succession for the same child.

How the engine picks among eligible items

After filtering, the engine may have several candidates that all pass every check. It picks among them through a fully deterministic tie-break, applied in the same order every time:

  1. Closest to the requested difficulty band first. If a band of “medium” is requested and there are items at medium and items at hard, the medium items come first. An item with no difficulty estimate ranks last.
  2. Among items equally close to the target band, the item with the lower difficulty prior comes first.
  3. Among remaining ties, items are ordered by their unique identifier, which is a stable alphabetic sort. The first item in this order is served.

The result of this process is always the same for the same inputs. If the same session context were run again with the same set of available items, the same item would be selected. This is intentional: it makes past decisions reviewable and keeps the system predictable.

When no item qualifies

It is possible for all items in the bank to fail at least one filter. When this happens, the platform does not substitute a different sub-skill’s item, does not lower the scaffold level without being asked, and does not serve an item that does not match. Instead it returns a clear response indicating that no eligible item was found, with a note on which combination of filters produced the empty result.

This response is not an error. It is a signal that the item bank has a gap for this particular combination of sub-skill, scaffold level, task mode, and possibly dialect. Every such gap is recorded. The record feeds an admin view that aggregates gaps by sub-skill and level so that offline content authors can see exactly which combinations need new items.

What the platform logs about each serve

Every task served creates a permanent record. The record captures which item was served, which child received it, the session context at the time of the serve, the scaffold level and rule version used, and the difficulty band of the item. This record is used to enforce the recent-history filter and to allow a replay: given the same context, the same selection logic, and the same pinned bank version, the platform can reproduce which item would have been chosen and verify that it matches what was actually served.

What delivery does not do

The delivery step has a defined scope. It does not write scores or record the child’s answer; that is the session layer’s job. It does not update the scaffold level; that is updated through the plan management layer based on monitoring evidence. It does not decide whether a session should happen; that is the teacher’s decision. And it is not accessible by children directly; there is no delivery endpoint that operates without a teacher or administrator’s authorization.

How Amal Works