Progress Monitoring

The progress monitoring engine (WP-PROG-MON) answers one question: is this bundle working for this student? It records non-CBM evidence, applies a stack of safety rules and per-bundle recipes, and emits a deterministic verdict, all without ever moving a tier, auto-failing a plan, or touching the student surface.

Progress monitoring handles comprehension, vocabulary, morphology, and other non-fluency evidence. Fluency (reading speed + accuracy) is handled separately; see CBM & ORF Fluency.

The five global safety rules (GSR-01..GSR-05)

Every monitoring decision passes through these rules in order. Any rule that fires halts further processing and returns do_not_decide_yet.

Rule	Description
GSR-01: Insufficient Evidence / Tie Rule	If evidence is insufficient or the signals tie, the verdict is `do_not_decide_yet`. The teacher is shown a quiet “need more data” hint (no red badge, no alert)
GSR-02: Acute Regression	A drop of ≥20% across 2 comparable sessions triggers an `acute_regression_alert`. This is an Immediate Review signal, never an auto-fail and never an auto-exit from the bundle
GSR-03: Benchmark Gap-Closing	Benchmark comparisons are valid only at review windows (BOY / MOY / EOY). Comparisons mid-window are rejected
GSR-04: Comparable Data Guardrail	Only evidence rows that share the same `comparabilityKey` (tool, context, conditions) are compared against each other
GSR-05: No Single-Point Decision	A single evidence record cannot alone determine a verdict. The engine requires a minimum window of comparable points

The 12 per-bundle PMR rules and 19 Intervention Success Criteria

On top of the GSR stack, the engine applies:

PMR-001..012: per-bundle monitoring recipes. Each recipe specifies which tools generate comparable evidence for that bundle, what the evidence-weight cap is for each tool, and when to re-evaluate.
ISC-001..019: per-bundle success criteria. One criterion row per bundle definition describes what “this bundle worked” looks like in measurable terms.

The engine is fail-closed on a missing recipe or criterion: a catalog defect raises an error rather than producing a silent default verdict.

The five verdict values

Verdict	Meaning
`positive`	Evidence consistently supports the plan is working
`partial`	Some evidence is positive but the picture is mixed
`no_response`	Evidence shows the plan is not producing a response
`do_not_decide_yet`	Insufficient or tied evidence; wait for more data
`acute_regression`	≥20% drop in 2 comparable sessions; Immediate Review required

Recording evidence

POST /api/monitoring/evidence accepts a non-CBM probe. Sending a CBM modality returns 422 cbm_scope_restricted. CBM evidence belongs to the CBM module.

The server runs a deterministic recompute on every evidence write. The sequence:

Materialize an active monitoring_plan (lazily created on first evidence, pinning the PMR recipe and ISC criterion).
Write the evidence row, keyed on (studentId, monitoringPlanId, measurementTool, occurredAt) for idempotency.
Recompute the monitoring status and write an append-only monitoring_status_review row pinning every rule version used.

The first evidence write for a new plan triggers two recomputes: one before and one after the row is persisted. This is expected and deterministic.

Evidence tools

Tool	Scope
`quick_check`	Short in-session checks, vocabulary or morphology probes
`rubric`	Scored rubric observed by the teacher
`teacher_observation`	Structured observation note (no free text; disposition is from a closed vocabulary)
`worksheet_evidence`	Paper or digital worksheet scored by the teacher
`digital_trend`	Platform-generated trend from practice-session response data

Each tool has a weight cap. No single tool can dominate the decision past its configured percentage. The cap is enforced at the evidence-writer level before the recompute runs.

Acute-regression alert lifecycle

An acute_regression_alert moves through two states:

Status	Description
`open`	Newly created; blocks cluster membership for this student (SCS_03 / QA_004)
`resolved`	Dismissed or escalated by the teacher via `/api/workflow/review`

Resolution requires a reason code from the 9-code OverrideCodeCatalog. A context flag may optionally accompany the dismissal but is recorded separately in context_flag_log, not on the alert row itself.

An acute-regression alert is never an auto-fail. The bundle assignment status is never mutated by the alert. Only the teacher can change plan status (V-12).

Determinism and versioning

Every monitoring_status_review row pins the version of every rule it read: the GSR snapshot, the PMR recipe, and the ISC criterion. A later change to the rule config does not re-run stored windows. This is V-6: same inputs + same version = identical output, forever.

API endpoints (3)

Method	Path	Purpose
`POST`	`/api/monitoring/evidence`	Record a non-CBM probe → triggers deterministic recompute
`GET`	`/api/monitoring/status/{bundleAssignmentId}`	Active plan + latest verdict + comparable/excluded evidence partition
`GET`	`/api/monitoring/alerts?status=open&type=acute_regression`	Teacher/admin acute-alert list

For full request/response shapes see the API Reference.

CBM & ORF Fluency: fluency/accuracy monitoring (separate module)
Intervention Bundles: PMR recipes and ISC criteria are keyed to bundles
Teacher Activation Workflow: the surface where teachers resolve acute-regression alerts
Safety Rules: the GSR rules in the broader context of the platform’s safety model