Drafts for the case deliverables
Working drafts of the written parts of the case: how it was built, the pitch outline and the 12-month plan. They describe what exists today and mark everything that is a proposal or an assumption. Live evidence is on the validation page.
How we built it (draft)
Tools and data. Next.js and TypeScript, a deterministic planning engine, the Claude API for explanation, chat and profiling, Vapi for browser voice calls, Supabase for requests, Vercel for hosting. Data: the TCU Undergraduate Catalog 2026-27 PDF, the sample transcript supplied with the case, and BLS Occupational Outlook Handbook pages for job-market data.
Collection and structure. A script parses the catalog PDF into about 3,900 courses with descriptions, prerequisites and typical offerings. Majors, minors and the Core Curriculum were structured by hand with a source and page for each. Pairing of course headers and descriptions is done per page after earlier drift errors.
Profiles and requirements. A student is a transcript record (courses, grades, terms, attributes, transfer flags). Requirements are lists and groups with credit-hour rules. The engine matches one to the other, then places remaining courses in terms using prerequisites and the catalog's typical offering pattern. Claude only explains what the engine returns.
Important workflows. Transcript reading cross-checks a rule-based parser against Claude. Every Claude reply passes a verifier that rewrites or cautions on invented courses, unsupported numbers and phrases like "you will graduate". Goals and corrections build separate overlays and never edit the original record.
Checking against authoritative requirements. Each requirement carries a catalog source and page. An independent validator re-checks finished plans, and a golden-master test pins the sample plan so presentation changes cannot alter it.
When the AI was wrong or uncertain. (1) The prerequisite parser first read "a grade of at least C-" as an A; tests caught it and the pattern was fixed. (2) The catalog cites MANA 30350 as a prerequisite, but no such course exists; the engine ignores it, says so and sends it to an advisor. (3) The validator found a plan placing MARK 40253 without the course it can be taken concurrently with; this is reported as a failure and not yet fixed.
With another week. Get a real schedule feed and the real maximum credit load; have an advisor review the test plans; fix concurrent-enrollment placement; evaluate transfer credit with the registrar; review the career-to-course mapping.
Pitch outline (draft)
- Problem. Students can see what they have completed but not how today's choices affect the semesters ahead.
- Findings. The findings report: prerequisite chains, assumption-based offerings, unevaluated transfer credit, catalog-year mismatch.
- Sharpest bottleneck. The course that holds up the most later courses and would add a term if missed once, computed per student.
- Solution. Engine computes, Claude explains, advisors decide. Students can correct, challenge and compare without touching the official record.
- Demo. The four scenarios on the sample students page, then the requirements map for two profiles.
- Validation. Eight checks per plan, failures shown, no independent reviewer yet.
- Recommendation. A one-department pilot with an advisor in the loop, then expand on evidence.
- Impact. Planning accuracy, student understanding, on-time readiness, advisor time on complex cases.
- Appendix. Sources, test cases, plan comparisons, assumptions, calculations, known limits.
12-month plan (draft proposal)
This is a proposal. Staffing, budget and partner commitments are not decided, and no costs are estimated because none were supplied.
Months 1–3: authorize and ground. Agree access and privacy terms with the registrar and advising office. Get the official degree-requirement data and a section feed. Have advisors review the test plans and the career-to-course mapping. Replace assumed values (maximum load, offering patterns).
Months 4–6: pilot. One school or department, a small group of volunteer students with an advisor reviewing every plan. Sign-in through TCU accounts.
Months 7–9: measure and fix. Compare tool plans with advisor plans. Track errors, challenges raised and corrections made. Fix the failures the validator and advisors find.
Months 10–12: decide. Expand to more programs only if the criteria below are met.
Success measures. Share of plans an advisor accepts without changes; errors found per plan; students who say they understand their path better (survey); advisor time moved to complex cases; later, on-time graduation readiness.
Expand if advisors accept nearly all plans, serious errors are rare and fixed quickly, and students report better understanding. Change or stop if serious errors persist, data cannot be kept current, or privacy requirements cannot be met.
Risks. Wrong recommendations, stale schedules, privacy, overreliance on AI. Mitigations: sources and confidence labels, draft status, advisor review, minimal data, no model training on student records.
Alternatives considered. (a) A chatbot over the catalog only: easy but cannot compute prerequisites or delays. (b) A rebuilt degree-audit system: accurate but slow and expensive, and duplicates what the registrar owns.
Financial impact of one avoided semester (you supply the numbers)
No tuition, living-cost or university-cost figures were supplied, so none are assumed here. Enter your own sourced values. Student savings and university effects are kept apart because they are different things.
- Student, per avoided semester: enter tuition and living costs
- Students avoiding a semester: enter pilot size and share
- All students together: n/a
- University: enter marginal cost to see the university side