Controlled pilot

A GrayMar product · Disability Services

The administrative work stops being yours.

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.

Become a design partner

The problem

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.

The platform 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.

Donna: Intake & documentation

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.

Daniels: Decision support

Produces citation-backed decision memos for your Director to review. Every decision stays human: the memo recommends, the Director decides.

Herald: Dissemination & follow-up

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.

Choices: Audit & consistency

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.

Scout: Early warning

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.

The student portal

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.

my.access.example.edu/request

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

New

In review

Awaiting docs

Decided this week

Exam in 5 days, no proctoring bookedBIO 301

needs action

Faculty 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

Medical & health-science schools

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.

Community colleges

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.

Regional & master’s universities

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.

Integrations

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

The platform 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, the platform 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

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 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 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

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.

Talk to us Sign in

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.