Inspiration

Through high school, a student with ADHD or a learning disability doesn't have to fight for support — the school runs their IEP or 504 plan automatically. The day they graduate, that system vanishes. The scale is documented: per the federal High School Longitudinal Study, even among students who still have a disability in college, only about one in three ever inform their school (NCES 2022-071) — the other two navigate college without the support they had for years. In college, they must self-identify, find the disability office, decode documentation standards, and re-request everything, and every college does it differently. UIUC's DRES recommends starting about six weeks before classes and gates its MyAccessCenter portal behind enrollment. UIC's DRC lets students begin before their documents are complete and says ideal documentation is current within five years. Illinois State requires an Access Training appointment and new faculty letters every term. Same student, same records, three different bureaucracies — and the cost of missing a lead time is a semester without the support you had for years.

Illinois quietly passed something remarkable: 110 ILCS 195/10 requires public colleges to accept an IEP or 504 plan that was in effect immediately before high-school exit as sufficient to establish disability status. But establishing status is not the same as getting a specific accommodation approved — and conflating those two questions is exactly the mistake a generic chatbot makes. That distinction became our product. Why hasn't this been built before? Because every college owns its own intake portal, but no institution owns the student's transition between schools — so nobody built for it. We did.

That's this hackathon's theme in miniature: the technology behind a public system people depend on — disability services at public universities — is fragmented and manual, and Handoff is the optimization layer that makes it navigable.

What it does

Handoff turns a student's existing records into a verified, source-linked Access Passport, then compares it against the real published processes of three Illinois public colleges: UIUC (DRES), UIC (DRC), and Illinois State (SAAS).

Anyone can upload any PDF. An AI extractor proposes candidate facts, but every fact must carry a quote that appears character-for-character in the document or it is discarded, and nothing enters the Passport until the student confirms it on screen. A random, unrecognizable PDF gets an honest "couldn't extract recognizable support records" — never a crash, never a fabricated extraction.

The heart of the app is one file producing three different answers. A deterministic rules engine outputs one of exactly seven readiness statuses per college. Our synthetic student Jordan (active 504) gets documentation clarification recommended at UIUC, ready to begin at UIC, and ready to request at Illinois State. Our second synthetic student Sam (504 expired two years before graduation, no current evaluation) gets missing required information at all three. Same pipeline, different evidence — and every cell links to the official source behind it. Judges don't have to take our word for it: the comparison screen lets you edit the 504's end date, the evaluation date, or the high-school exit date in typed date fields and watch every status recompute live through real date math. Restoring the originals returns byte-identical engine output.

Timing is typed, never flattened: legal deadlines, priority deadlines, recommended lead times, processing estimates, and rolling processes are five different things, and UIUC's "six weeks" is rendered as a lead time, never a deadline. A caseworker chat explains where you stand while citing confirmed fact IDs, and a deterministic integrity monitor screens every request before it reaches the model — "make my ADHD sound more severe" is refused without a single model token. A post-generation check intercepts any output containing "you qualify" or "will be approved," because approval belongs to the institution, full stop. There's also a sandbox application where provider certifications, signatures, attestations, and final submission are structurally locked server-side with an HTTP 403 rather than a prompt rule, an intake-rehearsal coach, a contradiction detector (our synthetic packet deliberately contains a 50%-vs-100% extended-time conflict it must catch), and a full audit trail of every action.

How we built it

The stack is Next.js 15, TypeScript, React 19, and Tailwind v4 — but the architecture is the point. All eligibility and readiness logic lives in a deterministic decision core of roughly 470 lines of dependency-free, source-commented TypeScript. Every rule object carries its official URL, a verbatim excerpt of the official text, a citation label, and a last-verified date. Facts in, statuses out: the same input produces byte-identical output, and the engine runs without the app at all —

npm run engine -- --student jordan
npm run engine -- --student sam

— printing all three colleges' statuses with citations straight from the terminal.

