GSA is a separate first-class object — an assessment, not an application. It has its own table, its own lifecycle and its own analytics, and it never enters the application workflows. A one-way bridge can later spawn a visa application from its data. One student, one login, both objects side by side.
Rule 1 — it is NOT an application. assessment is its own entity, not application.type='assessment'. Nothing that fires on an application fires on an assessment: no document pipeline, no expert-review orchestration, no submission automation, no application-lifecycle notifications, and a separate PostHog object/event taxonomy. The application state machine stays untouched.
Rule 2 — the student is the join point. Not the application. One student (one Clerk identity, one login) can own N assessments and N applications at once. The portal has to resolve “what am I working on?” across object types — that's a real new surface, not a detail.
Render the assessment (own routes + no-verdict end state) and a student home that lists both objects — assessments and applications under one login.
New “Assessments” section (invite → report → “Do the visa” migrate). Same pipeline UI + a previous stage.
School role: run assessments, import/invite agencies, decide + COE, and do visas for its own students. Built last.
Author the assessment as a template/step type. The pre-step lives in the same Steps→Sections→Questions model.
Provision schools (org client_type=school), branding, slug — mostly existing org management.
Untouched — assessment declares data, no certified translation stage.
Add/extend the school role + assessment scopes. Uses the existing per-app JWT templates — no new auth system.
Own entity + own lightweight state machine (4 states). Isolated module — no shared status enum, no shared lifecycle hooks with applications.
The Evaluator: GS risk rule set → band + 5 dimensions + flags. Triggered by the assessment lifecycle only.
The bridge. Reads an approved assessment → creates a visa application, pre-filled. One-way; the assessment record survives untouched.
Agency = global entity; school↔agency many-to-many. Import = match-and-link (never re-invite).
Untouched. It only ever sees applications — including the one the conversion service creates, which enters at the normal starting state.
Extend to invite for an assessment (target object type). Must resolve to the same student if the email already exists — no duplicate identity.
Same form-definition resolver — it resolves a template, agnostic of which object owns the answers.
Assessments are unlimited/free — so they simply never call billing. The credit is consumed by the application the conversion creates.
New task: on assessment submit → run scoring → persist report. Same broker/queue pattern as doc processing.
No new scheduled jobs required for v1.
Same insulated adapters; scoring calls go through the existing interface + model tiering.
New prompt set + AI context for the risk rubric, versioned & traced in Opik like every AI call.
application.type, migration link, school_agency association, assessment report. Additive schema, no rewrite.
COE PDF stored via the existing document path.
New lifecycle events: assessment invite, agency welcome, decision (approve/decline). Same event-driven layer.
Delivery channel unchanged.
Assessment never lodges to a gov portal — the submission layer is out of scope.
No new deploy target. Same dynos.
New code is covered by existing telemetry.
Only the credit rule (assessment free); no integration change.
No shared status enum. No polymorphic table. application needs no new column — the FK lives on the assessment side, so nothing in the visa domain has to know assessments exist.
Both rows coexist forever. The assessment is never mutated into an application — it's the source record, kept for audit, analytics and the school's history.
Everything that hangs off an application must not observe assessments. Concretely, these stay application-only:
Practically: the assessment module emits its own domain events. Any existing subscriber keyed on application events is untouched by construction — which is the main reason not to overload application.type.
⚠️ Biggest architectural decision: the assessment is a separate object with its own module, status enum and events — deliberately not application.type. That's what guarantees no application workflow ever fires for it, keeps analytics clean, and lets one student hold an assessment and an application at the same time under a single login. The only coupling is a one-way conversion service that creates an application from assessment data. New module inside the modular monolith — no new service, no new deploy target.
OneVisa · GSA stack-fit · grounded in the current Tech Stack (modular monolith · Next.js · FastAPI · Clerk · Supabase · Redis/Celery · OpenAI/Opik · Heroku · SuprSend/Resend/Polar). NEW/MODIFY marks are a proposed impact map for review, not a committed design.