01 — The problem
The problem
In California, disability-service vendors are funded — through the Department of Developmental Services and the regional centers — to teach independent-living and vocational skills. Everyone they serve has an Individual Program Plan, or IPP: a set of goals, agreed under the state's Lanterman framework, that the vendor's lessons are meant to advance. After each session, an instructor records what happened. On a schedule, the vendor turns those records into a progress report — a documented, evidence-based account of how each person is moving toward their IPP goals.
This is exacting professional work, and it is the same for everyone in the field. Tying lesson objectives to a person's IPP goals, recording each session against them, and producing a progress report that stands up as evidence — none of it is busywork, and none of it is easy. A vendor can be doing excellent teaching and still find the reporting a heavy, slow, end-of-day task. The work deserves better tools than a spreadsheet.
It deserves tools that fit California, too. Much of the software for this was built for other markets, in English. For a vendor whose instructors work in a first language other than English — Korean, for many — and whose reports must be filed in English, the tools on the shelf don't quite match the work: its IPP structure, its regional centers, its rules.
That gap is where STRIDE begins.
02 — The approach
The approach
STRIDE started from a question, not a feature list: what makes a progress report strong?
Because that is the real problem — not filling in a report, but producing one that genuinely holds, as evidence, against a person's IPP goals. STRIDE is built on two decisions about how a report is made:
A report's quantitative spine — attendance, service delivery, evaluation scores — is aggregated directly from structured session records. By design, AI is confined to the narrative sections, and only on top of data that is already verified. An instructor records a couple of minutes of structured input per session, and everything quantitative is built from it the same way every time — fast to produce, and sound to stand behind.
Each session, an instructor scores a person against their own IPP goals on a standard ABA prompt hierarchy — from "no response" to "independent" — mapped to California's developmental-services domains. Informal observation becomes structured, goal-aligned evidence a progress report can be built from.
And STRIDE is built to work the way a bilingual vendor actually works — instructors recording in their own language, reports produced in English — so language stops being an extra layer of the paperwork.
03 — What we built
What we built
STRIDE is an ERP. Class management is the ground floor; reporting, evaluation, and compliance support are the core.
Semesters, classes, enrollment, attendance, and a curriculum instructors choose from instead of retyping.
Per-session records form the evidence layer; from them STRIDE produces the periodic progress, summary, and family reports, each moving through a draft → review → sign-off workflow.
Each person's IPP goals and objectives, scored every session, rolled up into progress over time.
Retention aligned to California's Title 17 rules, audit logs, and version history as part of normal use, so a vendor's own records stay in order without a scramble.
04 — The architecture
Built to the bar the data demands
The features above are the visible half of STRIDE. The other half is the one that decides whether software like this should be trusted with the data at all.
A system that holds disability records, in California, sits inside a dense regulatory landscape — rules for health-related information, the state's privacy law, the Lanterman framework, accessibility standards. Adding an AI layer on top of sensitive, health-adjacent records opens another regulatory dimension again. None of that is a feature a vendor sees. It is the architecture the whole product stands on — and it has to be designed in from the foundation, not retrofitted under deadline.
That is the work STRIDE is built around. Its architecture was designed to meet that bar from the first line of code. One visible example of the thinking: each vendor runs on its own physically isolated database — it costs a little more to operate, and it means a breach can never spread from one vendor to another. Most engineering like it is invisible by design.
Each vendor runs on its own physically isolated database — a breach can never spread from one vendor to another.
This is the competency the field actually runs on. Building safe, modern technology for disability services means knowing the disability work, knowing the regulatory landscape, and being able to satisfy both at once — the specialized capability the best IT firms bring to healthcare. It is the core of what IT ABLE does, and STRIDE is where you can see it.
05 — Where it stands
Where it stands
STRIDE's product surface is feature-complete: class and session management, structured session records, the goal-aligned evaluation model, and the full report-generation pipeline all working end-to-end with a first vendor partner. The AI integration layer — for bilingual report drafting — is built as a separate module, deliberately decoupled from the model call.
Putting AI on regulated disability records is a regulatory problem before it is a coding one: HIPAA requires a Business Associate Agreement with whatever serves the model, which in practice means a managed boundary — AWS Bedrock (with the Gemma open-weight model) or Google Vertex — not a direct call to a general-purpose API. STRIDE was architected for that constraint from the first commit.
Final pre-launch work: wiring that module to Bedrock on AWS — the move that brings the model under BAA. That is the remaining gate before the first vendor goes live.