---
title: "Education & Teaching Qualifications (Teach USA)"
slug: education-teaching-qualifications
section: Applicant Journey
status: draft
description: "Teach USA collects a teacher's education history, teaching registration, and the documents that prove both."
last-updated: 2026-10-07
---

# Education & Teaching Qualifications (Teach USA)

Teach USA collects a teacher's education history, teaching registration, and the documents that prove both. This page documents the approved spec that links them: structured education records with permanent IDs drive **data-generated document requirements** in a dedicated Teaching Qualifications Documents hub, with automated extraction, passport name matching, per-document verification, and compliance-queue wiring.

> **Status (re-verified against BackOfficePrototype, 2026-09-30): APPROVED SPEC — tables and server services implemented**
>
> The PRD is approved for delivery as three dependency-chained tickets on **P11B: Workflow Studio & Step Library Phase 2** (Asana 1216839288136786 → 1216839250252504 → 1216839301448450, multi-homed on the IT Tech Delivery Kanban board). The new tables now exist in the implementation repo (migrations for Tasks #1885-#1887): `education_records`, `teaching_registrations`, `teaching_qualification_requirements` (the generated-requirements table; there is no `document_requirements` table), `document_extractions`, `document_name_mismatches` and `name_mismatch_support_links`, with the reconciliation service in `teachingQualificationReconciliation.ts` and reviewer routes in `qualificationReview.ts`. Client and portal delivery was not re-verified. The supporting infrastructure this spec builds on — the document review flow, Rules Engine V2, the Missing Compliance Documents and Compliance Review Required queues, the passport name-match rule family (REG-002), and the internal GCP Document AI pipeline — is all live. See Implementation Review Notes below for the verified deltas.

## Overview

Today the Education step stores answers as one loose block of form data and the documents hub asks for generic uploads with no link to what the applicant said. The spec replaces this with a linked structured-data + document-verification workflow:

1. The applicant enters education and teaching-registration details as structured records, each with a permanent ID.
2. The system generates the exact document requirements each applicant owes — transcripts, degree certificates, teaching registration, and (where needed) name-change evidence.
3. Uploads are read automatically, compared against the applicant's answers and passport, versioned, and individually verified by staff.
4. The hub completes only when every required document is **verified, waived, or formally marked not applicable** — never merely uploaded.

## Problem Statement

- Education answers combine degree and area of study in one field, carry no completion status, and have no stable identity per qualification — nothing else in the system can reference "this specific degree".
- Upload steps are blank and generic; an applicant with three degrees can upload one unlabeled file.
- Upload alone counts as progress: no per-document verification status, no supersede history, no qualification-level rollup.
- Name differences against the passport (marriage, divorce, legal name change) are handled ad hoc.
- Missing or unresolved documents do not automatically reach compliance queues.

**Non-goals:** no uploads inside the Education step itself (uploads live only in the hub); no dynamic creation of workflow *steps* — hub and subtask placement stays operator-only in Workflow Studio, only the requirement rows and cards inside are data-generated; and this builds on, never replaces, the existing doc-review flow, Rules Engine V2, and compliance queues.

## Part A — Education Step

The Education step collects four sections: Education History (repeatable), Languages (repeatable), Skills / Awards / Certificates (rich text), and a new Teaching Registration Summary.

### Education History Records

Each repeatable education record collects:

| Group | Fields |
| --- | --- |
| Institution (all required) | Name, location, contact name, email, website |
| Qualification (all required) | Degree Level (existing dropdown), **Qualification Name** (e.g. Bachelor of Education), **Area of Study / Major** (e.g. Foundation Phase Teaching) |
| Study dates | Start month/year, end month/year; "currently studying" checkbox hides end dates and stores `endMonth = null`, `endYear = null`, `currentlyStudying = true` |
| Qualification status (new, required) | "Did you complete this qualification?" — Yes, completed / No, currently studying / No, not completed |
| Document availability (new, required) | "Do you have documents for this qualification?" — Yes / No / I have requested them |

The existing combined "Degree / Area of Study" field is **split** into Qualification Name + Area of Study — the documents hub must display each qualification clearly. Qualification status is distinct from current enrolment: an applicant may have studied somewhere in the past without completing.

### Teaching Registration Summary

New section, no uploads. "Are you currently registered or licensed to teach?" — **Yes / No / Application pending / Not required in my country**. When Yes or Application pending is selected, the section expands to collect licence type, registration number, issuing authority, country of issue, issue/expiry dates, licence status (Active / Expired / Pending / Provisional / Suspended / Other), and multi-selects for authorised subjects and grade levels. This data prepopulates the Teacher Certification document subtask.

### Saving & Stable Record IDs

On submit, every education record is saved with its own **permanent ID** (e.g. `educationRecordId = edu_01HX…`) — never array position. Submission generates or updates the hub's document requirements while preserving the record ↔ requirement relationship, and the step locks while under review per the existing step access & lock contract. The form-engine bundle must round-trip server-assigned record IDs unchanged through edit / reorder / delete (Form Control team dependency).

## Part B — Teaching Qualifications Documents Hub

The hub's content is generated dynamically from the structured Education data — never a collection of blank generic uploads. Every card carries qualification context: qualification name, institution, area of study, completion status.

### Hub Subtasks

| # | Subtask | Generation |
| --- | --- | --- |
| 1 | Academic Transcripts (renamed from "Academic Record"; never "Teaching Transcript") | One card per applicable education record |
| 2 | Degree / Diploma Certificates | One card per record with completion status = completed |
| 3 | Teacher Certification | Prepopulated from teaching-registration data |
| 4 | Name Change Supporting Documents (conditional) | Active only while at least one unresolved name mismatch exists (server-driven visibility) |

Transcript applicability is **configurable in Workflow Studio by degree level** (e.g. High School optional; Certificate through Doctorate required). Degree certificates are never requested for a qualification that is currently studying or not completed — proof of current study, if needed, uses separate configurable requirements (Proof of Enrolment, Current Academic Record), never a mislabeled certificate. Accepted file types: PDF, JPG, JPEG, PNG.

### Teacher Certification Branching

| Registration answer | Behaviour |
| --- | --- |
| Yes | Certificate required |
| Application pending | Proof-of-application upload required; certificate optional once issued |
| No | No required upload auto-created; routes to a teaching-eligibility rule for review |
| Not required in my country | Never silently passes — creates a manual-review result entering the Compliance Review Required queue |

## Document Processing & Name Matching

After each upload of a degree certificate, diploma, transcript, or teacher certificate: store the original file and create a versioned application document; **extract** holder name, institution, qualification, dates, and registration number with a confidence score; **compare the extracted name to the applicant's passport legal name** (authoritative once the Passport Information step is submitted and verified; before that, compare against Personal Information and mark the comparison provisional); compare institution and qualification against the Education answers; write evaluation evidence and update rule results and queue membership.

Matching normalizes capitalization, punctuation, spacing, accents, ordering, middle-name omission, and initials — "Jacobs, Mary A." is **not** a mismatch for "Mary Anne Jacobs"; a material surname difference (passport "Mary Jacobs" vs degree "Mary Williams") **is**. Extraction uses the existing internal GCP Document AI pipeline with no external AI fallback.

### Applicant Mismatch Flow

A detected mismatch raises an inline issue on the specific document showing both names, qualification, and institution. The applicant selects a **Reason** (Marriage / Divorce / Legal name change / Different surname used previously / Document error / Other), a reason-dependent **Supporting Document Type** (e.g. Marriage → marriage certificate; Document error → corrected certificate or institution letter), and uploads the supporting document. **One supporting document may resolve several mismatches** sharing the same previous name — stored as a many-to-many relationship, never requested twice. The mismatch stays unresolved until evidence is uploaded **and reviewed**.

Staff-side routes (authenticated, permission `qualifications.review`): `POST /api/name-mismatches/:id/reason` records the applicant's reason on their behalf and sets the reason-dependent supporting document type; `POST /api/name-mismatches/link-evidence` links one supporting document to one or more unresolved mismatches; `POST /api/name-mismatches/:id/resolve` records the reviewer decision (`decision` of `resolved` or `dismissed`, optional `note` up to 2,000 characters). An unknown mismatch returns 404, and `reason` or `resolve` on a mismatch that is already `resolved` or `dismissed` returns 409 `CONFLICT` with `details.code` `MISMATCH_ALREADY_RESOLVED`.

## Verification Lifecycle & Hub Completion

Per document: `pending` → `processing` → `needs_applicant_action` / `under_review` → `verified` / `rejected`, plus `superseded`. A replacement upload never overwrites — the original becomes `superseded`, the replacement enters `under_review`, full audit history preserved. Per qualification, a computed rollup: Documents not started / Documents incomplete / Under review / Applicant action required / Verified / Verification failed / Not applicable.

**Hub completion:** all required generated requirements must reach `verified`, **waived by authorised Globus staff** (mandatory reason + audit), or **not applicable** (recorded reason + audit). An uploaded document alone never completes a requirement.

**Reviewer workspace:** per-qualification cards inside the rendered workflow step show the uploaded file, extracted values, expected values from Education, name/institution/qualification comparisons, AI confidence, rule results, supporting name evidence, and the applicant's explanation. Actions: Verify · Reject · Request replacement · Accept with supporting name evidence · Escalate — overrides, waivers, and accept-with-evidence require a note. A reviewer never needs multiple unrelated screens to understand one qualification.

**Permissions.** `qualifications.review` gates the reviewer workspace (`GET /api/applications/:id/qualification-review`), the document decision (`POST /api/documents/:id/qualification-review-action`: verify, reject, request_replacement, accept_with_evidence or escalate; a note is required for every action except verify; an invalid state change is 409 `INVALID_QUALIFICATION_TRANSITION`) and the name-mismatch routes (`POST /api/name-mismatches/:id/reason`, `POST /api/name-mismatches/link-evidence`, `POST /api/name-mismatches/:id/resolve`). `qualifications.waive` (restricted, reason required) gates `POST /api/qualification-requirements/:id/waive` and `.../not-applicable`, each with a mandatory reason; an already waived or not-applicable requirement returns 409 `REQUIREMENT_ALREADY_WAIVED` or `REQUIREMENT_ALREADY_NOT_APPLICABLE`. `references.review` gates staff review of completed reference submissions (`POST /api/reference-submissions/:id/review` with decision approved or rejected, notes required to reject, and `forceReason` required to reject a previously approved reference) and the reference template PDF reads.

**Reviewer routes and conflict codes.** `GET /api/applications/:id/qualification-review` and `POST /api/documents/:id/qualification-review-action` (body `action` of `verify`, `reject`, `request_replacement`, `accept_with_evidence` or `escalate`, plus `note`) need `qualifications.review`. `POST /api/qualification-requirements/:id/waive` and `.../not-applicable` (body `reason`) need `qualifications.waive`. Every action except `verify` requires a `note` (`400 VALIDATION_ERROR`, `details.field` `note`), and the document must be a qualification document type. The actions move the document to `verified` (`verify`, `accept_with_evidence`), `rejected`, `needs_applicant_action` (`request_replacement`) or `under_review` (`escalate`). Conflicts return `409 CONFLICT` with the code in `details.code`: `INVALID_QUALIFICATION_TRANSITION` (the document state machine refuses the move; details `fromState` and `toState`), and `REQUIREMENT_ALREADY_WAIVED` and `REQUIREMENT_ALREADY_NOT_APPLICABLE` (the requirement already carries that resolution; waiving and not-applicable exclude each other). The name-mismatch routes and their `MISMATCH_ALREADY_RESOLVED` conflict are described under Applicant Mismatch Flow.

## Reconciliation After Education Changes

The idempotent service `reconcileTeachingQualificationRequirements(applicationId)` runs on Education save/submit, record edit/removal, teaching-registration change, and workflow-configuration change. It creates missing requirements, updates existing linked ones, marks obsolete ones no longer required, and **never hard-deletes documents or audit history**. Specifics: adding a qualification creates new requirements; editing institution/qualification names updates display info and flags for re-evaluation; completed → currently studying marks the degree-certificate requirement no longer required while retaining the document; deleting a record marks it and its requirements `withdrawn_from_application` after an applicant confirmation, preserved in audit history.

## Data Model (New Tables)

| Table | Purpose |
| --- | --- |
| `education_records` | Institution details, degree level, qualification name, area of study, dates, currently_studying, completion_status, document_availability, display_order, status |
| `teaching_registrations` | Registration status, licence type/number, issuing authority, country, issue/expiry dates, licence status, authorised subjects/grade levels |
| `teaching_qualification_requirements` | Per-application generated requirements; requirement_type (`academic_transcript`, `degree_certificate`, `proof_of_enrolment`, `teacher_registration_certificate`, `teacher_registration_application_proof`, `name_change_supporting_document`), links to education record / teaching registration, required, source, status, generated_reason, waived_by/reason |
| `applicant_documents` (existing table, extended) | Versioned uploads; version_number, state, supersedes_document_id / superseded_by_document_id |
| `document_extractions` | Extracted values + confidence + raw payload |
| `document_name_mismatches` | Expected vs extracted name, mismatch type, applicant reason, status, reviewer, resolution note |
| `name_mismatch_support_links` | Many-to-many mismatch ↔ supporting document |

## Rules & Queue Wiring

All authored through the Rules Engine V2 pipeline: qualification-document-required rules fail into the **Missing Compliance Documents** queue; degree-certificate / transcript / teacher-certification verification rules pass only when reviewed and verified; name, institution, and qualification match rules compare Education data against extracted document data (name match supports Pass / Pass with supporting evidence / Needs review / Fail); the name-change-evidence rule fails into Missing Compliance Documents when evidence is absent, or **Compliance Review Required** when evidence awaits review.

The seeded reason codes and rules for this pipeline (all keys end `.j1_teacher`):

| Reason code | Rule key | Queue | Raised when |
| --- | --- | --- | --- |
| `QUALIFICATION_DOCUMENT_MISSING` | `documentation.qualification_documents_complete.j1_teacher` | Missing Compliance Documents | An active, required teaching qualification requirement has no usable upload (missing, rejected, or superseded without replacement). The applicant is asked to upload in the Education section. |
| `DEGREE_CERTIFICATE_NOT_VERIFIED` | `documentation.degree_certificate_verified.j1_teacher` | Compliance Review Required | A required degree certificate is not staff-verified (latest upload rejected or verification not established). |
| `ACADEMIC_TRANSCRIPT_NOT_VERIFIED` | `documentation.academic_transcript_verified.j1_teacher` | Compliance Review Required | The same for a required academic transcript. |
| `TEACHER_CERTIFICATION_NOT_VERIFIED` | `documentation.teacher_certification_verified.j1_teacher` | Compliance Review Required | The applicant said registration is not required in their country (a definite outcome that is reviewed, never silently passed), or the registration evidence was rejected. |
| `QUALIFICATION_NAME_MISMATCH` | `identity.qualification_name_match.j1_teacher` | Compliance Review Required | The extracted holder name materially differs from the legal name and is not resolved with accepted supporting evidence. The applicant is pointed to the Name Change Supporting Documents task. |
| `QUALIFICATION_INSTITUTION_MISMATCH` | `documentation.qualification_institution_match.j1_teacher` | Compliance Review Required | The extracted institution differs from the institution on the linked education record. |
| `QUALIFICATION_DETAILS_MISMATCH` | `documentation.qualification_details_match.j1_teacher` | Compliance Review Required | The extracted qualification or award name differs from the linked education record. |
| `NAME_CHANGE_EVIDENCE_REQUIRED` | `documentation.name_change_evidence.j1_teacher` | Missing Compliance Documents | An open name mismatch has no supporting evidence linked, so the name change supporting document requirement is active. |

All eight rules fail into a `REVIEW_QUEUE` action with `blocksTransition` false; the two missing-document codes carry a blocking severity hint on the reason code but the rule action itself does not block a transition.

The verification, institution and details codes show the applicant only a neutral message that the team is reviewing and no action is needed.

## Delivery Plan

Three dependency-chained tickets on P11B:

1. **Structured education records + generated requirements** — Education step redesign, the three core tables, stable IDs, reconciliation service, hub cards with qualification context, subtask renames, per-degree-level transcript configuration.
2. **Verification lifecycle + reviewer workspace** — expanded statuses, supersede versioning, qualification-level rollup, requirement-driven hub completion, waivers with audit, single-screen reviewer workspace.
3. **Extraction, passport name matching + supporting-evidence flow** — extraction for qualification documents, name matching, mismatch + supporting-evidence flow, conditional Name Change subtask, rules and queue wiring.

External dependencies: the **Form Control team** (record-ID round-trip through the form-engine bundle) and the **Applicant Portal team** (rendering generated requirement cards, mismatch prompts, and upload UX from the Globus-served hub structure — an integration-contract change).

## Implementation Review Notes

Verified against the implementation repo (2026-07-23) — deltas the delivery tickets must reconcile:

- **Requirement generation is a new mechanism, not an extension of the current one.** Today document requirements are derived at *publish time* by scanning each step's upload fields tagged with `metadata.documentType` (`documentRequirementDerivation.ts` → `workflow_step_document_requirements`). This spec introduces *runtime, per-applicant* generation from structured data. Both must coexist: publish-time derivation keeps serving generic tagged uploads while the new `teaching_qualification_requirements` table serves qualification-scoped rows. The resolver (`documentRequirementsResolver.ts`) and the applicant Documents tab will need to merge both sources without double-counting.
- **Two status vocabularies must be mapped, not duplicated.** The live review path treats `verified` / `approved` / `accepted` as equivalent verified states (`isVerifiedDocumentState` in `shared/documentRequirements.ts`). The spec's per-document lifecycle (`pending` … `superseded`) is broader. Phase 2 should extend the existing state model rather than introduce a parallel one, and keep the shared predicate as the single verified-state authority.
- **Versioning partially exists.** `document_versions` rows with reviewer audit and per-version download paths are already live in the requirements payload (`RequirementDocumentVersion`). The spec's `applicant_documents.supersedes_document_id` overlaps — Phase 2 should decide explicitly whether to extend `document_versions` or introduce the new table, and record the decision.
- **Passport name matching has an existing pattern to reuse.** The REG-002 passport name-match rule family, its reason codes, and the Missing Compliance Documents / Compliance Review Required queue definitions are all seeded and live. Phase 3's qualification name-match rules should follow the same seed + reason-code-envelope pattern rather than a bespoke path.
- **The extraction guardrail matches reality.** The internal GCP Document AI adapter is the only OCR path and hard-fails with no OpenAI fallback — exactly the architectural guardrail the spec states. Qualification-document extraction extends this adapter's document scope.
- **Wave-2 precedent for per-document verification rollups.** The confirmed-match document wave (`wave2DocReview.ts`) already derives a work-item status from per-document verified state. The qualification-level rollup in Phase 2 is the same shape and can follow its pure-shared-module pattern.

## Related Pages

- Passport-Authoritative Identity — the passport legal name this spec matches against.
- Workflow Studio — operator placement of the hub and subtasks; per-degree-level transcript configuration.
- Rules Engine / Queue System — the V2 rule pipeline and compliance queues this spec wires into.
- Applicant Portal — My Documents & Resources — the portal rendering contract the generated cards flow through.
- Section Locking & Unlocking — step lock behaviour while Education is under review.