What If Behavioral Software Tried to Disprove Its Own Answer?FunctionBx™ — Functional Behavior Analysis in the Digital Age, Part 3 of 3

In Parts 1 and 2, we looked at two problems.

First, behavioral patterns can be useful without being conclusive.

Second, software can help organize those patterns without necessarily improving the reasoning behind them.

That leads to a more interesting design question:

What if behavioral software was built not only to support its leading hypothesis, but to actively challenge it?

That idea sits at the center of FunctionBx™.

Most assessment systems naturally reward accumulation.

More observations.

More matching antecedents.

More matching consequences.

More evidence in the same direction.

But science becomes stronger when a hypothesis survives attempts to disconfirm it.

Behavioral reasoning should work the same way.

A strong hypothesis should survive contradiction

Suppose a student throws materials during difficult academic work.

Across ten observations:

eight episodes occur after a demand;

seven end with delay or removal of the task.

Escape/Avoidance looks plausible.

Now ask a different set of questions.

How often were difficult demands presented without problem behavior?

Did the behavior occur during easy work?

Did the same behavior occur when no demand was present?

Did task removal reliably follow the behavior?

Did the pattern appear with every teacher?

Did it disappear in another setting?

Does another explanation fit some of the same observations?

Now we're no longer simply accumulating evidence for Escape.

We're trying to break the hypothesis.

If it survives, confidence should increase.

If it doesn't, the hypothesis should weaken.

That is the logic FunctionBx™ is designed to make visible.

No-Bx is evidence

One of the most important ideas in FunctionBx™ is also one of the simplest:

When the behavior does not occur, that can still tell us something.

Traditional ABC recording often begins only after an incident happens.

That creates an unavoidable sampling problem.

Suppose 80% of behavior episodes occurred after demands.

That sounds meaningful.

But what if demands were presented 100 times and behavior occurred after only eight?

Now we have two different relationships:

How often was Demand present when Bx occurred?

and

How often did Bx occur when Demand was present?

They are not interchangeable.

This is why FunctionBx™ treats opportunities without behavior as first-class evidence rather than empty space in the dataset.

A suspected antecedent becomes more informative when behavior occurs reliably in its presence and less informative when the same event constantly happens without behavior.

The absence of Bx doesn't prove anything by itself.

But neither should it be ignored.

Evidence should compete

Behavior can have more than one plausible explanation.

A child begins yelling when a tablet is removed.

Is the function:

Access/Tangible because the tablet is gone?

Attention because adults immediately engage?

Escape/Avoidance because the removal signals the beginning of a task?

Or is the evidence currently too mixed to distinguish among them?

A weak system can force the observations into whichever category receives the largest number.

A stronger system keeps the alternatives alive.

FunctionBx™ is intended to do exactly that.

Rather than:

FUNCTION: ACCESS

the evidence might support something closer to:

Access/Tangible — strongest current support

Escape/Avoidance — meaningful competing evidence

Attention — limited support

Automatic Reinforcement — insufficient evidence

That is less dramatic.

It is also more informative.

Context can change the picture

Behavior does not occur in a laboratory vacuum.

People change.

Tasks change.

Settings change.

Schedules change.

A strategy that works with one person may appear less effective with another.

Recent renewal research involving 98 patients and 749 context changes found that problem behavior sometimes returned following changes in therapist, setting, or task. When renewal occurred, it often appeared immediately after the contextual change, although some episodes resolved quickly and others persisted. (onlinelibrary.wiley.com⁠�)

That matters because recurrence can easily be misread as:

“The hypothesis was wrong.”

or:

“The intervention failed.”

Sometimes the more accurate statement is:

Something changed in the context. Investigate that first.

FunctionBx™ now includes a Context Change & Durability Check for exactly this reason.

It asks whether the person implementing support changed, the setting changed, the activity changed, or another important contextual shift occurred.

The purpose is not to explain away failure.

It is to prevent us from confusing a new condition with the old one.

Broad functions can hide highly specific variables

The four common functional categories are deliberately broad.

That's useful for teaching.

It can also flatten important information.

Imagine that problem behavior occurs specifically when:

a preferred activity is interrupted,

by one particular adult,

immediately before an unfamiliar task,

when the individual has had little warning.

Calling the function simply Escape may be technically plausible while missing the variable combination that makes the pattern useful.

Research on inconclusive functional analyses continues to show the importance of investigating idiosyncratic antecedents and consequences when standard conditions do not explain behavior adequately. (link.springer.com⁠�)

