---
title: "Summer Work Travel Eligibility"
slug: swt-eligibility
section: Applicant Journey
status: stable
description: "The full picture of how the platform decides when a Summer Work Travel applicant is allowed to work in the US — from proving they are a full-time student, to reading and translating their documents, to overlapping the dates their governm…"
last-updated: 2026-10-07
---

# Summer Work Travel Eligibility

The full picture of how the platform decides when a Summer Work Travel applicant is allowed to work in the US — from proving they are a full-time student, to reading and translating their documents, to overlapping the dates their government and their school both permit.

## What This Is For

Summer Work Travel (SWT) lets international students work in the US during their school holidays on a J-1 visa. The US government sets strict rules about who qualifies (you must be a current full-time student) and when each student is allowed to work. Our platform automatically checks every applicant against those rules so we don't accept a student — or a set of work dates — that would put the student, or the program's visa sponsorship, out of compliance.

There are two halves to eligibility, and an applicant must clear both:

- Are you a qualifying student? Proof of full-time enrollment, plus verified vacation dates. This is the Proof of Student Status step.
- Are these dates allowed? The work dates must fall inside the window where the student is both permitted (by their government) and free (by their school) to work. This is the eligible window.
## The Full Flow, End to End

Here is the whole pipeline, in order. Each step has a clear owner, and one principle holds throughout: Globus decides, the portal only shows the answer.

The US State Department publishes, per country, the months that country's students may
participate. Those windows live in Globus only, as date objects hung off the Program, and
the Globus Rules Engine reads them as the single source.
The windows don't change on a fixed schedule — some seasons nothing changes, sometimes only
a country or two, sometimes nothing for years. So the owner reviews them against the latest
State Department chart and edits only what moved (no bulk reload, no audit trail), then
marks a non-blocking "reviewed / current" flag. The flag never blocks applications or
anything downstream — it just shows when the dates were last confirmed current.
On the Proof of Student Status step, they select the document type (transcript, enrollment letter, or other), upload
the document (PDF, JPEG or PNG) and enter their university country and vacation dates.
Two Globus AI capabilities run in sequence: one detects the language, translates, and
extracts the enrollment facts; the other scores how confident it is that the document
proves full-time enrollment. Neither makes the final decision — when confidence is low, it
hands off to a human.
The Rules Engine passes a confident proof, sends an uncertain one to a Globus reviewer
(and asks for a clear letter), and routes a missing one to a follow-up queue. Nothing is
ever auto-rejected.
A verifier — the recruiting partner, or Globus for direct sales — confirms or amends the
dates (that becomes the authoritative record), or asks for proof: a school calendar or a
professor/university verification, both accepted equally.
It overlaps the country's official window with the verified vacation dates to produce the
eligible window — the only stretch the student may actually work.
A soft, non-blocking warning early on (at Proof of Student Status, if the dates don't
overlap), then a hard gate later (at the Camp Contract step: the dates must fit the
eligible window and the work period must be four months or less).
## The Two Windows That Must Overlap

The when can they work half of eligibility comes down to fitting inside two windows at once:

### 1. The country's official window

The US Department of State publishes, for each country, the months when that country's students may participate (it tracks their school calendar) on its official Summer Work Travel program page . A Brazilian student's window is in our winter; a German student's is in our summer.

### 2. The student's own university holiday

Their actual vacation dates from their school — once verified (see below).

### 3. The overlap of the two

A student can only work during the time that falls inside both. We call this their eligible window, and it's automatically calculated and shown to them on the step in the applicant portal.

| Student | Their country's official window |
| --- | --- |
| Brazil | Falls in the US winter (their school summer holiday) |
| Germany | Falls in the US summer (their school summer holiday) |

## Proof of Student Status

Before any dates matter, the applicant has to prove they are a current full-time student. This all happens on the Proof of Student Status step — the same screen in both the applicant portal and the partner portal, with nothing built partner-specific. The step only collects information and shows back the platform's response; it never decides anything itself.

The step is shown for every answer on the About Me Education Background question, including "No, I am not currently a student". An applicant who says they are not a student still sees the step, but is blocked as ineligible by the declared-current-student rule; only the step's visibility is unconditional.

### Proving Full-Time Enrollment

The applicant selects the document type and uploads the matching document. Two types are accepted equally:

