ABC data is most useful when it captures the whole event, not only the behavior that drew attention. What happened immediately before? What did the client do? What happened after? Where and when did it occur? Was the incident linked to an active behavior goal, or was it an observation that still needs clinical review?
Those questions sound simple. In practice, the difference between a structured ABC record and a free-text note is the difference between a pattern a BCBA can analyze and a story that must be reread one incident at a time. A vague entry such as “tantrum after demand” may be enough to refresh someone’s memory. It is not enough to compare demand-related incidents with transitions, examine consequences by hypothesized function, or defend why a treatment plan changed.
This guide maps the complete ABC incident model used in Cognix Health: the 12 antecedent categories, 13 consequence categories, four hypothesized functions, three intensity levels, four settings, optional session and behavior-goal links, and the synchronization rules that keep ABC observations aligned with behavior-trial data. It then covers the Functional Behavior Assessment (FBA) report Cognix builds from those incidents — date-range configuration, incident tables, frequency charts, antecedent–function cross-tabs, conditional probability analysis, function hypothesis statements, BCBA recommendations, and branded PDF export — and explains what the model can tell you, what it cannot prove, and how to keep a hypothesis separate from an assessment conclusion.
Complementary reading: The Complete Guide to ABA Therapy Data Collection explains the seven target types and response structures that behavior-goal data can use. ABA Goal Phases and Mastery Criteria explains why behavior goals need different progress rules from skill goals.
Why ABC Data Is a Clinical Control System
ABC documentation is not a three-field formality. It is a compact observation model that preserves the relationship between an environmental event, an observable response, and the event that followed. That relationship gives a clinician something to compare across sessions, settings, staff, and activities.
A strong ABC record separates four jobs that are often collapsed into one note:
- Describe the event — record observable antecedent, behavior, and consequence details.
- Classify the context — use consistent categories for later aggregation.
- Connect the event to treatment programming — optionally link the incident to a session and behavior goal.
- Preserve clinical uncertainty — store a hypothesized function as a working interpretation, not as a proven fact.
This separation matters because the same top-line behavior can occur under different conditions. “Vocal protest” after a difficult demand may have a different treatment implication from “vocal protest” after attention is diverted. The behavior description stays observable; the antecedent, consequence, setting, activity, intensity, duration, and function fields make the context computable.
The ABC Data Surface at a Glance
These are counts of supported values in the product domain model, not claims about how many categories ABA as a discipline may use. A clinician can still add notes for nuance. The structured values create a shared vocabulary for filtering, aggregation, and review.
The Complete ABC Incident Record
Each ABC incident is stored as its own record, not buried inside a session note. That design matters. If observations only lived in free-text notes, teams would have to re-read every narrative just to compare patterns across days. Independent records can be reviewed by client, session, behavior goal, and time.
Every record keeps the care-team context, the observation itself, optional links, and when it was recorded:
| What is captured | What it preserves | Why it matters |
|---|---|---|
| Organization, client, and staff | Which care team owns the record and who recorded it | Keeps the observation with the right client and identifies the observer |
| Session and behavior goal | Optional links to a session and behavior goal | Connects an observation to treatment programming when the context is known |
| Antecedent | Category plus optional notes | Makes the event before the behavior comparable while preserving detail |
| Behavior | Required observable description | Prevents the record from being only an interpretation |
| Intensity and duration | Optional severity level and length in seconds | Adds magnitude to frequency-style event records |
| Consequence | Category plus optional notes | Shows what followed and supports treatment review |
| Function | Optional hypothesized function | Captures a working clinical hypothesis without rewriting the observation |
| Setting and activity | Optional location and activity | Makes patterns portable across environments and routines |
| Incident time | Required ISO timestamp | Allows chronological review and daily, weekly, or monthly aggregation |
| Audit timestamps | Created and updated metadata | Shows when the record was entered or changed |
The required fields are deliberately narrower than the full context. An incident must have an antecedent category, behavior description, consequence category, and incident time. Optional fields should remain optional when the observer did not have enough information. Guessing a setting or function just to complete a form produces cleaner-looking data and weaker clinical validity.
Observation Versus Interpretation
The behavior description should describe what was observable: “pushed materials from table,” “stood and moved six feet from the group,” or “called out repeatedly for 45 seconds.” It should not replace the observation with a label such as “attention seeking” or “noncompliant.” Those labels may be useful shorthand in a treatment plan, but they do not tell a later reviewer exactly what occurred.
The function field belongs one layer later. The supported values are Attention, Escape/Avoidance, Tangible, and Automatic/Sensory. A function is a hypothesis about reinforcement or maintaining variables. It is not automatically established because one incident was recorded with that value. Repeated patterns, direct observation, interviews, data review, and a qualified clinician’s assessment determine how much confidence a hypothesis deserves.
A Useful Rule for Review
Describe first, classify second, hypothesize third. If a record says what happened, where it happened, and what followed, another clinician can challenge or refine the hypothesis. If the record starts with the hypothesis, the team may end up confirming a label instead of testing a pattern.
Antecedent Categories: What Happened Before
The structured antecedent taxonomy contains 12 values:
- Demand/Task Presented — an instruction, task, or work demand was presented.
- Transition — the client was moving between activities, locations, people, or routines.
- Denied Access/Told No — access to a preferred item, activity, or outcome was denied.
- Item/Activity Removed — an item or activity already available was removed.
- Attention Diverted — another person’s attention shifted away from the client.
- Left Alone — the client was left without the previous social partner or interaction.
- Peer Interaction — a peer interaction was occurring or had just occurred.
- Unstructured/Free Time — the incident occurred during an open or less structured period.
- Sensory Stimulation — a relevant sensory input or stimulation was present.
- Routine Change — a familiar schedule, sequence, or expectation changed.
- Physical Discomfort — pain, fatigue, hunger, illness, or another physical factor was observed or reported.
- Other — the event does not fit the listed categories.
These values are not mutually exclusive descriptions of every detail that may be relevant. A transition can also involve a denied item. A routine change can happen while a demand is presented. The category is a primary classification for aggregation; antecedent notes preserve the combination and the specifics.
Why Category Choice Changes the Question
If a team records every event as “demand,” it can only ask whether demand-linked incidents are increasing or decreasing. With the broader taxonomy, the team can ask more useful questions:
- Are incidents concentrated around transitions rather than work demands?
- Does a routine change matter more at home than in the clinic?
- Are incidents after attention is diverted followed by attention delivery?
- Are “other” records high enough to indicate a missing operational definition or a training problem?
A category should be selected because it best describes the immediate context, not because it points toward the preferred intervention. “Demand/Task Presented” is an antecedent category even if the demand was reasonable and the resulting behavior was unsafe. The classification is not a judgment about who was right.
Consequence Categories: What Happened After
The consequence taxonomy contains 13 values:
- Attention Given (Verbal)
- Attention Given (Physical)
- Demand Removed/Break Given
- Task Modified
- Item/Activity Provided
- Planned Ignoring
- Verbal Redirect
- Physical Prompt
- Response Blocking
- Natural Consequence
- Reinforcement Delivered
- No Response
- Other
The distinction between consequence and punishment is important. In ABC documentation, “consequence” means what happened after the behavior, not a moral evaluation of that event. A verbal redirect, a break, a response block, and no response are different consequences with different implications for later analysis.
The categories also need to be recorded as events, not intentions. If staff planned to ignore a behavior but spoke to the client during the incident, the record should reflect what actually happened. If the client received a break after the behavior, “Demand Removed/Break Given” captures the observable sequence even if the break was clinically appropriate under the protocol.
Consequence Notes Add the Missing Precision
A category such as Task Modified does not tell the full story. Notes can explain whether the task was shortened, the prompt level changed, materials were rearranged, or the activity was postponed. The category makes the record searchable; the note makes it interpretable.
The same principle applies to Reinforcement Delivered. Record what was delivered and under what rule when that detail matters to treatment integrity. Avoid using “reinforcement” as a catch-all for any positive interaction. If the actual event was verbal attention, choose the attention category and add the relevant note.
Functions: Four Hypotheses, Not Four Diagnoses
The function list is intentionally compact:
The function value is optional because the observer may not have enough evidence at the time of entry. Leaving it blank is better than a confident but unsupported guess. When the team later reviews patterns, missing function values are treated as unknown — a placeholder for analysis, not a fifth function.
Reading a Function Pattern Carefully
Suppose five incidents share the antecedent Demand/Task Presented, and four are followed by Demand Removed/Break Given. That pattern may support an escape/avoidance hypothesis worth testing. It does not prove that escape is the maintaining function. The team still needs to consider task difficulty, communication alternatives, prompting, the client’s history, and what happens in comparable situations where the behavior does not occur.
ABC data is strongest when it narrows the next clinical question. It should not pretend to answer every question from a dropdown.
Intensity, Duration, Setting, and Activity
Intensity
The supported intensity levels are Mild, Moderate, and Severe. Intensity is not a replacement for a behavior definition or a frequency and duration measure. It is a contextual severity field that can help the team sort incidents and prioritize review.
An intensity scale is only useful when the practice defines what each level means for the behavior being tracked. A “severe” incident should be anchored to observable criteria such as risk, force, injury potential, property damage, or required response. Those operational definitions belong in the treatment plan and training materials; the ABC record stores the selected level and the event-specific description.
Duration
Duration records how long the behavior lasted when length is clinically meaningful and can be measured. It is optional because not every incident has a reliable start and end. A duration of 45 seconds tells a different story from an unmeasured brief event, but an estimated number entered after the fact can be worse than a blank field.
Duration also has a special link to progress measurement. When an ABC incident is connected to a Duration-type behavior goal and session, the value can be added to that goal’s session trials. If the incident is edited, the matching duration entry is updated. If the incident is deleted, the matching duration entry is removed.
Setting and Activity
The setting values are Clinic, Home, School, and Community. An optional activity note adds detail such as group instruction, meal preparation, toileting routine, transportation, or free play. Setting tells the team where the pattern appears; activity tells the team what was happening inside that setting.
A behavior that is stable in the clinic but spikes during community transitions should not be summarized as a generic increase. Setting and activity details help the team distinguish a treatment problem from a generalization problem.
Session and Behavior-Goal Linkage
An ABC incident can be saved without a session or behavior goal. That supports observations captured outside a formal session, incidents awaiting reconciliation, and records where the observer does not yet know which program should receive the data.
When both a session and a behavior goal are linked, Cognix keeps the two clinical views consistent:
- Save the independent ABC incident with the full contextual detail.
- Find the matching Behavior goal in that session.
- For a Frequency behavior goal, increase the count by one.
- For a Duration behavior goal, add a new trial with the incident duration in seconds.
- Keep a clear history of the linked update so the team can review what changed.
The separation is intentional. The incident keeps the full ABC context. The session record keeps the behavior-goal measurement used for progress tracking. One is not a substitute for the other.
Worked Example: One Incident, Two Data Views
Observation: During a clinic session, a client pushes materials away after a difficult matching task. The RBT records the incident at 10:30, selects Demand/Task Presented, describes the behavior as “pushed cards from table,” selects Moderate, records 8 seconds, selects Demand Removed/Break Given, and marks Escape/Avoidance as the current hypothesis.
ABC view: The record preserves the antecedent, behavior, consequence, intensity, duration, setting, activity, timestamp, and hypothesis for later analysis.
Session view: If the incident is linked to the active Frequency behavior goal for that session, its behavior trial count increases by one. If it is linked to a Duration behavior goal, an 8-second duration trial is appended instead.
The two views answer different questions. The ABC record supports functional analysis. The session trial supports progress measurement. The link makes them consistent without forcing the full ABC narrative into a single numeric answer.
What Happens When an Incident Changes
Editing and deleting linked incidents needs more care than editing a free-text note. If the linked behavior goal changes, Cognix removes the old trial contribution and adds the new one. If only the duration changes, the matching duration trial is updated. On deletion, Frequency counts step down (never below zero) and Duration removes the matching entry.
The incident itself is still the primary record. If a linked session update fails for some reason, the observation is not lost. Teams should still review linked progress data along with the ABC history rather than assuming every side effect always completed silently.
From Records to Analysis
Structured ABC incidents become useful when they can be filtered, counted, cross-tabulated, and reviewed against a defined date range. Cognix’s ABC analysis surface supports several intermediate views before a formal FBA report is generated:
- Antecedent summaries with counts and percentages
- Consequence summaries with counts and percentages
- Function distribution across the four hypothesized functions (with missing values treated as Unknown)
- Antecedent-by-function cross-tabulation
- Incident lists ordered by incident time
- Time-period aggregation by daily, weekly, or monthly buckets
A cross-tab is often more informative than a single top-line count. It can show, for example, whether Transition incidents are most often paired with an Attention hypothesis or whether Demand/Task Presented incidents are more often paired with Escape/Avoidance. The result is a prompt for clinical review, not an automatic treatment prescription.
Those intermediate views answer day-to-day questions. When a BCBA needs a dated assessment artifact for a treatment plan revision, an IEP team, an authorizing payer, or an internal peer review, Cognix turns the same incident set into a Functional Behavior Assessment (FBA) report.
The Cognix FBA Report
Most teams still assemble FBA documents by hand: filter a spreadsheet, rebuild charts, copy percentages into slides, retype a hypothesis, and paste recommendations into a separate file. Cognix builds the report directly from the structured ABC incidents already collected for that client.
The path is short:
- Open the client’s ABC analysis view.
- Open the FBA Report Builder.
- Choose the observation start and end dates (defaults to the last 30 days through today).
- Optionally write BCBA recommendations.
- Generate the report.
- Preview every section on screen.
- Export a branded multi-page PDF ready to share with the care team, school, or payer.
What the BCBA sees in the preview is what shows up in the PDF.
What the Report Includes
Every report is limited to one client, your organization, and the dates you choose. Inside that window, Cognix pulls together five clinical pieces:
| Report piece | What you get | Why it helps |
|---|---|---|
| Incident list | Every ABC incident in the date range | Lets a reviewer check the percentage against the actual events |
| Category summaries | Counts and percentages for antecedents, consequences, and functions | Shows what happens most often without reopening each note |
| Conditional patterns | Which consequences most often follow which antecedents | Turns vague impressions into patterns with denominators |
| Function hypothesis | The leading hypothesized function with observation and session counts | Gives the team a clear starting point for clinical review |
| Report summary | Total observations and the exact date range used | Keeps the document usable for people who did not collect the data |
Report Sections, In Order
The on-screen preview and the exported PDF follow the same order a clinical reviewer expects.
Header
The header is written for someone who did not collect the data. It names the client, organization, date of birth when available, assessment period, total observations, and report date. The PDF also includes the organization’s logo when one is set, a Cognix logo, a blue title bar labeled Functional Behavior Assessment Report, and page numbers throughout. That package is easier to file than a screenshot of a dashboard.
Incident Records
The incident list is the audit path. Every percentage in the report can be traced back to a real event. If a ratio looks off, the reviewer does not reverse-engineer a chart — they open the incident that produced the count.
Each row includes:
| Column | What it shows |
|---|---|
| Date/Time | When the incident occurred |
| Behavior | Observable description of what the client did |
| Antecedent | What happened immediately before |
| Consequence | What happened immediately after |
| Function | Hypothesized function, when one was recorded |
| Intensity | Mild, moderate, or severe |
| Setting | Clinic, home, school, or community |
Charts and Summaries
The data-summary block turns the structured categories into the five views most clinical reviews need:
- Antecedent frequency — which situations show up most often in the window
- Consequence frequency — what most often follows the target behavior
- Function distribution — how hypothesized functions are spread across incidents that include a function
- Behavior trend — daily incident counts across the assessment period
- Antecedent–function comparison — joint patterns such as Demand/Task Presented with Escape/Avoidance
The PDF keeps both the number tables (category, count, percentage) and the charts, so the document still works in print and on screen.
Conditional Patterns
Conditional patterns are where ABC becomes more than a frequency recap. For every antecedent present in the date range, Cognix asks: when this situation happened, how often did each consequence follow?
The report ranks those pairs from strongest to weakest. Preview and PDF only show pairs that reach 30% or higher, so one-off couplings do not clutter the document. Strong pairs are written as plain-language statements:
When Demand/Task Presented occurs, the behavior is followed by Demand Removed/Break Given 62% of the time (18 of 29 observations).
That format puts a denominator into the clinical conversation. “Escape looks common” becomes a checkable claim about what followed a specific situation in a specific window.
What these patterns do not claim: A 62% pair is not proof that escape is the function, not proof that the consequence caused the behavior, and not a mandate to write a specific behavior plan. It is ordered evidence that a consequence followed an antecedent often enough to deserve a clinical test.
Function Hypothesis Statement
The function hypothesis is built only from incidents that already include a hypothesized function. Cognix:
- Counts each of the four supported functions in the date range.
- Ranks them by how often they appear.
- Selects the top function as the primary candidate.
- Calculates what share of function-labeled observations that top function represents.
- Reports the total number of observations in the window.
- Reports how many different sessions those observations came from.
The resulting statement reads:
Based on 47 observations across 12 sessions, the target behavior(s) appear to be primarily maintained by Escape/Avoidance (58% of observations).
Three safeguards keep this from being over-read:
- Missing functions are left out of the ranking, not treated as a fifth function.
- The wording stays hypothesis-grade (“appear to be primarily maintained by”), not diagnostic.
- Both observation count and session count are shown, so a high percentage from a tiny session set is visible.
If no incident includes a hypothesized function, the section is simply left out rather than filled with a guess.
BCBA Recommendations
Recommendations are free text written by the BCBA. Cognix does not turn the hypothesis into a behavior intervention plan on its own. The recommendations section exists so the summaries, patterns, and hypothesis travel with the clinician’s own treatment language in one PDF. If the field is empty, the preview says so and the PDF leaves recommendations out until the BCBA writes them.
Worked Example: Building an FBA Report From the Same Incidents
Client window: 30 days, clinic and school settings
Incidents in range: 47 ABC incidents; 12 linked to a session and behavior goal
Top antecedent: Demand/Task Presented — 29 of 47 (62%)
Top consequence after that antecedent: Demand Removed/Break Given — 18 of 29 (62%), which is strong enough to appear as a conditional pattern
Function mix when a function was recorded: Escape/Avoidance 58%, Attention 22%, Tangible 12%, Automatic/Sensory 8%
Generated hypothesis: “Based on 47 observations across 12 sessions, the target behavior(s) appear to be primarily maintained by Escape/Avoidance (58% of observations).”
BCBA recommendations (human-written): Test a demand-fading hierarchy on academic worksheets; teach a functional communication response for “break please”; protect attention for compliance rather than protests; recheck the pattern after two school weeks before changing the behavior plan.
Export: Multi-page PDF with organization branding, the full incident list, charts, the 62% conditional pattern, the escape hypothesis, and the recommendations block.
The report did not invent the function. It organized what the team already recorded and made the pattern easy to review.
Why a Dedicated FBA Report Beats Dashboard Screenshots
| Manual path | Cognix FBA path |
|---|---|
| Filter a spreadsheet and copy counts into slides | Generate the report from the client’s ABC incidents for a chosen date range |
| Rebuild charts for every review meeting | The same charts appear in the live preview and the PDF |
| Retype hypothesis language each cycle | Leading function, percentages, and denominators are assembled automatically from recorded hypotheses |
| Paste recommendations into a separate document | BCBA recommendations travel with the data section in one PDF |
| Screenshots lack branding, page numbers, and client details | Branded header, logos, repeated page headers, footers, and report date |
| Hard to prove which events produced a percentage | The full incident list ships with the report |
The FBA report is the part of the ABC workflow that teams show other people. Documentation load drops without taking clinical control away from the BCBA. The clinician still owns recommendations and final interpretation. The platform handles the assembly.
A Practical Review Sequence
Use a repeatable sequence whether you are reading the live ABC analysis surface or the exported FBA PDF:
- Check data completeness. Look at missing function, setting, duration, and session links before interpreting the totals.
- Start with time. Use the daily trend to see whether the pattern is stable, increasing, decreasing, or concentrated in a short window.
- Compare antecedents. Sort by category and inspect the notes behind the largest groups.
- Compare consequences. Ask what reliably follows the behavior, not only what staff intended to happen.
- Read conditional probability pairs ≥ 30%. Treat each pair as an observation-backed claim with a denominator.
- Cross-tab antecedent and function. Look for joint patterns rather than a single overall function label.
- Stratify by setting and activity. Separate clinic performance from home, school, or community generalization.
- Compare with behavior-goal trials. Check that frequency or duration progress reflects the same incidents that informed the ABC review.
- Interrogate the generated hypothesis. Confirm it is hypothesis language, inspect the percentage and session count, and decide whether the evidence window is strong enough.
- Write recommendations and the next test. Define what the team will observe or change, and what result would support or weaken the hypothesis.
This process preserves the difference between a descriptive data summary, a generated hypothesis statement, and an FBA conclusion owned by a qualified clinician. It also gives supervisors a concrete way to coach staff: improve the missing field, clarify the operational definition, harden a weak probability pair, or test the next antecedent and consequence pattern.
Best Practices for Reliable ABC Data
- Define the behavior before collecting incidents. Use observable, measurable language and train staff against examples and non-examples.
- Record the event close to when it occurred. Delayed entry increases the chance that antecedent and consequence details will be reconstructed from memory.
- Use the structured category first, then add notes. Categories enable analysis; notes capture the details that categories cannot.
- Do not force a function. Leave the field empty when evidence is insufficient and let the review process refine the hypothesis.
- Record what happened, not what was planned. A planned break and a delivered break are not the same data point.
- Use duration only when it can be measured. An honest blank is better than false precision.
- Link to the session and behavior goal when the link is known. This keeps the incident and trial views aligned.
- Review missingness as a quality signal. High “Other,” “Unknown,” or blank-setting rates may indicate taxonomy or training gaps.
- Compare settings before generalizing. A clinic pattern should not automatically be treated as a home or community pattern.
- Keep the audit trail intact. Corrections should update the record through the application workflow rather than silently rewriting history.
Common Mistakes and How to Avoid Them
Digital ABC Workflows That Deserve Trust
A digital system should make the correct workflow easier without making clinical decisions opaque. For ABC incidents, that means supporting rapid capture during a session, consistent fields on web and mobile, safe updates, and analysis that can be traced back to individual records.
Cognix keeps the same rules for web and mobile, so staff do not get different category lists or different session-link behavior depending on which device they used. Organization boundaries stay enforced as well: each team only sees its own clients. Those controls are not a substitute for clinical governance, but they keep a client’s observation history in the right care environment.
How Cognix Health Supports ABC Incident Workflows
Cognix Health treats ABC data as part of everyday clinical work, not a side note. Teams can capture structured incidents during sessions, keep narrative detail when it matters, connect incidents to behavior goals, review patterns across a date range, and generate a branded FBA report without rebuilding charts by hand.
The workflow includes:
- Structured ABC incident records with categories, descriptions, notes, intensity, duration, setting, activity, and timestamps
- Web and mobile consistency so the same categories and rules travel with staff across devices
- Optional session and behavior-goal links when an observation should update session behavior data
- Automatic frequency and duration updates when incidents are linked, including clean handling of edits and deletions
- Clear history of linked updates when behavior-trial data changes
- Antecedent summaries and comparisons for practical clinical review
- FBA Report Builder with date-range selection, full incident lists, frequency and trend charts, conditional patterns (30% or higher), function hypothesis statements, and BCBA-written recommendations
- Branded multi-page PDF export that matches the on-screen preview and is ready to share
The goal is not to replace a BCBA’s functional assessment. It is to give the BCBA cleaner observations, clearer comparisons, fewer disconnected records to reconcile, and a review-ready FBA document when the team, school, or payer asks for one.
Want to see how structured ABC data and FBA reports fit your clinical workflow? Contact Cognix Health to schedule a demo.
Frequently Asked Questions
What does ABC stand for in ABA?
ABC stands for Antecedent, Behavior, and Consequence. The antecedent is what happened immediately before the behavior, the behavior is the observable response, and the consequence is what happened immediately after. Good ABC records can also include time, setting, activity, intensity, duration, and a clearly labeled hypothesized function.
What are the four functions in this ABC data model?
The model supports Attention, Escape/Avoidance, Tangible, and Automatic/Sensory. These are hypothesized functions, not diagnoses or automatic conclusions. A missing value is represented as unknown during aggregation rather than being treated as a fifth function.
How many antecedent categories does the model support?
The structured taxonomy contains 12 antecedent categories: demand or task presented, transition, denied access or told no, item or activity removed, attention diverted, left alone, peer interaction, unstructured or free time, sensory stimulation, routine change, physical discomfort, and other. Antecedent notes can preserve details when more than one context is relevant.
How many consequence categories does the model support?
The taxonomy contains 13 consequence categories, including verbal and physical attention, demand removed or break given, task modified, item or activity provided, planned ignoring, verbal redirect, physical prompt, response blocking, natural consequence, reinforcement delivered, no response, and other. The selected category should describe what actually happened after the behavior.
Can an ABC incident exist without a session?
Yes. Session linkage is optional. An incident can be recorded independently when it occurs outside a formal session, before reconciliation, or when the correct session is not known. If both a session and behavior goal are provided, the system can synchronize the linked behavior trial.
What happens when an ABC incident is linked to a behavior goal?
For a linked Frequency behavior goal, creating an incident increments the last answer’s count or creates the first count. For a linked Duration behavior goal, the incident duration is appended as a trial. The system also records the linked update in the session-data audit trail.
What happens if a linked incident is deleted or its duration changes?
Deleting a linked Frequency incident decrements the count with a minimum of zero. Deleting a linked Duration incident removes the matching duration entry and renumbers attempts. Editing a linked duration updates the matching session trial. These side effects are logged if they fail, while the primary incident operation can still complete.
Does ABC data prove a behavior’s function?
No. ABC data supports functional hypotheses by showing repeated relationships among antecedents, behaviors, and consequences. A qualified clinician should interpret the pattern alongside operational definitions, interviews, direct observation, treatment history, and other assessment evidence before making treatment decisions. Cognix’s FBA report surfaces a leading hypothesized function with observation and session counts; it does not replace that clinical judgment.
What does Cognix include in an FBA report?
The FBA Report Builder looks at one client’s ABC incidents across the dates you choose, then assembles the report header, the full incident list, frequency summaries for antecedents, consequences, and functions, a daily behavior trend, an antecedent–function comparison, conditional patterns that reach 30% or higher, a leading function hypothesis statement, optional BCBA recommendations, and a branded multi-page PDF ready to share.
How is the function hypothesis calculated?
Cognix looks only at incidents that already include a hypothesized function, ranks the four supported functions by how often they appear, and selects the top one. It then shows what share of those function-labeled observations the top function represents, along with the total observation count and how many sessions contributed. Incidents without a function are left out of the ranking rather than treated as a fifth function. If no incident has a function, that section is simply left out.
How do conditional patterns work in the report?
For each antecedent present in the date range, the report counts every consequence that followed and shows how often that pairing appeared. Pairs are sorted from strongest to weakest. Preview and PDF only display pairs at 30% or higher, each written with the count so reviewers can see how solid the pairing is.
Does the FBA report auto-write a behavior intervention plan?
No. Frequency tables, charts, conditional patterns, and the hypothesis statement are generated from recorded incidents. Recommendations are free text written by the BCBA. Empty recommendations stay empty on the PDF instead of inventing treatment language.
How should ABC data connect to mastery tracking?
ABC data and mastery tracking should remain related but distinct. ABC incidents preserve functional context, while session behavior trials measure frequency or duration progress. Goal phases and mastery criteria explains why behavior reduction goals should not be forced into the same percentage-correct rules used for every skill target.
This guide reflects Cognix Health ABC incident workflows and the FBA Report Builder as of July 2026. Clinical teams should use their organization’s operational definitions, treatment plans, supervision procedures, and applicable payer requirements when collecting and interpreting ABC data. For questions about how Cognix Health supports ABA clinical workflows, reach out to our team at [email protected].