Programming Sheets and Procedural Fidelity

Making sure two paras run the same program the same way

For paraprofessionals and the teachers who supervise them

| |

| :-: |

| The frameWhen two adults implement the same program two different ways, the student gets two different interventions. Programming sheets are the tool that prevents this. A well-written programming sheet tells any trained staff member exactly what to do, in what order, with what prompts, and how to record the outcome. Procedural fidelity -- checking whether the program is being run as written -- is what keeps quality consistent over time. |

Why this matters

Special education programs work because they are implemented systematically and consistently. Research on applied behavior analysis, structured literacy, and other evidence-based practices consistently shows that fidelity to the program is one of the strongest predictors of student outcome. When one para uses a least-to-most prompt hierarchy and another uses a most-to-least approach for the same student goal, the student is receiving inconsistent instruction -- and the data collected along the way cannot be meaningfully compared.

Programming sheets are not bureaucratic paperwork. They are the translation of a teacher's or specialist's program design into an actionable, replicable procedure that any trained staff member can follow.

What a programming sheet contains

Student and goal identification

Every programming sheet starts with the student's name, the IEP goal or objective it supports, the date the program was written, and the name of the supervising professional who designed it. This is not optional. A para should never run a program they cannot trace to a goal and a designer.

Antecedent conditions

This section describes exactly what the para does or says to set up the learning opportunity:

The instruction or discriminative stimulus (SD): the exact words or gesture the para uses to present the task

Materials: what objects, cards, worksheets, or technology are needed

Setting: where the session occurs (table, carpet, community setting)

Student positioning: seated, standing, facing the para or the materials

Time of day or routine: when the program runs in the student's schedule

Response definition

The correct response must be defined with enough precision that two different observers would agree whether it occurred. Vague language like 'student responds correctly' is not adequate. Better: 'Student points to the named picture within 3 seconds of the SD without prompting.' The response definition should also specify what counts as an error and what counts as no-response.

Prompting procedure

This section specifies which prompting strategy is used (least-to-most, most-to-least, time delay, etc.), what each prompt level looks like, and how long the para waits between prompt levels. Example: '3-second wait, then verbal, then model, then physical -- fade physical first.' See Brief 04.02 for prompting hierarchy details.

Reinforcement

Specify what reinforcement is used (praise, token, tangible), when it is delivered (immediately after correct independent response vs. after prompted response), and at what schedule (every correct response, every third, etc.). Also note whether prompted responses earn the same reinforcement as independent responses -- in many programs they do not.

Data collection

How does the para record each trial? Options include: plus/minus per trial, prompt level per trial, percent correct per session. The programming sheet specifies the data sheet, where it is stored, and how often data is reviewed.

Error correction procedure

When the student makes an error, what happens next? Common procedures: model-lead-test (show the correct response, do it together, test again); back-up prompt immediately; repeat SD with full prompt. The sheet should be specific. 'Correct errors' is not a procedure.

Mastery criterion and next steps

When is the goal considered mastered? Typical criteria: 80% correct across three consecutive sessions, or 90% correct with two different staff members. The sheet also specifies what happens next -- move to the next step, probe generalization, or transition to maintenance.

Procedural fidelity checks

What fidelity checking looks like

A fidelity check is a structured observation in which a supervisor watches the para implement the program and scores each step as implemented correctly or not. A simple fidelity checklist lists every step on the programming sheet and has a yes/no column. The resulting score (e.g., 14 of 16 steps correct = 88% fidelity) tells the supervisor how closely the program is being followed.

How often fidelity is checked

Research suggests fidelity checks are most important when a program is new, when data shows unexpected patterns, and after any staff change. A reasonable minimum: once per quarter for stable programs, once per month for new programs, and any time the program designer suspects drift.

What to do with fidelity data

Low fidelity does not automatically mean the para made a mistake. Sometimes the problem is in the program itself -- the instructions are ambiguous, the materials are hard to manage, or the antecedent is not practical in the real setting. A good fidelity debrief asks both 'what did the para do differently?' and 'does the program need to be revised?'

Calibration sessions

Before a new program launches -- or after a significant update -- schedule a calibration session in which all paras who will run the program practice it together, receive feedback, and reach agreement on what each step looks like. This is especially important for subjective steps like 'provide minimal physical prompt.' See Brief 03.02 on para training and supervision.

Documenting program changes

Programs evolve. When a teacher or specialist modifies a program -- adjusts the prompt hierarchy, changes the mastery criterion, adds a new step -- those changes must be documented on the programming sheet with a date and the initials of the person who made the change. Running a program from an outdated version is a fidelity failure even if the para is doing exactly what the sheet says.

Keep prior versions of programming sheets. If a student's progress stalls, having the program history allows the team to identify when things changed and whether the change may have contributed to the plateau.

Scenarios

Scenario A: The para improvises

Marcus runs a discrete trial program for labeling pictures. His programming sheet specifies a 3-second time delay before the first prompt, but Marcus has started prompting immediately because the student 'seems to need it.' When the supervising teacher reviews the data, she notices the student's independence rate has dropped. A fidelity check reveals Marcus's deviation. The fix is not to reprimand Marcus but to review why he changed his approach, retrain on time delay rationale, and monitor again.

Scenario B: Two paras, two programs

Elena and DeShawn both work with the same student on a communication board program. Elena learned the program from the SLP in September; DeShawn started in November and was trained verbally by Elena. By January, their implementations are meaningfully different. A side-by-side fidelity check reveals the divergence. The solution: go back to the programming sheet, run a joint calibration session, and commit to written updates instead of verbal hand-offs.

| | |

| :-: | :-: |

| Try this | Watch out for |

| Follow the programming sheet exactly as written, even if you think you know a better way -- bring improvement ideas to the supervising teacher | Modifying a program on your own -- even with good intentions -- creates inconsistency and makes the data uninterpretable |

| Date-stamp any note you make on a program, so the team knows when it changed | Running an old version of a program because you did not know it had been updated |

| Ask for a fidelity check when you are new to a program or uncertain about a step | Skipping data collection steps because the session felt successful |

| Store all programming sheets in one consistent, accessible place | Assuming verbal training is sufficient -- always get the written program before you begin |

| |

| :-: |

| Bottom lineA programming sheet is not a constraint on your judgment -- it is the product of expert judgment translated into a procedure you can implement with confidence. When you follow it with fidelity and document what you see, you are doing exactly what evidence-based practice requires. |

Page