- a university transcript, or
- an enrollment letter from their university.
The selector also offers Other proof of student status, but an Other (or unconfirmed) type can never auto-pass — it always goes to a human reviewer, however confident the AI is. The upload accepts PDF, JPEG and PNG only. The bar is the same whichever of the two they choose: the document has to establish full-time enrollment for the relevant term. Importantly, the platform does not try to count credit hours to decide this — "full-time" is defined differently in every country and institution, so a clear written enrollment statement is more reliable than a credit tally.

> **No one is ever auto-rejected**
>
> If the evidence doesn't yet prove full-time enrollment, the applicant is routed to the Missing Student Evidence follow-up queue so it can be resolved — never silently declined.

### AI Translation & Check

Those documents arrive from universities all over the world, in many languages and formats. Two separate Globus-controlled AI capabilities do the reading — one translates and reads, the other scores:

- Translation & extraction — detects the language, translates the document, and extracts the enrollment facts (institution, student, term and year, and any explicit full-time enrollment statement). It returns the translation and facts only — no score, no decision.
- Confidence scoring — takes that translated, extracted output and emits a calibrated confidence signal for how sure it is the document proves full-time enrollment, then flags the case for a reviewer when confidence falls below a configurable threshold.
The AI assists but never decides. The Rules Engine takes the AI's facts and confidence and makes the actual call:

| When the AI is… | What happens |
| --- | --- |
| Fully confident it proves full-time enrollment (selected type is transcript or enrollment letter) | The applicant passes and clears the Missing Student Evidence queue. |
| Not fully confident | The case goes to a Globus reviewer, and the applicant is asked to supply a letter (or other proof) that states full-time enrollment plainly. |
| Selected type is Other, or no type is confirmed | The case always goes to a Globus reviewer, regardless of AI confidence — never auto-passed. |
| Given nothing that proves enrollment | The applicant is added to the Missing Student Evidence queue — never auto-rejected. |

The confidence threshold that decides when the AI must hand off to a human is configurable, and both capabilities are owned and tuned by Globus in program configuration — the portal only uploads the file.

Staff routes: `GET /api/programs/:id/enrollment-proof-settings` (permission `dashboard.view`, program scope enforced) returns `programId`, `confidenceEscalationThreshold` and `isOverridden`; the threshold is 0.7 when the program has no override. `PUT` on the same path (permission `programs.manage`) sets `confidenceEscalationThreshold`, a number from 0 to 1, and is audited as `enrollment_proof_confidence_threshold_updated`. Both return 404 for an unknown program. `GET /api/applications/:applicationId/academic-verification-requests` (`applications.view`) lists the professor or university verification requests, and `POST` on the same path (`applications.manage`; body `contactName`, `contactEmail`, `contactRole`, optional `vacationVerificationId`) creates one and returns 201. `GET /api/applications/:applicationId/enrollment-proof-assessment` (`applications.view`) returns the assessment, or 404 when none exists; `POST` on `.../enrollment-proof-assessment/process` (`applications.manage`) runs the AI pipeline for an uploaded document and returns 200, or 422 when processing does not succeed.

### Verifying the Vacation Dates

Because vacation dates drive work-period eligibility, they can't simply be taken at face value — they have to be verified before the platform trusts them. The applicant enters their dates, and then:

- A verifier — the partner who recruited them, or Globus for direct-sales applicants — accepts or amends the dates. That confirmation becomes the authoritative record, with a full audit trail of who verified and when.
- If the verifier can't confirm them, they ask for proof. The applicant can supply a school calendar or a professor / university verification — both accepted equally.
The academic-calendar verification is satisfied by the same approval that verifies current-student status: once staff have approved the exact application's Proof of Student Status, no duplicate approval is needed. A dedicated academic-calendar review, when it has an explicit approved or rejected decision, still takes precedence (a rejection produces a failure even if the proof was approved). With neither an approved proof nor a decided review, the fact stays unresolved and the applicant is held for review.

The vacation dates are also checked against the programme window. The check passes when the official school vacation and the configured programme window overlap by at least one day; there is no minimum overlap length, and the vacation may start before or end after the programme window (only the shared period counts). Reversed dates, dates that do not overlap, or missing dates fail it (missing dates fail closed).

> **Professor / university verification**
>
> This works like an applicant reference: the applicant names a professor or university contact, that person receives a request (with reminders) and submits their verification, and a Globus reviewer reviews it. It is a new, dedicated flow — modeled on the reference process but kept separate from Reference Management. Only verified dates are passed on to the eligible-window calculation.

