SPECIAL EDUCATION MEASUREMENT BUILD

IEP progress monitoring software, built around how each goal is actually measured

For US districts and edtech teams whose progress data is one column staff have learned to round. We build the measurement layer: a model per goal type, capture where the instruction happens, and the report cycle the plan already promised the parent.

Every requirement on this page cites the section of federal regulation it comes from.

Progress monitoring is where a special education system earns its keep or quietly stops being true. The plan sets the goals, federal regulation says progress toward them must be measured and reported, and the data that proves it is collected by people working at speed in classrooms and hallways. Get the capture wrong and every chart above it is decoration.

This page is for a district whose progress data cannot answer a parent or a State report, and for an edtech company building the measurement side of a special education product. Bles Software builds custom software, AI agents and integrations from Israel for clients in the US, the UK, the EU and Israel. We have no progress monitoring product to sell you. We build the measurement layer your process needs, or fix the one you own.

Where measurement actually breaks

Three different builds hide behind one complaint about progress data. Naming yours is the cheapest hour of the project.

Capture in the room

The screen a paraprofessional uses between two prompts. Offline, on a phone, with the goal and its measurement type already on it.

Application development →

The data on its way out

The student information system, the assessment platform and the State extract, each wanting the same progress record in a different shape.

Integration services →

The document it hangs off

The plan, the compliance clocks and the audit trail behind a signed change. Measurement hangs off that record, so the two builds get scoped together.

IEP document and clocks →

A goal is not one number, so do not give it one column

34 CFR 300.320(a)(2)(i) requires measurable annual goals, academic and functional. Paragraph (a)(2)(ii) adds benchmarks or short-term objectives for children who take alternate assessments aligned to alternate academic achievement standards. Nothing there says those goals share a scale, and they do not.

Frequency per minute, trials correct out of N, a rubric level, a duration and a latency are five data types with five valid ranges and five ways of being wrong. Model the goal type first, then the measurement it accepts. A single progress column makes a paraprofessional convert a rubric level into a percentage at the moment of entry, and that is where the data stops being real.

Capture happens in a hallway, not at a desk

The case manager is not the person holding the data. A paraprofessional is, between two prompts, on a phone, usually with no signal, while the child waits. A screen that needs three taps and a network round trip does not get used, and Friday becomes a reconstruction from memory.

Offline first is not a feature here, it decides whether the data exists. Queue on the device, stamp each observation with the person and the time it was taken rather than the time it synced, and settle the conflict rule in the schema before the first sync: trials append, a scored judgement keeps its earlier value in history. Decide it once or every team decides it differently.

The report cycle is a promise inside the document

34 CFR 300.320(a)(3) requires the IEP to describe how progress toward the annual goals will be measured and when periodic reports on that progress will be provided, such as through quarterly or other periodic reports, concurrent with the issuance of report cards. That is a per child commitment written into the plan, not a district wide calendar.

So generate the cycle from the record. The plan states its cadence, the system derives the next due date per goal, and the report carries the data points behind the sentence a parent reads. The alternative is a spreadsheet somebody maintains: it survives one school year, one staff change kills it, and nobody notices until a parent asks where the second quarter report went.

Lack of expected progress is a trigger, not a chart

Under 34 CFR 300.324(b)(1)(i) the IEP Team reviews the plan periodically, and not less than annually, to determine whether the annual goals are being achieved. Paragraph (b)(1)(ii)(A) then has it revise the plan to address any lack of expected progress toward the goals and in the general education curriculum. A team that first sees the trend at the annual meeting has already spent the year.

Define expected progress per goal as a rate against its target date and raise the case when a goal falls off that line, weeks before the review. Then build two write paths. One is the annual meeting. The other is 34 CFR 300.324(a)(4)(i): after that meeting the parent and the agency may agree not to convene and instead develop a written document amending the IEP. Different record, different consent, different audit trail.

Access, destruction and who may touch the record

34 CFR 300.613(a) gives parents the right to inspect and review education records without unnecessary delay and before any meeting regarding an IEP, and in no case more than 45 days after the request. The clock opens on the request and can close early when a meeting is scheduled. Progress data spread across a capture app, a reporting table and an export job is not one readable record unless it was built to be.

Destruction has its own shape. Under 34 CFR 300.624(a) and (b) the agency must inform parents when the information is no longer needed to provide educational services and must destroy it at their request, while a permanent record of name, address, phone number, grades, attendance record, classes attended, grade level completed and year completed may be kept without time limitation. That carve out is a table boundary, drawn before the first row.