Exactly two LLM roles exist, both outside the decision path. The extractor runs in strict JSON mode, is Zod-validated, passes a verbatim-excerpt provenance gate, and falls back to a deterministic pattern extractor on any failure. The caseworker's prompt is rebuilt on every turn from an "AccessGraph": the verified facts, the current workflow state, and explicit allowed and blocked claims and actions. The model never decides a case. Behind it all sit 61 Vitest fixtures covering expired plans, date boundary conditions (an active-through date equal to the exit date counts; one day earlier does not), conflicting extended-time values, image-only PDFs, unsupported colleges, prompt-injection text embedded inside a PDF, banned-vocabulary scans of engine output, and same-input-twice determinism checks. When things go wrong — a garbage upload, a model outage, a malformed request, an unsupported college — the app degrades to an honest, specific answer instead of an error page. The synthetic packets are generated with pdf-lib, read back with PDF.js, and watermarked "SYNTHETIC DEMONSTRATION RECORD" on every page.

We ran pilot sessions with five students heading to college with disabilities, using Jordan's synthetic packet. The clearest pattern: participants couldn't tell whether anything across the documents contradicted anything else — which validated the contradiction detector we'd specced and pushed us to make the conflict view show both sources side by side. Several also said they'd feel unprepared for the intake meeting itself, which is what the rehearsal coach is for.

Challenges we ran into

Our own AI broke our own rules. Mid-build, the extractor classified a school counselor's suggestion in a Summary of Performance as a "provider recommendation," which flipped UIUC's status — but only licensed providers count. The fix wasn't a better vibe; it was a tighter category definition plus the provenance gate, and that bug is why the two-question separation has to live in code rather than prompts. Determinism fought the wall clock too: "current within five years" depends on when you ask, so we pinned the engine's reference date and made it explicit input, meaning rehearsed output can't silently change on demo day. The banned-words audit humbled us — we ban "eligible," "approved," "guaranteed," "will receive," "rejected," and "you qualify" from output, and an audit found our own interface violating the rule in four places, including a headline reading "Deadline-ranked" directly above a disclaimer promising we never call everything deadlines. And the infrastructure bit back: Google retired the Gemini model we'd wired for new accounts — but our fallback design meant the app answered deterministically instead of crashing. The safety net caught its own maintainers.

Accomplishments that we're proud of

The AI cannot introduce a single unsupported disability claim into an application: every substantive sentence traces to a student-confirmed fact with a page-level source, or it doesn't render. The same verified record produces three genuinely different, cited college results, and judges can steer the engine with date fields and get byte-identical restores, live — try to break it. Question 1 — does the evidence establish disability status under 110 ILCS 195/10? — and Question 2 — does it support this specific accommodation? — are never blended, anywhere in the system. And the interface has an identity of its own: the whole app is styled as the student's case file, with manila folder tabs, ink stamps, and highlighter-marked official quotes, because every design choice traces to the same insight — the student who leaves high school without a self-advocacy playbook needs to own their file, see the source behind every claim — because a student burned by bureaucracy doesn't trust software's word, and the cost of one missed lead time is a semester without support — and never be told "you qualify" by software that can't promise it.

What we learned

Accessibility isn't only about a usable interface — it's about preserving autonomy while preventing the system from making decisions or disclosures on the student's behalf. The hard part of "AI for public services" isn't generation; it's restraint: encoding what the system must never say, sign, submit, or infer. Honest statuses like "portal unavailable until enrollment" turned out to be the design story, not a limitation of it.

What's next for Handoff

The first conversation is with a high-school transition coordinator and one of the three disability offices we already encode — and Illinois has organizations built for exactly this handoff, like the Illinois Center for Transition and Work and Equip for Equality, the state's designated disability-rights organization. From there: pilot sessions with disabled students, more Illinois public institutions (the policy schema already versions its sources and fails closed when an official page changes), provider-request tracking, and the post-approval semester loop — letters, term activation, and accommodated exam scheduling. Every public college in the country runs on published rules — Handoff can encode all of them.


AI usage disclosure: In the product, AI is used in exactly two roles — a document extractor and a caseworker chat — both structurally excluded from decisions: extracted facts require verbatim in-document quotes and student confirmation, and all eligibility, readiness, timing, and permission logic is deterministic TypeScript. In development, AI-assisted coding tools(Claude) were used for implementation under our direction; every rule in the decision engine was hand-reviewed against the official sources cited in the code. All demo records are synthetic and watermarked; no real student data exists anywhere in this system.

Sources: 110 ILCS 195/10 · NCES 2022-071 — Use of Supports Among Students With Disabilities and Special Needs in College · UIUC DRES — Apply · UIC DRC — New DRC Student · Illinois State SAAS — Documentation

Built With

Share this project:

Updates

Submission history