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 every possible profile to exactly one named support plan. The lookup is deterministic: the same profile, evaluated against the same table version, always returns the same plan. There is no randomness and no generative step.

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 plan.

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.

What a plan is made of

Every plan has three parts. The balance across the parts is fixed per plan, and the anchor is always the largest share.

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 remains active, with its status tracked through a defined lifecycle: recommended, in review, activated, being monitored, and eventually exited or adjusted. The lifecycle is transparent: the teacher can see at any moment what stage the plan is at for each child.

Related pages

• Grouping and Activation: how children with similar plans are grouped and how the teacher activates them.
• Task Delivery: how the platform picks and serves the specific tasks a child practices.
• Content and Items: where those tasks come from and how they are prepared.
• How Amal Works: the full teaching cycle these plans sit inside.