Cavi · Disability Services
The administrative work stops being yours.
Cavi for Disability Services is an AI-native platform for college and university accommodations: automated intake and documentation review, citation-backed decision support with your Director as the decision-maker, and FERPA-safe dissemination to faculty with acknowledgment tracked and escalation handled.
One coordinator. Hundreds of students.
Disability services offices are among the most under-resourced in higher education, demand keeps rising while staffing does not, and the students who most need accommodations are the least likely to chase paperwork through a broken process. The heaviest burden usually isn't the decision; it's the dissemination and the follow-up that come after it, repeated every semester.
Cavi does the administrative work so your team can do the human work, the interactive process, and the cases that genuinely need a person.
How it works
Specialized roles carry a case from a student's first request to acknowledged faculty letters, with a human decision at the center.
A plain-language student portal that confirms receipt quickly and, when something is missing, sends one clear list of what's needed instead of a rejection.
Produces citation-backed decision memos for your Director to review. Every decision stays human: the memo recommends, the Director decides.
After a human approval, routes the faculty letter through a FERPA gate and tracks acknowledgment: a reminder at 48 hours and a chair escalation at five days. Campus delivery configuration is validated during onboarding.
Every action is recorded in a tamper-evident trail, and any case reconstructs in under five minutes, the record you need the day someone asks for it.
Watches for the students who fall through administrative cracks, an accommodation that didn't roll over or an exam approaching with no arrangements booked, and flags them to your office.
Students always know where they stand
In a configured pilot, a student gets a My Access status view from the day a request arrives. The protected decision and action tier is enabled only after the institution's governance, FERPA, and deployment checks are complete. It is built for the student, not for staff, and it keeps a person in the loop the whole way.
Your accommodation request
Case DS-2026-0143
Step 3 of 5: Meeting scheduled
Your documents are in. Your coordinator is scheduling a time to talk through what will help.
We expect a decision by March 24.
The My Access status view, recreated from the interface. In development. Data shown is illustrative.
See your status in plain language
A student opens one link and sees exactly where their request stands, from received to decided, in plain words. No account to create, no system built for staff to navigate.
Read the decision, explained
When a decision is made, the portal explains it plainly: what was approved, any alternatives offered, and what could change it. No jargon, no scores, no paperwork to decode.
Send the one thing we still need
If something is missing, the student gets one specific, plain request instead of a rejection, and can respond and upload right there in the portal.
Ask us to look again
A student can ask the office to reconsider, or add a statement in their own words, without navigating a formal grievance. The portal is clear that the formal process stays separate and on its own timeline.
Anything beyond status is protected by a quick identity check, so a forwarded link cannot expose a student's case. That protected tier remains fail-closed until its launch checks clear. Staff can preview the applicable student view before anything goes out.
Why it's different
4
New
7
In review
3
Awaiting docs
12
Decided this week
Exam in 5 days, no proctoring bookedBIO 301
needs actionFaculty letter contains accommodations only.Diagnosis: no path to instructor.
The staff compliance view, recreated from the interface. In development. Data shown is illustrative.
FERPA enforced by design, not by procedure
A faculty letter physically cannot contain a diagnosis. The system is built so diagnostic information has no path to an instructor. Compliance is a property of the software, not a rule staff have to remember.
A person decides every case
No accommodation is approved or denied by software. Recommendations are prepared for your Director; a denial can only be issued after a documented, multi-point review and a signature.
Dissemination is the job, so it's the point
The hardest part isn't deciding accommodations, it's getting every letter to every instructor, confirming they acted on it, and chasing the ones who didn't. That end-to-end loop of send, confirm, remind, escalate is what the platform automates.
Built by a Director of Disability Services
The workflow is right because it was designed by someone who has run a disability services office: the interactive process, the documentation standards, and the fair-process principles are built in, not bolted on.
Fair without being identical
The platform surfaces past cases like the one in front of you so a person can decide consistently, and flags a decision that departs from precedent. It never reduces a student to a number: there is no consistency score, by design. Fairness is a prompt to a human, not an automatic rule.
The reasoning is on the record
Every case captures the functional barrier behind the request, the back-and-forth of the interactive process, the rationale for the decision, and the precedents it was weighed against. Years later, why this decision is a question the record can answer, and when a student's record must be removed, the platform proves it was.
Who it's for
Accommodations across didactic, lab, clinical, and board environments, functional technical-standards review, and board-exam documentation packets for NBME and COMLEX, with a plain portability statement that institutional approval is not board approval.
One coordinator carrying a very large caseload, a first-generation student body, and no compliance team to spare. The platform runs intake, delivery, and follow-up so the coordinator's time goes back to students.
High letter volume where the operational pain is dissemination: getting every letter to every instructor, confirming action, and re-issuing when a student changes sections mid-semester.
Works with the systems you already run
The platform is designed to sit on top of your existing campus software, not replace it. Approved accommodations flow out to the tools faculty and students use, and the signals that matter flow back in, every path through the same FERPA gate.
Student information system
Cavi accepts enrollment and registration data through a documented campus feed contract. The specific SIS connection (for example Banner, Colleague, PeopleSoft, or Workday Student) is configured and validated during onboarding before those records drive alerts.
Learning management system
Canvas accommodation writes can be demonstrated in a supervised sandbox. A live campus connection is enabled only after campus OAuth, SIS alignment, and onboarding validation. Every write passes the FERPA gate: only the accommodation setting travels, never a diagnosis, and re-sending cannot stack an extended-time multiplier.
Exam calendar and proctoring
When a campus provides exam and proctoring feeds, Cavi compares upcoming exams with booked arrangements and flags gaps for staff review. The threshold and feed-health rules are configured with the institution; staff remain the ones who act.
Email and advising
Faculty-email and status-only advising routing are scoped through a written, FERPA-limited integration plan for each campus. No case detail is routed outside Disability Services unless the recipient and fields are explicitly allowed.
Staff sign-in and provisioning
Staff single sign-on gets its own section below: per-institution SAML/OIDC with SCIM provisioning and de-provisioning, configured and validated with your IdP before a campus goes live.
Staff sign in with your identity provider
Per-institution SAML or OIDC (Microsoft Entra, Okta, and other OIDC providers), with just-in-time provisioning: a staff member's first sign-in creates their Cavi profile with the role their IdP groups map to. SCIM 2.0 keeps the roster in sync both ways: off-board someone in your IdP and their Cavi access is removed, no ticket.
Your team's SSO, domain routing, group-to-role map, and SCIM token are configured per institution and validated with your IdP before the campus goes live. Live single sign-on is enabled per campus during onboarding. Staff only: students never authenticate, and the public intake and letter-verification routes are never behind the IdP. Institutional SSO can never grant GrayMar operator privileges, and every sign-in and provisioning change writes an audit event.
We're onboarding design partners
Cavi for Disability Services is in active development. We're looking for a small number of institutions to shape it with. Bring a real workload and see how the platform handles it.
A readiness run you can watch before you commit. A deterministic, synthetic-only simulation walks the full accommodation lifecycle: request, staff clarification, review, a Director-only determination, gated communication, case close. It scores isolation, authorization, workflow, auditability, reliability, and communication gating. It proves those guarantees on synthetic data; it is not a production-readiness certification, and it touches no database, email, or identity provider.