Two reason codes are seeded in the reason-code catalog for this flow. `SWT_NOT_CURRENTLY_A_STUDENT` (blocking) applies when the applicant declared on About Me that they are not currently studying (`education.currently_studying` is false: `no_completed`, `no_gap_year` or `no_no_plans`); it is a declaration gate that no document can satisfy, and the student status, academic calendar and vacation window evidence rules stand down so the applicant is not also asked for a Proof of Student Status. `ACADEMIC_VERIFICATION_OUTSTANDING` (review, never blocking) applies while a professor or university verification request is `PENDING` (verifier has not responded) or `SUBMITTED` (staff approve or reject still owed); it projects the applicant into the Academic Verification Required exception queue and clears when every request on the application is approved or rejected.

## The Eligible Window & the Two Checkpoints

Once the country's window and the verified vacation dates are both known, the eligible window is simply the overlap of the two — the only stretch of time the student is both permitted and free to work. The platform calculates it and shows it to the applicant; they never have to work it out themselves. It is then enforced in two places:

- A friendly preview, early on. On the Proof of Student Status step, the applicant sees their eligible window right away. If their dates don't overlap their country's window, they get a gentle warning — guidance, not a hard stop — so they can keep going and fix it. Two submit-time exceptions exist in the applicant portal: dates that run backwards are rejected (422), and so is a country with no State Department window on record for the season (422, "No Summer Work Travel window is on record for that country yet"), since no eligible window could ever be calculated for it. A failed window lookup (for example a temporary Globus error) does not block the applicant. The portal BFF backs this preview with three authenticated routes: `POST api/national-window/get` (one country window), `POST api/national-window/list` (every country that has a window for the applicant program and season, returned as `windows` keyed by country code with `startFormatted`, `endFormatted`, `countryName` and `display`, to populate the country dropdown) and `POST api/eligibility/calculate`. The calculation returns a `threeLineDisplay` of the country window, the declared vacation and an eligibility line whose wording depends on which side the State Department window clips: starts before the window, ends after it, both, or neither (a plain "You may travel between" range). Dates with no overlap return `NO_OVERLAP` with a warning message instead.
- A firm check, later. When the actual work dates are set at the Camp Contract step, the platform enforces the rule for real: the dates must sit inside the eligible window, and the work period must be four months or less. Anything outside that is blocked and routed for review. For Wild Packs SWT Camp, the Ready for SEVIS gate requires six SWT prerequisites: current student status, academic calendar, vacation/programme overlap, both Camp Contract eligible-window boundaries, and the four-calendar-month contract maximum. The four-month check is the rule `j1_summer_work_travel.work_period_within_four_months` (22 CFR 62.32, SWT Camp only; other resolved SWT applicants pass): a missing contract period, or one longer than four months, hard-blocks with reason code `WORK_PERIOD_EXCEEDS_FOUR_MONTHS`, routed to the `missing-compliance-documents` queue, and overriding it requires compliance dual approval. `POST /api/integrations/applicant-portal/swt/eligibility/evaluate` (`integrations.portal` API key) previews the same decision from candidate dates without persisting anything; its `reasons` array carries the code.
> **One simple rule, two inputs**
>
> Eligible window = the country's official DOS window intersected with the student's verified vacation dates. If those two never overlap, there is no eligible window — and the applicant is flagged so it can be resolved before any commitment is made.

Eligible-window reason codes in the catalog: `ELIGIBLE_WINDOW_OVERLAP_WARNING` (warning, non-blocking, never queued) is the early notice at eligibility-cleared when declared or verified dates do not overlap the country's window. `CONTRACT_BEFORE_ELIGIBLE_START` and `CONTRACT_AFTER_ELIGIBLE_END` (both blocking) are the directional hard stops at the post-contract document batch when the camp contract start is before the eligible window opens or its end is after it closes, or when no eligible window exists. They replace the deprecated combined `PROGRAM_OUTSIDE_ELIGIBLE_WINDOW`, which stays in the catalog so historical rule versions and audit records resolve. `WORK_PERIOD_EXCEEDS_FOUR_MONTHS` (blocking) covers the four-month maximum, and `PROGRAM_OUTSIDE_VACATION_WINDOW` (blocking) is the vacation-window verification failure on the eligibility-cleared phase gate.

## Behind the Scenes

A few design choices keep this trustworthy and consistent across the whole ecosystem:

