Skip to Content

Intervention Plans

When the platform has a clear enough picture of what a child needs, it proposes a support plan. The plan comes from a curated, closed catalog, not from an algorithm generating something new for each child. The teacher reviews the proposal, adjusts it if they want, and either confirms it or sets it aside. Nothing reaches the child until the teacher acts.

How a plan is matched to a child

The platform builds an educational profile for each child by interpreting the evidence across their reading skills and areas. That profile belongs to a fixed set of named types. Once the profile is known, the platform looks it up in a 21-row table that maps each profile to a recommended next step. The lookup is deterministic: the same profile, evaluated against the same table version, always returns the same recommendation. There is no randomness and no generative step.

Most profiles map to a named support plan from the catalog. But not every profile leads to a plan. Some rows in the table point instead to a lighter response: a short monitoring process to keep watching the child for now, or a small, targeted light-support action rather than a full plan. For those paths, no intervention plan is written; the recommendation is simply to watch or to apply the light action, and the teacher reviews that recommendation the same way they would review a plan. A valid recommendation, in other words, can be “keep monitoring” or “a light touch” rather than a full support plan.

Some profiles have meaningful sub-types. A child with a reading access gap, for example, may be primarily struggling with decoding letters, with accuracy under speed, or with fluency specifically. The table accounts for these differences. When the sub-type matters, the match keys on both the profile and the sub-type, producing a more targeted recommendation.

If the evidence is not yet sufficient to form a clear profile, the platform stops and says so. It names the specific data step that would resolve the gap, and no plan is proposed until that step is completed. There is no placeholder plan and no way to override this: the system waits because an under-informed plan can do more harm than waiting. This is a distinct outcome from a clear profile that maps to monitoring or a light action: in the data-gap case the platform cannot yet describe the child at all, whereas in the monitoring case it can, and is choosing a deliberately light response.

What a plan is made of

Every plan has three parts. The balance across the parts is expressed as ranges that accumulate across a full cycle of sessions, not as a fixed split applied identically to every single session. Across the cycle as a whole, the anchor is always the largest share.

PartShare of instructional time across the cyclePurpose
Anchor40 to 60 percentThe main focus: the primary skill group the plan targets. Across the cycle, the anchor is always the largest single share.
Supporting threads25 to 35 percent combinedOne or two skills related to the anchor that reinforce the work or address adjacent gaps. A plan has at most two supporting threads.
Strength bridge10 to 15 percentBuilt on a domain where the child is already doing well, used as a confidence anchor or entry point.

Because these are cumulative-cycle ranges, an individual session can lean more heavily on one part while another session balances it out; what the platform guarantees is that, totalled over the cycle, the shares land within these bands and the anchor remains the largest.

The strength bridge is only included when the evidence actually shows a documented area of strength. If the data does not support it, the share is not artificially assigned elsewhere; instead the anchor absorbs it and the bridge language in the plan becomes neutral rather than specific.

The three-part structure is called the Threaded Path Model. The code that computes the final time shares enforces the anchor-strictly-largest rule at both the recommendation step and the activation step. A configuration that violates this is caught before it can reach the teacher.

Scaffold levels

Within any plan, each skill has a scaffold level that governs how much support a task provides for that child on that skill. There are three levels: Foundation, Targeted, and Independence.

The level is set per skill, per plan, and per task type, not across the whole child. A child may be at Foundation on their main anchor skill and at Independence on a supporting skill in the same plan. These are not global assessments of the child’s ability; they are task-design parameters that change as the child progresses. The scaffold level is never shown to the child in any form.

The initial level is derived from the skill’s current status. A skill showing a broader weakness starts at Foundation. A skill that needs targeted work but is not severely weak starts at Targeted. A skill flagged for monitoring with reasonable evidence starts at Independence. When a child has had a sharp, recent drop in performance on a skill, the system holds their scaffold level rather than stepping it down automatically: the drop triggers a human review first.

What the teacher sees and controls

The teacher sees the plan proposal with its structure laid out: which skill is the anchor, which are the supporting threads, whether a strength bridge was identified, and the suggested share of instructional time across the three parts. The teacher can:

  • Confirm the plan as proposed.
  • Adjust individual parameters: the delivery format, the schedule, a scaffold level for a specific skill with a selected reason.
  • Replace the plan with a different one from the catalog, again with a reason from the provided list.
  • Decline to activate and return to monitoring.

Every change goes through a controlled list of reasons. There is no free-text field for a reason. This is intentional: free-text notes about children and their needs are never stored by the platform.

If the teacher changes a scaffold level from what the plan proposed, the platform asks for explicit confirmation before saving. A change that reduces the level of support for a child is a meaningful choice, and the platform records it, including the reason code, so there is a traceable record.

Plans and evidence over time

A plan that was never delivered is not the same as a plan that failed. The platform tracks whether support was actually given before drawing any conclusions about its effect. If a plan’s tasks were not completed, the monitoring layer does not treat the gap as a failure of the plan itself.

The plan’s status is tracked through a defined lifecycle: recommended, in review, activated, being monitored, and eventually exited or adjusted. Alongside this, the platform tracks a separate delivery-continuity status. If a plan goes for three instructional weeks in a row with none of its planned sessions actually delivered, it is marked off-track. While a plan is off-track, the platform holds all automatic movement to a different level of support until the teacher resumes it; a resumed plan is then watched for fresh evidence before any judgment is made. The lifecycle is transparent: the teacher can see at any moment what stage the plan is at for each child, and whether it is on-track or has drifted off-track for lack of delivery.

How Amal Works