The same question applies to everyone holding a login, us included. 34 CFR 99.31(a)(1)(i)(B) lets a contractor count as a school official on three conditions: the outsourced institutional service, direct agency control over the use and maintenance of education records, and the redisclosure limits in 34 CFR 99.33(a). Paragraph (a)(1)(ii) wants reasonable methods so a role reaches only records it has a legitimate educational interest in, and 34 CFR 300.623(d) makes the agency publish the names and positions of everyone who may see personally identifiable information. Your role table is that public list, so design it as one.

State reporting is an export you design at the source

Each State must collect valid and reliable information as needed to report annually to the Secretary on the indicators set for State performance plans (34 CFR 300.601(b)(1)), and must examine data on significant disproportionality by race and ethnicity in identification, placement in particular educational settings, and the incidence, duration and type of disciplinary removals (34 CFR 300.646(a)), using the risk ratio methodology in 34 CFR 300.647.

Read that as required dimensions on the rows your capture app writes. An observation without the student, the goal, the setting and the date cannot be aggregated later, so someone rebuilds the submission by hand each spring. Agree the export format and its field list with whoever files the State submission before the first screen is designed.

What AI may draft here, and what it may not conclude

Two narrow places: drafting the narrative of a progress report from data points already collected, and flagging goals trending off the pace needed to reach the target date. It must not decide whether a goal was met, or anything about eligibility or placement. Keep the observation as the source of record, log what was suggested against what a person kept, and leave the teacher as the author the parent reads.

How we scope a progress monitoring build

Four steps in this order, because each sets the cost of the next.

1

1. Sort one real term of goals

Take the goals live in your plans now and sort them by how they are measured. That list is the data model, and it is shorter and stranger than anyone expects.

2

2. Design the capture before the dashboard

One screen per goal type, offline, on the device the person collecting carries. Conflict and correction rules written down before the first sync, not after the first argument.

3

3. Derive the cycle and the trigger

Report dates and off pace flags come out of the plan record, so no calendar needs an owner and nothing waits on somebody remembering.

4

4. Prove the three exports

The parent report, the complete record for a 300.613 request, and the State extract with its fields. One goal type in production first, then the rest.

Questions districts and edtech teams ask about progress data

What does federal regulation require us to measure and report?

Two things, both in 34 CFR 300.320(a)(3): how the child's progress toward meeting the annual goals will be measured, and when periodic reports on that progress will be provided, such as through quarterly or other periodic reports concurrent with the issuance of report cards. The goals themselves must be measurable under (a)(2)(i).

How do you model goals that are measured in completely different ways?

Goal type first, measurement second. A frequency per minute, a trials correct out of N, a rubric level, a duration and a latency each get their own record shape, valid range and chart. One progress percentage for everything looks tidy in a demo and produces numbers nobody in the building believes.

Our data is collected on phones with no signal. Does offline capture really work?

It is the only thing that does. Entries queue on the device, sync when a network appears, and the conflict rule is settled in the schema rather than by whoever taps last. Without it, observations get reconstructed from memory at the end of the week, which is the real data quality problem in most districts.

How often does a parent have to receive a progress report?

As often as that child's plan says. 34 CFR 300.320(a)(3)(ii) requires the document to state when periodic reports will be provided, and offers quarterly or other periodic reports concurrent with report cards as the example. Because the cadence lives in the document, generate the schedule from the record, not from a calendar somebody maintains.

Where does AI help here, and where must it not decide?

Drafting the narrative of a progress report from data points already collected, and flagging goals trending off the pace needed to reach the target date. It must not decide whether a goal was met, or anything about eligibility or placement. Log what was suggested against what a person kept, and leave the teacher as the author.

What should the system do about a lack of expected progress?

Surface it early, then open the right write path. 34 CFR 300.324(b)(1)(i) has the team review, not less than annually, whether the annual goals are being achieved, and (b)(1)(ii)(A) has it revise the plan to address any lack of expected progress. Between meetings, 34 CFR 300.324(a)(4)(i) lets the parent and the agency amend the IEP in writing instead of convening.

A parent asked to inspect the progress data, and another asked us to destroy it. What does the system owe them?

Inspection without unnecessary delay, before any meeting regarding an IEP, and in no case more than 45 days after the request (34 CFR 300.613(a)). Destruction at the parent's request once the information is no longer needed for educational services, with the named permanent record fields in 34 CFR 300.624(b) as the carve out.

Can it produce what the State asks for on indicators and disproportionality?

Only if the source rows carry the dimensions. The State submission needs the indicator data in 34 CFR 300.601(b)(1) and the disproportionality data by race and ethnicity in 34 CFR 300.646(a), across identification, placement and disciplinary removals. Those fields belong on the observation when it is written, not in a spreadsheet rebuilt each spring.

No spam. Just a practical audit.

Ready to remove your biggest software bottleneck?

Book a free 15-minute call. We will help you identify the highest-leverage automation, API integration, AI agent, or internal system to build first so your team can move faster with less manual work.