The Transcript Problem
Every system worth building exists because some current process hurts. This lesson is the pain: how coursework-based competency evaluation works today, and why the transcript itself is such a hostile input. Understand both and the design of the statewide service (next lesson) becomes almost self-evident.
Today: every EPP for itself
Under current practice, each EPP independently reviews candidate transcripts against the SMRs. The same body of coursework can be carried to two programs and receive two different answers, because each program's analyst applies their own interpretation of whether "PHYS 152" covers the electromagnetism domain. The failure modes compound:
- Inconsistency. Candidates near a program boundary learn to shop for the friendlier evaluation — which undermines the standard itself.
- Delay. Reviews queue behind a small number of trained analysts at each program; candidates wait weeks for an answer that gates their enrollment decisions.
- Duplicated effort. A candidate applying to three programs triggers three full reviews of the same transcript. Statewide, that's thousands of redundant expert-hours a year.
- Candidate confusion. With no early, authoritative answer, candidates hedge — taking coursework they may not need, or paying for an exam a proper review would have shown was unnecessary.
Note what the problem is not: nobody lacks diligence. It's a structural problem — distributed judgment without a shared methodology — which is exactly the kind software can help with.
The input from hell
The transcript itself is the second half of the problem. A transcript is a semi-structured document: tabular in spirit, but with no standard schema across the thousands of institutions that issue them — often arriving as a scanned PDF. The recurring hazards:
- Naming variance. The same content hides behind "Calculus I," "MATH 1A," "Analytic Geometry and Calculus," or an abbreviation the registrar invented. Course numbers carry no cross-institution meaning at all.
- Transfer credit. Courses taken at College A appear on University B's transcript, sometimes retitled, sometimes as bare unit blocks ("TRANSFER CREDIT: 24.0 UNITS") with the detail living on yet another transcript.
- Quarter vs semester units. Institutions on the quarter system issue units worth 2/3 of a semester unit. Any rule phrased as "at least N units of X" silently breaks unless every evaluation normalizes to one system first — a classic source of inconsistent human results, and a bug you'll be asked to not reproduce in code.
- Grades, repeats, and withdrawals. Which attempts count? Does a C− qualify? Policy answers exist, but they must be applied uniformly.
Why this shape of problem fits software
Look at the two lists together: the process problems are all variance problems, and the document problems are all normalization problems. Software is good at exactly those — a single methodology applied identically, and messy inputs parsed into a canonical model (courses, units, grades) that rules can run against. What software must not absorb is the judgment call at the end. That boundary — automate the normalization and the consistency, keep humans on the determination — is the design thesis of the next lesson.