- Globus does the deciding; the portal just shows the answer. Every decision — full-time enrollment, date verification, the eligible window — is made by the Globus Rules Engine , not by the applicant portal. The portal collects and reflects; it never invents its own version of the rules.
- AI assists, humans decide. One AI capability translates and extracts, another scores the confidence, but a person (via the Rules Engine's review routing) makes the final call whenever there's any doubt.
- The country windows come from one official source. The per-country months are loaded from the US Department of State's published SWT dates ( j1visa.state.gov/programs/summer-work-travel ) and kept in Globus only — held as date objects hung off the Program that the Rules Engine reads as the single source, while HubSpot just stops banned countries upstream. The owner edits the existing dates in place rather than reloading a fresh set, and because the windows change irregularly — sometimes only a country or two, sometimes nothing for years — currency is tracked with a non-blocking "reviewed / current" flag the owner marks off, not a hard deadline, so nothing downstream is ever blocked.
- Staff maintain the windows on the date windows admin page (`/swt/date-windows`, `programs.manage`). Each window is a `program_date_windows` row keyed by program, country (ISO2) and season label, with an open month and day, a close month and day, a year-boundary flag and an active flag. The page uses `GET` and `POST /api/swt/programs/:programId/date-windows` (list and upsert), `PATCH /api/swt/date-windows/:windowId/reviewed` (marking a window reviewed is one-way; no route clears it) and `DELETE /api/swt/date-windows/:windowId`, each audited. The same data is also served under program-scoped paths: `GET /api/programs/:programId/date-windows` (optional `seasonLabel` and `activeOnly=true`) and `GET /api/programs/:programId/date-windows/:countryIso2/:seasonLabel` need `programs.view` (404 when that window does not exist), while `PUT /api/programs/:programId/date-windows` upserts a window and `POST /api/programs/:programId/date-windows/:windowId/mark-reviewed` marks it reviewed by the caller; both need `programs.manage` and are audited as `program_date_window.upserted` and `program_date_window.reviewed`.
- The applicant portal reaches the same data through two integration routes on the Hub, authenticated with the shared integration key (`x-api-key` or Bearer), an applicant portal session Bearer, or an API key with the `integrations.portal` scope. `GET /api/integrations/applicant-portal/swt/programs/:programId/seasons/:seasonId/date-window/:countryIso2` returns `found: false` when the season has no season key or no active window exists for that country, otherwise `found: true` and the window (open and close month and day, year-boundary flag, `seasonYear`). `POST /api/integrations/applicant-portal/swt/eligibility/evaluate` (body `programId`, `seasonId`, `countryIso2` of the university, `vacationStartDate`, `vacationEndDate`, `contractStartDate`, `contractEndDate` as YYYY-MM-DD) is a non-persisted preview: it derives the eligible window (DOS window intersected with the vacation dates) and runs the published contract-start, contract-end and four-month gates over a synthetic facts snapshot. It returns `decision` (`allow` or `block`), `eligibleWindow`, `eligibleWindowStatus` (`derived`, `empty_intersection` or `unavailable`), `seasonYear`, every failing `reasons` entry (code, applicant message, queue, rule key, severity) and the per-rule `rules` outcomes. Impossible dates, a start after its end, an unknown program or an unknown season for the program are 400 validation errors.
- One step, both portals. The Proof of Student Status step and its rules run identically in the applicant portal and the partner portal — nothing partner-specific is built.
- The DOS country windows are scoped to SWT_WP (Wild Packs Summer Work & Travel - Camp) only. A migration backfilled the full DOS chart for every open or active SWT_WP season, preserving any operator-edited row already present (`ON CONFLICT DO NOTHING`), and deactivated the provisional windows for seven other program codes (CAC, CAMP_WP, SWT, SWT1, SWT2, SWT_GEO, SWT_HOSP). Those rows are kept inactive as staff-visible history, not deleted.
- Verification records live in three tables. `vacation_date_verifications` holds the submitted and verified vacation dates per application with `verification_state` (`UNVERIFIED`, `VERIFIED` or `PROOF_REQUESTED`), verifier and time, `proof_type` (`SCHOOL_CALENDAR` or `PROFESSOR_VERIFICATION`), `school_calendar_file_id` and `notes`. `academic_verification_requests` holds each professor or university request: contact name, email and role, `status` (`PENDING`, `SUBMITTED`, `APPROVED` or `REJECTED`), a unique `submission_token` with expiry, the confirmed enrollment term and vacation dates, the free-form response and its translation, reviewer, time and notes, and `reminder_count` with `last_reminder_sent_at`. `enrollment_proof_assessments` holds the AI output per application and document: `document_type` (`TRANSCRIPT`, `ENROLLMENT_LETTER` or `OTHER`), detected language, translated and OCR text, extracted institution, student name, term and enrollment statement, `confidence_score` (0 to 1), `escalate_flag`, `processing_status` (`PENDING`, `PROCESSING`, `COMPLETED` or `FAILED`), `rule_decision` (`PASS`, `REVIEW_REQUIRED` or `MISSING`), `rule_reason_codes`, and the staff decision (`APPROVED` or `REJECTED`) with notes.
## How This Is Being Built

The runtime for all of this lives in the Globus core and applicant-portal repos, tracked by the following Asana tickets. (This documentation site only describes the architecture.)

| Area | Ticket | What it owns | Board | Link |
| --- | --- | --- | --- | --- |
| Engine rule | SWT eligibility rule — national-window ∩ vacation eligible-window derivation + four-month work-period gate | The eligible-window predicate, decision classes, and the hard Camp Contract gate | P3: Rules Engine & Eligibility | [Open](https://app.asana.com/1/817430812898727/project/1213692100361485/task/1216024273302734) |
| Engine rule | Full-time enrollment proof rule — transcript-or-letter equivalence with AI-confidence escalation and Missing Student Evidence routing | The pass / review / follow-up decision on enrollment proof | P3: Rules Engine & Eligibility | [Open](https://app.asana.com/1/817430812898727/project/1213692100361485/task/1216033663942819) |
| Engine rule | Vacation-date verification rule — verifier attestation as the authoritative record with ask-for-proof escalation | Date verification as the authoritative record, shared across both portals | P3: Rules Engine & Eligibility | [Open](https://app.asana.com/1/817430812898727/project/1213692100361485/task/1216033683983994) |
| Form fields | SWT Proof of Student Status fields — university country, vacation dates, enrollment evidence (collection only) | Collecting the three inputs; never computes eligibility | AP-6: Application Forms & Field Library | [Open](https://app.asana.com/1/817430812898727/project/1216785079269821/task/1217186757080252) |
| Portal step | Proof of Student Status step — eligibility inputs, enrollment-proof upload, and vacation-date verification states | The collect-and-reflect step UI, identical in both portals | AP-6: Application Forms & Field Library | [Open](https://app.asana.com/1/817430812898727/project/1212278731177206/task/1216024188440694) |
| Reference data | SWT country date-windows as Globus-only date objects hung off Program (single source, edited in place, non-blocking reviewed flag) | The DOS per-country windows the engine reads | P11.4: Program Configuration (Camp) | [Open](https://app.asana.com/1/817430812898727/project/1215728878667241/task/1216024273729588) |
| AI capability | Globus-controlled AI translation and extraction for enrollment-proof documents | Language detection, translation, structured fact extraction (no score, no decision) | P11.4: Program Configuration (Camp) | [Open](https://app.asana.com/1/817430812898727/project/1215728878667241/task/1216033663967458) |
| AI capability | Globus-controlled AI confidence scoring for enrollment-proof documents | Calibrated full-time-enrollment confidence with configurable reviewer-escalation threshold | P11.4: Program Configuration (Camp) | [Open](https://app.asana.com/1/817430812898727/project/1215728878667241/task/1216057552293296) |
| Verification flow | Professor and university verification mechanism — referee-style request, reminders, submission, and review | The new dedicated flow modeled on (but separate from) Reference Management | P11.4: Program Configuration (Camp) | [Open](https://app.asana.com/1/817430812898727/project/1215728878667241/task/1216033770026123) |
| Matching | Eligible-Window Overlap soft-scoring dimension (SWT-Camp) | Using the eligible window as a soft-scoring signal in matching | P7: Matching Engine & Skill Intelligence | [Open](https://app.asana.com/1/817430812898727/project/1213692100437234/task/1217036700195562) |

> **Retired ticket**
>
> The original "annual refresh of the DOS SWT country date-window dataset" ticket on P11.4 was retired (Won't Do) when the model moved to irregular edit-in-place maintenance with a non-blocking reviewed flag — its scope was folded into the date-windows ticket above.

> **Related pages**
>
> See the Applicant Portal — Eligibility Surface for how the portal renders these decisions, the Rules Engine for the decision pipeline and reason codes, and Pre-Qualification Eligibility for the earlier screening step.