Evidence and Review
A change in a child’s support level is one of the most consequential decisions the platform is involved in. To make sure such decisions are deliberate, grounded, and reviewable long after they are made, the platform maintains a dedicated evidence layer that assembles all relevant information about a child into a structured dossier, and a review-and-approval workflow that a proposed change must pass through before it takes effect.
This page describes how the evidence is assembled, how the review workflow operates, and why the architecture makes a tier change without a documented decision structurally impossible.
The student data room
For every child who has an active plan, the platform maintains what it calls the student data room: a per-student collection of decision-relevant evidence assembled from across the platform. The data room is not a place to store notes or impressions. It is a structured reference that pulls together the skill-status picture, the monitoring verdicts, the fluency trend, the fidelity rate, the current profile, and the tier-review history into one place.
The data room is refreshed automatically when the underlying evidence changes, and it can also be refreshed on demand. Each refresh recomputes a set of summary blocks: the current reading status per skill, the overall reading area picture, the progress monitoring verdicts, the fluency signal, the delivery rate, and a data-sufficiency assessment that indicates whether there is enough evidence to support a decision at all.
The sufficiency assessment matters because a data room that looks complete may still lack the depth needed to support a confident recommendation. The platform distinguishes between having some evidence and having enough comparable, recent, consistent evidence. When the dossier is thin, the sufficiency assessment reflects that honestly, and the downstream review workflow responds accordingly.
The data room never decides anything. It assembles and presents; the rules in the measurement, monitoring, and tier layers still decide. The data room makes those decisions show their work.
The evidence index
Within the data room, the platform maintains an evidence index: a catalog of references to each piece of supporting evidence, with a flag indicating whether a given piece has been included in the current active decision packet.
The index refers to evidence; it does not copy it. Skill-status results, monitoring records, fluency readings, and fidelity data all live in their own modules and are referenced here by record identity. This keeps the data room’s content synchronized with the underlying records automatically: if a monitoring record is added, the next refresh picks it up without any manual update.
Evidence can be filtered by type, by validity status, and by whether it has been included in a packet. This lets a teacher or a specialist review the complete picture and compare what went into a formal decision against what was available at the time.
Decision packets
When a teacher or specialist opens a formal support-level review for a child, the platform opens a decision packet alongside the review request. The packet is a point-in-time snapshot of the evidence that will be used to support the proposed decision.
Opening the packet pins the versions of all the rules that were current at the moment of opening. This is the mechanism that makes past decisions auditable: a reviewer looking at a closed packet sees not just the evidence but the exact rules that were applied to interpret it. The platform would produce the same recommendation given the same evidence and the same rule versions, forever.
The packet moves through a defined set of states. It starts as a draft, becomes available for review, and is closed as either approved or rejected when a decision is made. Once closed, its contents are permanent.
A packet cannot be opened while one is already active for the same child. This prevents concurrent or overlapping formal reviews for the same student, which would create ambiguity about which review’s outcome should apply.
The review and approval workflow
The workflow that uses the decision packet follows a linear sequence. No step can be skipped, and the platform enforces the sequence at each transition.
When a formal review is opened, the packet is populated with a snapshot of the evidence indexed in the data room. The platform then computes a recommendation by applying the movement rules to the evidence in the packet. This recommendation, the proposed direction, and its reasoning are visible to the reviewer, but at this stage nothing has changed. The recommendation is an analysis, not a commitment.
The reviewer, the teacher for standard movements or the specialist for the most intensive support level, reads the recommendation and the evidence and then approves or rejects. Approval is the only action that triggers a change. Rejection closes the review with no change and no movement.
If the decision packet signals that the evidence is not yet sufficient to support a recommendation, the review is deferred. A deferred review is not a failure; it is the correct response to incomplete data. The teacher can return when more evidence has accumulated.
If the sentinel conditions that block movement are active (the skill-status layer returned a “not enough to decide yet” result, or the fidelity gate has not been passed, or the data-sufficiency assessment is below the required level), approval is rejected by the platform even if the human reviewer selects it. The gates run before the approval is accepted.
The tier change and the decision record
When an approval is accepted, the platform writes two things in one atomic operation: the tier change, and the tier decision record. These two writes cannot be separated. The tier decision record is an append-only permanent entry that contains the decision type (escalation, de-escalation, or maintenance), the decision direction, the approver, the timestamp, the linked decision packet, and the applied movement-rule versions.
A tier change without a decision record is structurally impossible. The code that applies the change is the only place in the entire platform that can update a child’s support level, and it always writes the decision record in the same transaction. If the transaction fails for any reason, both writes are rolled back and the child’s level is unchanged. There is no path through which the level changes but the record is not written.
This is not bookkeeping added after the fact. It is the architecture: the decision and the evidence are bound together at the moment of change, and the binding is permanent.
What the decision history looks like
A teacher or specialist can view the complete tier-decision history for a child: a chronological list of every formal support-level review, what was decided, who decided it, when, and which evidence was in the packet at the time. This history does not change. Entries are never removed or amended.
For any historical decision, the platform can reconstruct exactly what recommendation it would have produced given the same evidence and the same rule versions. This means that if a question arises months later about why a child was moved to a particular level of support, the record is not just a log entry but a fully auditable chain from the raw evidence to the final approved action.
Who has access
Teachers can open a data room for any child in a class they teach. Administrators and specialists can see the data room for children in their organization. Children and parents cannot access the data room or any decision packet. Support-level information never appears in student-facing or parent-facing views, in any form, at any point.
Evidence submitted through this layer is always in the form of structured, controlled information. There are no free-text fields for notes about a child. Any contextual information that needs to be recorded alongside a decision is drawn from a closed list of context options, not from open input. This constraint applies throughout the evidence and review process without exception.