Behavior.software · Early access · three engines wired, four built and not switched on
The behavior platform that refuses before it logs.
Most behavior-management platforms sell you a log: a fast way to write an incident down and hand out a point. That is genuinely useful, and it is the reason most schools buy one. What it does not give you is a decision layer — something that can say no to a consequence that has not had due process, before the paperwork ever moves.
This is the decision layer. A consequence gate that blocks an exclusionary discipline outright without due process, and blocks it first of all when a student with a disability has not had a manifestation-determination review. A restorative-practice workflow that cannot schedule a circle without recorded consent. A tiered-intervention ledger and an MTSS/RTI pipeline that states, on every value it returns, that it is not a predictive model. And a free classroom positive-points chart, wired and reachable today.
Three of those five are live. Two are written, tested, and not connected to a route — and this page names exactly which is which, on the first screen, not the footnotes.
Not a mock incident. These are the actual return-value shapes of the shipped functions -- a refusal, an advisory flag, or an exact integer, and nothing else.
153tests across seven suites over the behavior and support engines, measured green by the author before this page was written
0consequences ever auto-imposed. The gate that would allow a suspension or expulsion refuses without due process, full stop
0predictive or AI models run on a child anywhere in this product — one module ships a named, disabled prediction scaffold instead
4modules that are written, tested, and have no production caller — each named on this page under “built, not switched on” rather than counted as a feature
The honest frame
What this is, and what it is not.
Behavior and discipline software sits in the same category as payroll software for one reason: being confidently wrong here does not waste an afternoon, it costs a child due process or exposes a school to a disproportionality finding it cannot explain. So this product was built around three refusals before it was built around a feature, and each refusal is a value the code actually returns, not a sentence on this page.
It is a decision layer, not (yet) a log. The consequence gate, the restorative workflow, and the tiered-intervention ledger all decide something about a record; none of them currently persists the record itself, because no route wires them to a table yet. We say that once here and do not walk it back anywhere below.
It never auto-imposes a consequence. The function that would allow a suspension or expulsion is fail-closed: no due process, no consequence, and that check runs before anything else matters. A student with a disability facing exclusion is checked first of all, ahead of due process, for a completed IDEA manifestation-determination review — the single most protective guard fires first, so it can never be masked by a second missing requirement.
It never runs a predictive or AI model on a child. The MTSS/RTI tiering pipeline is a deterministic threshold rule over three named signals, and it says so on its own return value: notMlModel:true. Where the codebase has a named seam for a predictive mastery forecast, that function returns a disabled scaffold rather than an unvalidated guess, and its own header states that in those words.
And it is early access. Three engines below are wired to a registered route; four more are written and covered but idle. We would rather you read that here than infer it from a quiet quarter after a pilot starts.
Built and reachable — a registered handler calls it
The engines that are actually wired.
Each of these is called by a registered API handler behind a tenant wall and a role gate. One honest bound on the whole section: reachable is a source-level claim. It means a handler calls the function. It does not mean every school has provisioned every signal feed, and where a surface degrades honestly on a missing feed, the card says so.
MTSS / RTI early-warning + tiering pipeline
The tiering pipeline — attendance, behavior count, and grades in; a tier and, where warranted, a referral out
Attendance rate, a behavior-incident COUNT (never a narrative), course failures, and an optional GPA and benchmark-assessment percentile fold into a composite risk score, and the score maps to a support tier — 1 universal, 2 targeted, 3 intensive — against a single, published set of cut points stamped with an engine version, so a threshold change is attributable rather than silent. A second, additive engine reads the SAME signals through a plain per-signal threshold instead of a score, and SUGGESTS a tier independently — every one of its results is pinned advisory:true, notMlModel:true, and notDisabilityDetermination:true. When a student is referred toward eligibility, the referral state machine can open a special-education plan and append the IEP-clock anchor events on the SAME student record, rather than starting a second, disconnected file.
mtss-tiering.ts + assess-early-warning.ts + assess-mtss-tier-engine.ts + mtss-referral-flow.tsA student's risk score and tier route through the same consent chokepoint the IEP surface uses; a suppressed student's PII never serializes. Module-dark behind sis_mtss.
Classroom positive-points charts
Positive-points charts — a teacher's own reward chart, integer points, and a leaderboard
A teacher defines a chart of behaviors — each worth an INTEGER number of points, never a fraction and never a currency — and awards points to a student in their own section. The recipient is validated against the section's actual roster before an award is accepted, so a point cannot be awarded to a student who is not enrolled in that class. A leaderboard tallies the running per-student total, highest first, with ties broken by a stable ordering rather than an arbitrary one. There is no fractional point, no cents field, and no price anywhere in this surface: it is free by construction, not by a pricing decision that could later change.
classroom-reward-chart.ts + classroom-reward-charts.ts routeRecipients are opaque section-enrollment references; a name is resolved only through the platform's existing consent gate at read time, never stored on the chart row itself.
Benchmark score ingest (OneRoster / IMS Caliper)
Benchmark ingest — an optional, honest-off feed into the tiering pipeline
The tiering pipeline accepts an optional normalized benchmark percentile — a NWEA MAP, i-Ready, or Renaissance Star-shaped score — read in through an OneRoster-Gradebook / IMS Caliper-shaped interop parser, so a school's existing assessment vendor can feed the pipeline without a second data entry pass. The feed is honest-off by default: it refuses while disabled, and enabling it requires a real credential reference. No live vendor connection is faked, and when the feed is absent the tiering engine scores on attendance, behavior, and grades alone — it never fabricates a benchmark value to fill the gap.
assessment-interop-map.tsOff by default; requires a configured credential reference before it accepts any inbound score.
Built, not switched on
Four modules with no production caller. Here they are by name.
This table is the part of the page we would remove if we were selling harder. It is here because the characteristic dishonesty of a technical product page is to describe a green test suite as a working feature, and this codebase has four places where that temptation exists. Every module below is written, is covered by tests, and is imported by nothing outside its own siblings and its own test file.
The largest consequence is worth stating plainly rather than burying in a row. There is no route in this product that persists a behavior incident record. That is why the discipline consequence gate below has no incident to gate against in production yet, and it is why this page does not claim incident logging as a working feature, anywhere above this line or below it.
Module
What it does
Why it is not reachable
Discipline consequence due-process gate
Blocks an exclusionary consequence (suspension or expulsion) unless due process was given, and blocks it FIRST on a missing IDEA manifestation-determination review for a student with a disability. Surfaces the exclusionary rate and a disability-exclusion equity flag over a set of incident records.
No production caller. There is no route that persists an incident record for it to gate, which is also why this page does not claim incident logging as a working feature today.
Restorative-practice case workflow
The referred to scheduled to circle-held to agreement-set to follow-up to resolved case state machine, plus a fail-closed rule that a circle cannot be scheduled until participation consent is recorded, and a restorative-versus-punitive response classifier for equity counts.
No production caller. The state machine and the consent gate are both correct and both idle; nothing calls openRestorativeCase or scheduleRestorativeCircle from any route.
Tiered-intervention assignment + progress ledger
Lets an MTSS team assign a NAMED Tier 1/2/3 intervention to a student, record a progress-monitoring point series against it, read a deterministic least-squares trend, and get an advisory-only tier-change flag that never moves the persisted tier itself. A small-cell-safe aggregate rolls per-tier counts up for a school.
No production caller. This is distinct from the wired early-warning pipeline above, which tiers off an attendance/behavior/grade composite rather than a specific named intervention a team assigned.
Universal screening, fidelity, and problem-solving-team decisions
Extends the intervention ledger with a universal-screening risk band, an intervention-fidelity reading, a goal-line projection, a recorded problem-solving-team decision vocabulary, and the special-education referral handoff signal.
No production caller. Its own header states, verbatim, that a named predictive-mastery function "NEVER returns a prediction: the model is off until validated" and ships only a disabled scaffold -- a refusal we would rather name than let a reader assume is a working forecast.
Built, not switched on — the discipline consequence gate
Due process, in a function, not a policy document.
The gate answers exactly one question: may this proposed consequence be imposed? For a warning, a detention, or no consequence at all, the answer is always yes — those are not exclusionary and the gate never blocks them, though the due-process fact is still recorded on the incident. For a suspension or expulsion, the answer runs through two checks, in a deliberate, most-protective order.
The FIRST check, ahead of everything else: does the student have a disability, and has the IDEA-required manifestation-determination review been completed? If not, the gate returns blocked_manifestation_review_required and stops there. This order is not arbitrary — checking the equity guard first means a missing manifestation review can never be masked by also citing a missing due-process step as the reason. The SECOND check, only reached once the first has cleared: was the student given notice and a chance to be heard? If not, blocked_no_due_process. Only when both checks clear does the gate return consequence_allowed.
Two equity primitives sit alongside the gate rather than behind it. An exclusionary rate, computed as an integer per mille over a set of incident records, and a disability-exclusion flag that is true the moment ANY incident in the set proposes exclusion for a student with a disability whose manifestation review is not done. Neither number is hidden behind a report a district has to remember to request; both are a direct function of the records.
What the gate does not do, said plainly: it does not decide anything on its own. It receives a proposed consequence and a small set of already-known facts and returns a verdict; a human still proposes the consequence, still gives notice, still holds the manifestation review. And it carries no incident narrative — every reference in the record is opaque, by the module's own stated boundary, because the narrative is exactly the kind of free-text PII this decision layer was built to never need.
This module has no production caller today (see “built, not switched on” above). It is described here as what it is: a correct, tested decision function, not connected to a route that persists an incident for it to decide about.
Built, not switched on — restorative practice
Voluntary is enforced, not requested.
Restorative practice only works when a student and the people affected actually choose to participate, and most software treats that as a norm a staff member is trusted to honor rather than a rule the system enforces. This module enforces it: a circle cannot be scheduled for a case unless participation consent has already been recorded. Not a checkbox that defaults to checked — a boolean the scheduling function reads and refuses to proceed without.
A case moves through a fixed sequence: referred, then scheduled, then circle held, then an agreement set, then follow-up, then resolved — or closed without an agreement at any point along the way. Every transition is checked against the legal set of next states for where the case currently sits; an attempt to jump the sequence is rejected rather than silently accepted. The state machine references an existing behavior-incident record by an opaque soft reference rather than re-implementing incident tracking of its own — restorative practice responds to an incident, it does not duplicate one.
Two smaller pieces round out the module. A response to an incident classifies as restorative, punitive, mixed, or none — a plain equity-count primitive with no PII beyond the classification itself, useful for asking whether a school's restorative alternative is actually displacing suspension or running alongside it. And an agreement's follow-through items roll up into a single fulfillment status — fulfilled, partial, breached, or pending — based only on whether items are done and whether a due date has passed, never a judgment call the code makes on its own.
Access is gated the same way as the rest of this page's sensitive surfaces: the restorative-team capability or a school/district administrator, and an account-manager role is denied outright regardless of any capability it might hold.
This module has no production caller today. The consent gate and the state machine are both correct and both idle — described here as exactly that.
Reachable today — positive points
Free, on purpose, and in the code, not just the pricing page.
A teacher defines a chart: a set of behaviors, each worth an integer number of points that may be positive or negative, keyed and labeled in strict printable ASCII so a malformed row can never silently corrupt a leaderboard. Awarding a point validates the recipient against the section's own roster first — a teacher cannot award a point to a student who is not actually enrolled in that class, which sounds obvious until you consider how many chart tools take whatever identifier the client sends.
The tally is a straightforward sum per recipient, and the leaderboard orders by total, highest first, with ties broken by a stable secondary key rather than whatever order rows happened to arrive in. A defensive detail worth naming: a legacy row that somehow carries a fractional point is skipped from the tally entirely rather than rounded, because rounding a stray fraction into an integer total is exactly the kind of silent correction that erodes trust in a running score.
The honest-off claim here is a refusal, not an absence: there is no SupportedCurrency type, no cents field, and no price anywhere in this module's code. It is not that the reward chart happens to be free today and might change — the type system has nowhere to put a price if someone wanted to add one without also changing the engine.
This is one of two engines on this page that IS wired to a registered route today (see “the engines that are actually wired” above), and it is the one lane in this whole category that persists.
Reachable today — the MTSS / RTI pipeline
A threshold rule that says, on every answer, that it is not a model.
Three canonical signals — an attendance rate, a count of behavior incidents, a count of failing grades — plus an optional GPA and an optional benchmark-assessment percentile fold into a single composite risk score from 0 to 100, and the score maps to a support tier against two published cut points. Nothing here is a black box: the weights and the cut points are named constants in the source, and every decision carries an engine version, so a future change to either is attributable rather than invisible.
40 and above, below 70One published cut point crossedTier 2 · targeted
70 and aboveThe second published cut point crossedTier 3 · intensive
These are the actual TIER_THRESHOLDS constants in the engine, not a rounded illustration. The
engine's own header calls them a defensible default, not a per-state truth: a state's MTSS rule may mandate
different cut points, and every decision the engine returns is stamped with an engine_version so a threshold
change is attributable rather than silent.
A second, independent engine reads the same signals a different way: instead of a score, it compares each signal against a named threshold and raises a watch-list flag — none, watch, or warning — only when a signal actually crosses its published line, and every flag lists exactly which signals fired and what threshold they crossed. Layered on top of that watch-list flag, a third function SUGGESTS a support tier, and pins three fields on every single result it returns: advisory:true, notMlModel:true, and notDisabilityDetermination:true. Tier 3 is never suggested off a single fired signal — the rule requires multiple distinct concerns at once before it suggests intensive support.
Neither engine moves anything by itself. The suggestion is recorded ALONGSIDE the tier a human actually assigns, specifically so a divergence between the two is visible to the team rather than quietly overwritten. When a referral toward special-education eligibility is opened and a determination comes back eligible, the same student record gets the IEP-clock anchor events and a special-education plan — the referral state machine feeds the platform's existing IEP spine instead of starting a second, disconnected file for the same child.
One deliberate content gap, named rather than smoothed over: this pipeline assigns a tier and opens a referral. It does not prescribe what a Tier 2 or Tier 3 intervention should actually consist of. A curated library of intervention strategies is exactly the kind of partner- or subject-matter-expert-curated content this product does not invent, and the comparison below gives that row to the category outright.
Every risk score and tier this pipeline would emit for a student routes through the same consent chokepoint the IEP surface uses; a student whose family has suppressed that data never has it serialized, even though the tier ASSIGNMENT itself (a placement, not PII in the same sense) may still be written. The whole surface sits behind a module flag, so a school that has not enabled it is byte-identical to one that never installed it.
Against the category
Ten rows. The category wins the first three, outright.
Most vendor comparison tables are a list of things the author is good at, and everyone reading knows it. So here are the three axes where the category of PBIS point-and-incident platforms beats us, first, without qualification: a fast mobile incident log, a curated intervention-strategy library, and a family-facing rewards app. Those are not small. For most schools those three are the whole reason to buy behavior software at all, and if that is what you need this week, buy it from a product that already has it.
The seven rows underneath are where we are different, and there is a discipline in how they are written that matters more than the result. We describe our own behaviour precisely, because we can read our own source. Where the other column would require us to assert what another company’s code does internally, it says we have not established it — because we cannot, and a guess in the direction that flatters us is not a comparison.
The left column states our own measured behaviour. The middle column states only what the category openly advertises, or that we could not establish it. Rows are marked for whoever wins them.
What you are buying
A PBIS point-and-incident platform
Behavior.software
Log a behavior incident today, on a phone, in the hallway
Yes. A fast, mobile incident-entry flow is the advertised core of the category, and it is the reason most schools buy one.
No. Not built. The consequence gate governs a decision; nothing in this product persists an incident record yet.
A ready-made library of Tier 2/3 intervention strategies
Yes. A curated content library of interventions is a standard, genuinely useful advertised feature.
No, by design. The tiering engine assigns a tier and opens a referral; it deliberately ships no intervention content.
A family-facing mobile app for behavior and rewards
Yes. A branded parent/guardian app is a standard advertised feature of the category.
No. There is no mobile app and no family-facing surface for behavior data in this product today.
A serious consequence is blocked without due process, in the function that decides
Not established. We cannot read another vendor's approval logic and will not characterise it here.
Yes. consequenceGate refuses an exclusionary consequence outright when due process was not given.
A student with a disability cannot be excluded without a manifestation review
Not established. Whether this check exists, and where in the flow, is not something we can read from outside.
Yes, and checked FIRST in the gate's own order, before the due-process check, so it can never be masked by it.
Restorative-practice participation requires recorded consent before a circle is scheduled
Not established. We do not know whether consent is a gate or a checkbox in any other product.
Yes. restorativeCircleSchedulable fails closed: no recorded consent, no circle, full stop.
A support-tier suggestion states, on its own return value, that it is not a trained model
Not established. Some vendors market a predictive risk score; how it is computed is not published that we found.
Yes. advisory / notMlModel / notDisabilityDetermination are pinned true on every suggestion this pipeline returns.
A predictive behavior or mastery forecast for an individual child
Some vendors advertise a predictive or risk-scoring capability; we make no claim about how any of them compute it.
No, on purpose, even where the surface exists to hold one: predictiveMastery is a named, disabled scaffold.
Classroom positive-point rewards free of a paid tier
Not established as a universal category default; some products gate advanced reward features behind a plan.
Yes. Money-honest-off by the module's own header: no cents field, no price, no currency type exists in the code.
The exclusionary rate and a disability-exclusion flag surfaced automatically, not requested
Not established as an automatic surface; a compliance report is more commonly a separate, requested export.
Yes. exclusionaryRatePerMille and disabilityExclusionFlag are computed directly over a set of incident records.
One note on the category, since this page makes a claim about it. The PBIS / behavior-and-rewards software category this
product is measured against includes mobile incident-logging tools, point-and-token reward platforms, and
office-discipline-referral trackers. It is named here once, only as a factual category reference, and none of
its code, copy or design is used anywhere in this product. Nothing above is a claim about how any specific
vendor is built internally — we have not read their source and cannot, so every row of the table either
cites our own measured behaviour or says outright that we could not establish theirs. Their advertised
capabilities are their own to describe, and any of them may ship any of the things in our column tomorrow.
Data, walls, and what we hold
Behavior and discipline data is sensitive child PII. Every module treats it that way.
Every surface on this page is gated the same shape, twice. First an application-layer role check: a school or district administrator, or a session holding the specific team capability that surface requires (the MTSS-team capability, the restorative-team capability) — and a rep, a photographer, platform support, or an account-manager role is denied outright, before any capability is even checked. Second, a database-level restrictive policy backs the same wall, so a misconfigured application check can never lift the database's own refusal for a role that should never see this data.
Every record on this page is referenced by an opaque handle — an incident reference, a student reference, a case reference — never a name and never the free-text narrative of what happened. That is a stated boundary in the source, not an accident of what got built first: the modules that decide (the gate, the case workflow, the tiering engine) are deliberately kept separate from any place that would hold a narrative, so the decision layer can be read, audited, and reasoned about without also being a repository of sensitive text.
Where this page reports a count — a per-tier aggregate, an exclusionary rate — the count runs through the platform's shared small-cell suppression rule before it can leave the module: a cell below the FERPA small-cell threshold is suppressed to a bound rather than shown as a raw, potentially re-identifying number. An unauthorized viewer of any aggregate gets an empty result, never a suppressed-but-present one, because the honest failure mode of an aggregate is silence, not a number a determined viewer could reverse.
To be exact rather than flattering: none of this is a claim that we hold no data. A behavior record, an intervention assignment, or a restorative case is real, sensitive information about a real child, wherever it does eventually get persisted. The honest claim is narrower: every module that touches it today is walled at two layers, references it opaquely, and refuses by default rather than admits by default.
Seven suites, 153 tests
What is actually proven, and what a passing suite does not prove.
Seven test files cover the modules on this page and they run green: npx vitest run, executed by the author immediately before this page was written, on this exact set of files. The count here is that measurement, not a target.
The bound is as important as the result. A green suite proves a function computes the right answer. It says nothing about whether anything calls that function — and four of the seven below exercise modules that have no production caller at all. Those are flagged in place, on the chip, rather than mentioned once at the bottom.
12 testsclassroom-reward-chart.test.tsA non-integer or non-finite point value is rejected; keys and labels must be strict printable ASCII.
21 testsassess-early-warning.test.tsA flag fires only on a named signal past a named threshold; an unprovisioned signal can never fire.
15 testsassess-mtss-tier-engine.test.tsTier 3 is never suggested off a single fired signal; advisory/notMlModel are pinned true on every result.
29 testsspr-discipline-behavior-records.test.tsAn exclusionary consequence is blocked without due process; the manifestation-review check runs first.Exercises a module with no production caller
20 testsrestorative-justice.test.tsA circle cannot be scheduled without recorded consent; an illegal case-state transition is rejected.Exercises a module with no production caller
32 testssch-mtss.test.tstierRecommendation never mutates the persisted tier; the per-tier aggregate suppresses counts under 5.Exercises a module with no production caller
24 testssch-mtss-screening.test.tsThe problem-solving-team decision and the fidelity band stay advisory; predictiveMastery stays disabled.Exercises a module with no production caller
Common questions
The questions a dean of students or an MTSS coordinator actually asks.
Can I log a behavior incident on Behavior.software today?
No, and we would rather say that in plain words than let a pilot discover it. The consequence gate that would govern a serious incident is written and tested, but no route in this product persists an incident record. If your school needs a working incident log this week, this is not the product for that today, and we will tell you so on a call.
Then what does work today?
Two things, concretely. First, the MTSS/RTI tiering pipeline: attendance, a behavior-incident count, grades, and optional benchmark scores fold into a support tier, and a referral can open a special-education evaluation on the same student record. Second, a teacher's classroom positive-points chart: define behaviors worth an integer number of points, award them to a student in your own section, and read the leaderboard. Both are wired to a registered route today; everything else on this page is named as built or not.
Will an algorithm decide my child's discipline or support tier?
No. A support-tier SUGGESTION is computed from a published, deterministic threshold rule -- not a trained model -- and every suggestion the pipeline returns is pinned advisory:true and notMlModel:true on the value itself, not just in a sentence on this page. The persisted tier is always the one a human recorded. A consequence is never auto-imposed: the gate that would allow a suspension or expulsion refuses outright without due process, and refuses first of all when a student with a disability has not had a manifestation review.
Does this product predict which students will misbehave, or forecast mastery?
No, on purpose, even in a place where the code has a named seam for it. One module ships a function called predictiveMastery whose entire job, by its own header, is to never return a prediction until a real model is validated -- it returns a disabled scaffold today. We are naming that refusal as a feature rather than hiding an empty function.
Is restorative practice mandatory, or can a student opt out?
It is voluntary by construction, not by classroom norm. The function that would schedule a restorative circle checks for a recorded participation-consent flag first, and returns false without one -- there is no code path that schedules a circle absent that consent. This module is written and tested; it is not connected to a route, and we say so above rather than let the workflow look further along than it is.
What happens to the points if a family stops paying, or the school downgrades a plan?
Nothing, because there is nothing to stop. The reward-chart engine has no SupportedCurrency type, no cents field, and no price anywhere in its code -- it is free by construction. There is no pricing tier that could gate it, on this surface or any other described on this page: there is no pricing or checkout anywhere on this site.
Twelve, sorry, seven suites pass with a hundred and fifty-three tests. Does that mean every feature works?
It means the logic is correct. It does not mean every module is connected to anything -- four of the seven suites exercise modules with no production caller at all: the discipline consequence gate, the restorative-practice workflow, the tiered-intervention ledger, and the universal-screening extension. Those four are named on this page under "built, not switched on" rather than counted as features. A green suite proves a function returns the right answer; it proves nothing about whether anything calls that function in production.
Does the platform track which students are excluded and whether it is disproportionate?
The primitive to compute that exists and is tested: an exclusionary rate per mille and a disability-exclusion compliance flag, both computed directly over a set of incident records with no PII beyond opaque references. It has no production caller yet, for the same reason the incident log itself does not: there is no route that persists the incident records this primitive would run over.
Who can see a student's MTSS tier, restorative case, or intervention record?
The access rule is the same shape across every module on this page: an explicit team capability (access_mtss_team or access_restorative_team) or a school/district administrator, and NOTHING else -- a rep, a photographer, platform support, or an account manager is denied by role, before any capability check even runs. The database backs this with its own restrictive row-level policy, so a misconfigured application-layer capability can never lift the database wall for a role that should never see it.
Does any part of this touch a student's photo, yearbook page, or public record?
No. Every module on this page reads and writes opaque student and school references only -- no photo, no yearbook placement, no public-facing record. Behavior, discipline, and intervention data are handled as the sensitive, narrowly-walled category they are, entirely separate from the photography and publishing side of the platform.
How does this compare to a district's existing PBIS or discipline-tracking tool?
Most of that category is a fast, mobile incident and point log with a curated intervention library and a family app, and those are real, useful, advertised strengths -- we do not have them today and say so plainly on this page. What we have that a log by itself does not: a consequence decision enforced in a function rather than a policy document, restorative practice that cannot be scheduled without consent, and a tiering pipeline that states, on its own output, that it is not a model. If your school needs the log this week, use your existing tool. If you want the decision layer under it, that is the conversation to have with us.
What does it cost?
There is no price on this page and no checkout anywhere on this site. This is early access: three engines are wired and reachable, four more are written and covered but not connected to a route, and the honest next step is a conversation about which of those matches what your team actually needs first.
Is Behavior.software a school, a district, or a nonprofit?
No. It is a for-profit software product built by Stanley Studios. It is not a school, not a district, and not a nonprofit, and nothing here is a charitable gift of any kind. This is software a school buys, and we are precise about that difference because it matters.
Related surfaces
Adjacent products, each its own thing.
Behavior.software is the decision layer over a student’s behavior and support record. These are the neighbouring rails, kept as separate products rather than folded into a suite.
The money-out-to-staff side of a school’s back office — an entirely different sensitivity class from student behavior data, and never mixed with it.
What this page is and is not claiming
The whole posture, in one paragraph.
Behavior.software is early access: three engines are wired and reachable, the seven measured suites run green, and four more modules are written and covered but not connected to a route. It cannot log a behavior incident today — no route persists an incident record, and this page says so above rather than implying otherwise. It never auto-imposes a consequence: the gate that would allow a suspension or expulsion refuses without due process, and refuses first of all when a student with a disability has not had a completed manifestation-determination review. Restorative-practice participation cannot be scheduled without recorded consent — the scheduling function checks for it and refuses without it. The tiering pipeline runs no predictive or AI model: it is a deterministic threshold rule that pins notMlModel:true on its own output, and a named prediction seam elsewhere in the codebase ships as a disabled scaffold rather than an unvalidated forecast. Classroom positive-points charts carry no currency, no cents, and no price in their code. Four modules are written, tested, and have no production caller, and they are named above rather than counted as features. There are no adoption counts, no customers named, no testimonials and no invented figures anywhere on this page; the only measurement quoted is seven test files and 153 tests, run green before the page was written. There is no pricing and no checkout on this site. The honest next step is a conversation.
Behavior.software is early access. The MTSS/RTI tiering pipeline and the classroom positive-points charts are wired today; the due-process consequence gate, the restorative-practice workflow, and the tiered-intervention ledger are written, tested, and not connected to a route. We would rather tell you exactly which is which on the first screen than let a pilot find out.