The short version
- 1. Define a behavior — once, when things are calm.
- 2. Log an incident — every time that behavior actually happens. Four taps.
- 3. Add the day's context — sleep, meds, mood, routine changes.
- 4. Read the pattern, then export it — bring the summary to the meeting.
Behaviors and incidents are two different jobs
A behavior = a definition
You write it once. It is the dictionary entry the whole team will use: exactly what the behavior looks like, what counts, what doesn't, when it starts and stops, and how it's measured (how many times, how long, how severe). Write it in observable language — "leaves seat and walks to the window during independent work," not "disruptive." You will rarely touch it again.
An incident = one occurrence of that behavior
One row of data, logged each time it happens: which behavior, what happened right before, what happened right after, how intense. Under 20 seconds, no typing required. If you're logging something a teacher told you about later, open the entry and set the date and time it actually happened.
One definition, many incidents. That's what makes the numbers mean something — everyone is counting the same thing.
Daily context: the slow triggers
Some things don't happen right before the behavior but raise the odds all day: short sleep, illness, a medication change, hunger, a rough morning, a substitute teacher, heavy sensory load. The daily check-in records these so a hard week can be explained by something other than "he's just like that."
How the data comes together
Nothing here is a diary. Each piece is a field that can be counted and cross-referenced:
- Definition + incidents → how often and how severe, over a real span of days.
- Antecedents across incidents → which situations set it off (demands, transitions, denied requests).
- Consequences across incidents → the likely function: escape, attention, tangible, or sensory.
- Incidents + daily context → whether sleep, meds or routine changes track with hard days.
- Removals and safety flags → lost instructional time, which is often the strongest argument for more support.
- Strengths entries → what already works, so the meeting produces supports instead of a list of complaints.
The pattern summary stays locked until there are enough incidents across enough days. That's on purpose: a claim made from four data points gets contradicted in the room.
Using it in the meeting
- Export the summary and bring printed copies for the team.
- Open with the definition, then the numbers: "In 14 school days, 22 incidents, 17 of them during independent writing."
- Ask for the school's matching data. Where it disagrees with yours, ask what they count and how.
- Ask for the next step in writing: an FBA, a BIP review, or specific accommodations tied to the antecedent you documented.