That is why FunctionBx™ now includes an Individual-Specific Variable Check.

When evidence is weak, mixed, or closely competing, the system can prompt users to ask whether something unusually specific is being hidden inside a broad category.

Not another diagnosis.

Not a new function.

A better question.

Different observers may be seeing different worlds

Behavioral information often comes from multiple people.

A parent.

Teacher.

Technician.

Supervisor.

Caregiver.

Those observers may disagree.

That disagreement can be irritating if the goal is producing one clean answer.

But disagreement itself may be evidence.

Perhaps behavior occurs differently at home and school.

Perhaps one observer delivers consequences another does not.

Perhaps definitions are inconsistent.

Perhaps the person's environment genuinely changes across settings.

A future FunctionBx™ capability should therefore compare observations by person and setting rather than automatically blending them.

Instead of smoothing differences away, the system should say:

These observers are seeing different functional patterns. Investigate why.

That may be far more useful than an average score.

Some variables should stop the behavioral analysis

There is another important limit.

Not every behavioral pattern should be interpreted behaviorally first.

Pain.

Illness.

Medication effects.

Sleep deprivation.

Hunger.

Fatigue.

Neurological or physiological change.

A responsible behavioral system should be capable of recognizing when the information may warrant attention outside its own scope.

This does not mean physical discomfort becomes “Function #5.”

It means there are moments when the software should say:

A medical or physiological variable may need to be considered before placing greater confidence in this behavioral interpretation.

A system becomes safer when it knows what it cannot determine.

Objective Hypothesis Strength should not become fake probability

FunctionBx™ uses the concept Objective Hypothesis Strength.

That phrase needs to remain disciplined.

If a hypothesis receives a score of 82, that should never be interpreted as:

“There is an 82% chance this hypothesis is true.”

Behavioral data generally do not justify that kind of probability statement.

The score is intended to describe how strongly the structured evidence currently supports one functional hypothesis relative to the available information.

That includes:

consistency,

replication,

discrimination,

contradictions,

competing evidence,

context,

observation quality,

and missing information.

The number should summarize an evidence structure.

It should never masquerade as certainty.

Sometimes the best answer is “not ready”

One of the least exciting outputs in software may be one of the most scientifically valuable:

Insufficient evidence.

If five observations conflict with one another, a polished interface should not force a conclusion simply because users expect one.

If the target behavior is poorly defined, the correct next step may be improving the definition.

If observations all come from the same brief context, more varied data may be needed.

If two hypotheses are nearly tied, the system should say so.

If observers strongly disagree, investigate the disagreement.

FunctionBx™ separates Hypothesis Readiness from Objective Hypothesis Strength for exactly this reason.

Before asking:

“Which hypothesis is strongest?”

we should first ask:

“Is the information good enough to analyze meaningfully?”

That distinction may ultimately be one of the most important parts of the platform.

FunctionBx™ is not trying to be an automated BCBA

That boundary matters.

FunctionBx™ is not designed to diagnose.

It is not a substitute for a formal Functional Behavior Assessment.

It is not a replacement for experimental functional analysis.

It is not intended to replace supervision or professional judgment.

Its purpose is narrower:

Make functional reasoning visible.

A trainee should be able to see why one hypothesis currently has stronger support.

A parent should be able to understand why more observations are needed.

A supervisor should be able to inspect the evidence behind a conclusion.

A team should be able to identify disagreement instead of hiding it.

And the software itself should be able to say:

“Here is what supports this explanation.”

“Here is what contradicts it.”

“Here is what we still don't know.”

That is a different kind of automation.

The real question isn't whether AI can identify function

It eventually will become very easy for AI systems to generate behavioral hypotheses.

That is not the hard part.

The hard part is whether those hypotheses are:

transparent, challengeable, evidence-aware, appropriately uncertain, and useful to the people making decisions.

That is the problem FunctionBx™ is trying to solve.

Not:

Can software give us an answer?

But:

Can software help us understand whether the evidence deserves that answer?

That distinction may determine whether the next generation of behavioral technology becomes merely faster—

or actually becomes better.

The FunctionBx™ principle

After all three parts of this series, the underlying idea can be reduced to one sentence:

FunctionBx™ doesn't replace professional judgment. It makes the reasoning behind that judgment visible.

And perhaps one more:

The goal is not to make software more confident. The goal is to make behavioral reasoning more accountable.

FunctionBx™

What is the function of the behavior?