The Statewide Service Vision
The answer to the transcript problem is not "make every EPP try harder" — it's to move the analysis to where the standard lives. The vision: a statewide, Commission-supported service that performs transcript analysis once, consistently, against a single published methodology. This lesson walks the intended workflow, then translates "standardized and transparent" into engineering requirements — because that translation is your job.
The workflow
An EPP submits a candidate's transcripts to the service. A Commission-defined methodology — the normalization and matching rules from the previous lessons, including AI-assisted analysis for the fuzzy step of proposing course-to-SMR mappings — evaluates alignment with the SMRs. Commission staff review the proposed analysis and make the final determination. The output is a standardized, portable report: whether subject matter requirements are met and, if not, exactly which domains remain as gaps — each addressable by targeted coursework or the corresponding examination.
Each emphasized word fixes a specific failure from the last lesson. Commission-defined kills interpretation variance. Staff review with final determination keeps accountable humans on the judgment — the AI proposes, people decide. Portable kills duplicated effort: one analysis travels with the candidate to every program. And a gap report gives candidates the early clarity that stops unnecessary coursework and exam fees.
Phased, on purpose
The service starts advisory: it informs EPP decisions, while formal authority stays where statute currently places it. Over time — contingent on validation and statutory authority — it may become a Commission-administered determination. That's not bureaucratic hedging; it's earned trust as a rollout strategy, and it constrains your architecture. The system must be valuable while advisory, must collect the evidence of its own reliability (analyst agreement rates, override rates and reasons, turnaround times), and must not hard-code assumptions about who holds final authority — that's a policy variable, and policy variables change.
What "standardized and transparent" means in code
Here is where domain language becomes a requirements list:
- Versioned methodology. Rules, SMR versions, and AI model/prompt versions are data. Every determination records which version of everything produced it — you must be able to explain a 2026 decision in 2029.
- Explainable output. A gap report states why: which courses were credited to which domains under which rule. "The model said so" is not an acceptable line item; AI proposals need attached rationale a reviewer can inspect and reject.
- Human-in-the-loop as workflow, not decoration. Staff review is a real state machine — proposed → under review → determined — with the reviewer identity, edits, and rationale captured in the audit trail from Module 7.
- Consistency as a testable property. Same transcript in, same analysis out. Determinism, golden-file regression tests over reference transcripts, and monitored drift when models or rules are updated — Module 8's discipline, aimed at the domain.
Every module of this course lands here: layered MVC and EF model the domain, security guards the records, tests guarantee the consistency, and the domain fluency you just built tells you what it's all for.