How Teacher Credentialing Works

You can't build good software for a domain you don't understand — and in a small agency development team, the developers who speak the domain language get the interesting work. This module teaches the teacher-credentialing domain the way a new team member should learn it: enough to read a requirements document without a translator, and to smell when a data model is wrong.

The players

A state Commission (the credentialing agency) sets the standards for who may teach in public schools, issues credentials (the licenses themselves), and accredits the institutions that prepare teachers. Those institutions are Educator Preparation Programs (EPPs) — typically universities and district-run programs — that recruit candidates, deliver the required preparation, and formally recommend successful candidates to the Commission for a credential. The candidate is the prospective teacher moving through the pipeline: coursework, examinations, supervised student teaching, and background checks, ending (ideally) with a credential in a specific subject and grade span.

Notice the triangle: candidates interact mostly with their EPP; EPPs answer to the Commission; the Commission is accountable to the legislature and the public. Almost every workflow you'll build has all three parties on it, each seeing a different slice of the data — which is why per-record authorization was a whole security lesson.

Pathways and requirements

There is no single road to a credential. Pathways vary — the traditional undergraduate-then-program route, intern programs where candidates teach while completing requirements, and specialist routes — but they converge on the same core requirements the Commission verifies before issuing: completion of an accredited program, demonstrated basic skills, a clean background review, and subject matter competency — proof the candidate actually knows the subject they'll teach. That last requirement is the one this course's system serves, and the next lesson dissects it. For now the key fact: competency can be demonstrated multiple ways (examination, qualifying coursework, a degree in the subject), and someone must evaluate the evidence against the state's definition of the subject.

Why domain fluency makes you a better developer

Every entity in the system — Candidate, Epp, Credential, SubjectMatterRequirement, Determination — is a domain concept with rules attached, and the rules come from statute and Commission policy, not from a product manager's imagination. Developers who understand why a determination must be traceable, or why "the requirement" is versioned when standards change, write models that survive contact with reality; developers who don't produce a Status string column and a pile of special cases. Domain fluency also changes your conversations: you can challenge a requirement ("should a candidate see the gap report before staff review?") instead of transcribing it. The rest of this module builds that fluency: SMRs, the transcript problem, and the statewide service this system exists to deliver.