--- title: "Intern/Trainee Scope" slug: intern-trainee-scope section: Program Configuration status: draft description: "The sponsor-grade scope for bringing the J-1 Intern and Trainee programs onto Globus." last-updated: 2026-10-07 --- # Intern/Trainee Scope The sponsor-grade scope for bringing the J-1 Intern and Trainee programs onto Globus. It explains, in plain English, what Globus must know, what staff must decide, what the applicant must provide, and how the system preserves evidence and approvals over time. The scope is written against the platform as it actually exists: where it needs machinery the platform already has (a rules engine, versioned rulesets, conditional evidence collection), it reuses it; where Globus genuinely lacks a capability, the gap analysis below says so. This page is the official first draft and the source of truth for the Intern/Trainee scope. > **Status: approved as architectural baseline — decomposition pending.** Architecture review (July 2026) approved this scope as the baseline for Intern/Trainee. A scoping ticket covering final sign-off and Phase 1 ticket decomposition is filed on the P11.5 board; no implementation tickets have been filed yet. The Open Decisions below are formal architecture gates — dependent workstreams must not begin until the gate they rely on is resolved. The Rules Engine spec's Normative Contracts section remains the source of truth wherever this page and it intersect. ## Executive Summary This scope introduces the regulated assessment layer required to support the J-1 Intern and Trainee programs within Globus. The key architectural principles: - **Applicants never choose Intern or Trainee.** Both routes are evaluated after evidence collection; the system determines what the person is eligible for. - **Workflow Studio collects evidence.** Step trees and conditional evidence collection are configuration, not code. - **The Rules Engine evaluates verified facts.** All eligibility logic lives there as versioned rules; nothing is re-implemented. - **Sponsor staff approve regulatory decisions.** The engine calculates; a named, authorized human adjudicates. The two records never blur. - **Eligibility is a living assessment.** Evidence changes, facts change, rules rerun, and the workflow reacts — eligibility is never a one-time checkbox. - **Matching consumes the current Eligibility Projection.** Operations reads a fast current-status view, never the audit trail. - **Every regulatory decision is fully auditable.** Immutable records, supersession chains, and engine evaluation references make every decision explainable years later. The scope reuses existing platform capabilities wherever possible and introduces only the sponsor-specific entities that are genuinely missing. ## Not in Scope This document deliberately does not cover: - SEVIS implementation details (the gate is specified; the SEVIS integration itself is not) - Electronic signature provider selection for the DS-7002 (an Open Decision) - DS-2019 generation mechanics - Applicant Portal visual design - Reporting and analytics - API contracts and database schema — those belong to the decomposition tickets, not this scope ## Overview & Positioning Intern and Trainee are two distinct J-1 participant types under 22 CFR 62.22 that share one operational pipeline. In the platform they live under **one combined regulatory category (`intern_trainee`) with two eligibility routes** — and this is not net-new onboarding: **five Intern/Trainee programs are already live** across multiple brands ("Intern and Trainee" ×2 including the GEO brand, "Self-arranged Intern and Trainee" ×2, and "Teach Intern and Trainee" under Teacher Lounge). Every rollout decision in this scope has that installed base to consider. - A single intake flow collects evidence once; both routes are evaluated independently from the same facts. - The applicant is never asked to pick Intern vs Trainee at registration — the choice is a legal classification made after evidence is in, and the sponsor (not the applicant or partner) owns the final call. - Route eligibility is date-relative: the Intern 12-month graduation window is measured against the *proposed program start date*, so eligibility is an assessment at a point in time, never a static applicant attribute. > **Design principle: the Living Eligibility Model.** Eligibility is not a permanent status. It is always calculated from the latest verified evidence and the latest proposed placement details — references arrive over time, employers confirm or dispute employment, start dates move, and each material change produces a new immutable Eligibility Assessment while historical assessments stay on file. Operations, Matching, and the Applicant Portal always work from the current Eligibility Projection, never from a remembered decision. Everything on this page — the assessment records, the supersession machinery, the operational scenarios — follows from this one principle. > **Why eligibility changes.** Unlike Camp Counselor or SWT, an Intern/Trainee applicant may wait months between applying and a suitable placement being found. During that window, the facts underneath eligibility keep moving: employers respond to reference requests, alternative evidence is accepted, work history is corrected, the occupational classification shifts with the proposed placement, and placement dates change. The sponsor must therefore continually reassess eligibility against the latest verified evidence and the latest proposed placement — which is why Globus models eligibility as a living assessment rather than a permanent applicant attribute. The regulatory ground rules the system must enforce: | Area | Requirement | | --- | --- | | Intern eligibility | Currently enrolled in a qualifying foreign post-secondary institution, **or** graduated no more than 12 months before the program start date. | | Trainee eligibility | Foreign degree / professional certificate **plus** at least 12 months of related experience outside the U.S.; **or** five years of related experience without the degree route. | | Occupational scope | Training must be in an authorized occupational category and related field. | | Duration | Intern: max 12 months. Trainee: normally 18 months; Hospitality/Tourism and Agriculture limited to 12. Sponsor authorization may be stricter. | | Training quality | Structured and guided, not ordinary employment; must not merely duplicate prior experience. | | DS-7002 | Complete, signed, approved training plan before DS-2019 issuance. | | Prohibited placements | Controls for unskilled/casual labor, childcare/elder care, patient contact, excessive clerical work. | | Sponsor authority | An authorized sponsor user approves the Regulatory Decision. | ## The Core Problem in One Example An applicant is created with Brand: Teacher Lounge, Program: Teach Intern and Trainee, Cycle: 2027 Rolling. They then submit a current university enrollment record, a degree history, three jobs, and two employer references. Globus must be able to answer: 1. Is this person eligible as an **Intern**? 2. Is this person eligible as a **Trainee**? 3. In which **occupational category and field** are they eligible? 4. Which **job orders** are compatible? 5. Has the **sponsor approved** the final route? 6. Is the **DS-7002** complete and consistent with that route? Today the registration screen works fine — the missing capability is the regulated assessment layer between application evidence and final placement. That layer is what this scope adds. ## Scope Decisions | Decision | In scope | Rationale | | --- | --- | --- | | New Program Family hierarchy level | **No** | Existing Brand → Visa Type → Regulatory Category → Program → Operational Cycle carries it. | | Occupational Category as a first-class entity | **Yes** | Classification follows the training activities (DS-7002), not the host's industry. | | Intern/Trainee selection at registration | **No** | Both routes evaluated after evidence collection; seven-state operational projection. | | Parallel eligibility engine | **No** | The Eligibility Assessment is a *consumer* of the Rules Engine — it references engine evaluations, it does not re-implement or copy them. | | Partner-proposed route | **Yes** | Partner or job order may propose; only an authorized Globus user approves. | | Placement Assessment per match | **Yes** | Applicant eligibility and placement suitability are separate questions with separate records. | | DS-7002 as a first-class versioned record | **Yes** | Gates DS-2019 / SEVIS issuance. | | Participant dates on Operational Cycle | **No** | Dates live on placement / DS-7002 / DS-2019; the cycle manages intake only. | | Record-level remediation UI | **Deferred to platform** | Re-collecting a single failed evidence item is platform-wide work-item mechanics; this scope is its first consumer. | ## Program Hierarchy Placement Intern and Trainee slot into the existing hierarchy without structural change: ``` Brand └── Teacher Lounge (and other brands operating Intern/Trainee programs) Visa Type └── J-1 Regulatory Program Category ├── Teacher └── Intern / Trainee (one combined category, code intern_trainee) Program ├── Teach USA ├── Teach Intern and Trainee (Teacher Lounge) ├── Intern and Trainee / Self-arranged Intern and Trainee (other brands) └── ... future I/T programs (Hospitality, Business, Marketing, ...) Operational Cycle └── 2027 Rolling ``` The live platform has **one combined `intern_trainee` regulatory category**, not two sibling categories — Intern vs Trainee is a *participant type decided per applicant*, not a category split. Whether the category should ever be split into two is an Open Decision (below); this scope does not pre-decide it, and a split would move the category-scoped bundle attachment, the five live programs' category assignments, and the auto-attach predicates. > **Program is doing two jobs — acknowledged, not restructured here.** Today the Program entity carries both a **commercial role** (the product a brand sells: name, pricing, partner contracts, reporting) and a **regulatory role** (which BridgeUSA category and rules apply). "Teach Intern and Trainee" is a commercial product; *Intern/Trainee* is a regulatory category — different things sharing one entity. Intern/Trainee is the scope that exposed this. Nothing needs to change today: the program already carries a single category_id for its regulatory category, and the configuration fields below (*regulatory_category_scope*, ruleset and policy versions) are proposed additions on the regulatory side, while name, brand, and cycle stay commercial. But every future reader should interpret Program with that split in mind, and a formal Commercial Program vs Regulatory Program separation is recorded as an Open Decision below. Below program configuration sits the authority scoping chain — each program may only offer what the legal sponsor is authorized to operate. This chain is the Sponsor Authority model (detailed below): designation governs far more than occupational categories, so the chain runs from the legal entity down through program, occupational, and country authorities to versioned policies: ``` Legal Sponsor └── Designation (DS-2019 authority, effective/expiry) └── Program Authorities (which J-1 categories, e.g. Intern / Trainee) └── Occupational Authorities (authorized occupational categories → program-enabled subset → fields) └── Country Authorities (countries the sponsor may serve) └── Policy Versions (duration caps, site-visit policy, monitoring obligations) ``` - Intern/Trainee Operational Cycles are rolling administrative groupings; **no participant dates derive from the cycle**. - An optional Program Group for cross-category reporting may come later; it must never define an applicant's legal status. ## Data Model Additions The full sponsor-grade data model — every entity in the regulated chain from application evidence to SEVIS, with what each one carries. Each entity is marked **EXISTS** (already in Globus — gains Intern/Trainee fields) or **NEW** (must be built for this scope): | Entity | Status | What it carries | | --- | --- | --- | | **Application** | **EXISTS** | Declared education *(new field)*, declared work history *(new field)*, submitted evidence *(exists — document/evidence pipeline)*, intended occupational interests *(new field)* | | **Eligibility Assessment** | **NEW** | Intern result, Trainee result, occupational-category results, engine evaluation references (the live `eligibility_assessments` row holds the current result with `ruleset_key` and `ruleset_version`; each sponsor approval is an immutable `eligibility_approvals` row that stores `facts_snapshot` and `evidence_snapshot` copies), provisional / approved status, sponsor approval | | **Eligibility Projection** | **NEW** | The current-status view; in the shipped Phase 1 schema this is the live `eligibility_assessments` row itself (one per application and assessment type, ADR 0003 section 3.1) rather than a separate derived view, and it is what Operations and Matching read; never an audit source | | **Host Organization** | **EXISTS** | Verification *(exists — host vetting)*, site-visit status *(exists)*, workers'-comp insurance *(exists)*, eligibility status per occupational category *(new field)* | | **Job Order** | **EXISTS** | Occupational category *(new)*, occupational field *(new)*, proposed participant type *(new)*, duties / duration / hours *(exist)*, prohibited-activity checks *(new)* | | **Placement Assessment** | **NEW** | Applicant alignment, non-duplication review, category compatibility, duration validation, sponsor approval | | **DS-7002** | **NEW** | Versioned training plan, signatures, approval — a first-class record | | **Regulatory Decision** | **NEW** | The generic locked decision record (for Intern/Trainee it resolves to Intern or Trainee), program dates, approved evidence basis, authorized sponsor decision, compliance opinion | In short: the four entities Globus already has (Application, Host Organization, Job Order, plus Program configuration below) are extended, not rebuilt. The four regulated decision records (Eligibility Assessment, Placement Assessment, DS-7002, Regulatory Decision) are new — they are exactly the assessment layer the platform is missing today, and the gap analysis at the top of this page says the same thing entity by entity. The Eligibility Projection is not a decision record: it is the derived "where does this applicant stand right now" view over the decision records, following the same pattern as Rules → Effective Rules. A deliberate design principle runs through this list: **the reusable entities are platform concepts, not Intern/Trainee concepts.** Sponsor Authority, the Occupational Category taxonomy, the evidence-verification pipeline, the Eligibility Projection pattern, and the Regulatory Decision record are all written so Teach USA, Camp, SWT, and future regulated programs (H-2B, Australia, Canada) consume the same machinery instead of growing program-specific clones. Only the rule content — the 22 CFR 62.22 specifics — is Intern/Trainee-shaped. Why this shape: it keeps the current applicant-creation experience (no early legal classification), separates what the applicant *declares* from what the sponsor *assesses*, evaluates Intern and Trainee independently, separates applicant eligibility from host and job-order suitability, and gives a clean audit bridge from evidence to DS-7002, DS-2019 and SEVIS — with re-evaluation that never deletes or rewrites a prior sponsor decision. > **Plain-language terms used on this page.** **Snapshot** — a frozen copy of the exact evidence and rule versions behind a decision, kept so the decision can always be explained later. **Supersession** — replacing an approved decision with a new one while keeping the old one on file, instead of editing it. **Canonical fact** — a single agreed-upon data point (like "verified months of experience") that every rule reads from the same place. **Lock-required rule** — a compliance rule that must pass before the system allows the next regulated step. **Projection** — a derived "current status" view computed from immutable records, safe to read for operations but never the audit source. Two existing entities also gain Intern/Trainee-specific fields (no rebuild — additions only): **Program** **EXISTS** — gains configuration fields (proposed: apart from `Active / archived status`, none of the rows below exist in code today) | Field | Purpose | | --- | --- | | `regulatory_category_scope` | Which regulatory categories the program operates (proposed; today a program has a single `category_id`) | | `allowed_occupational_categories` | The subset of sponsor-authority scope this program offers | | `default_workflow_version` | The Workflow Studio tree new applications start on | | `eligibility_ruleset_version` | The pinned rule versions in-flight applications stay on | | `evidence_policy_version` | Versioned evidence policy (e.g. which documents verify employment) | | `host_policy_version` | Versioned host vetting policy | | Active / archived status | Lifecycle of the program offering itself | **Application** **EXISTS** — gains Intern/Trainee fields | Field | Purpose | | --- | --- | | Declared education records | What the applicant says about their studies (before verification) | | Declared work-history records | What the applicant says about their jobs (before verification) | | Submitted artifacts | The actual uploaded evidence documents | | Intended occupational interests | Which categories/fields the applicant wants to train in | | Current applicant-action state | Whether the applicant owes the system anything right now | ### Occupational Category & Field Taxonomy **NEW** A regulated configuration entity, owned at the platform level (not per-program). Categories match the DS-7002 category list; fields are a configurable child taxonomy: | Occupational category | Example fields | | --- | --- | | Hospitality and Tourism | Front Office, Food & Beverage, Rooms Division, Culinary Operations, Revenue Management | | Management, Business, Commerce and Finance | Marketing, Finance, Human Resources, Sales, Operations | | Education, Social Sciences, Library Science, Counseling and Social Services | Early Childhood Education, Curriculum Development, Educational Administration | | Information Media and Communications | Media Production, Communications, Digital Content | | Sciences, Engineering, Architecture, Mathematics and Industrial Occupations | Mechanical Engineering, Data / Analytics, Architecture | Scoping chain: sponsor authority constrains which categories the sponsor may operate → program configuration constrains which the program offers → the job order picks one from the allowed intersection. The host's industry is **descriptive metadata only** — validation always runs against the placement's occupational category (see Worked Example C). This is deliberately **platform master data, not an Intern/Trainee entity**. Intern/Trainee is simply its first full consumer: Teacher programs can classify placements against it, professional-visa programs can reuse it, and non-US expansions (Australia, Canada) can carry their own category sets in the same structure. Nothing in the taxonomy schema references Intern/Trainee. ### Sponsor Authority **NEW** Designation governs far more than occupational categories, so this is a platform-wide entity (SWT and Camp will consume it too) modeling everything the Department of State has authorized the legal sponsor to do. Conceptually it is the hierarchy shown in the Program Hierarchy section — Legal Sponsor → Designation → Program / Occupational / Country Authorities → Policy Versions — though whether each level becomes its own table is an implementation call, not a commitment made here: | Field | Purpose | | --- | --- | | `sponsor_number`, designation effective / expiry dates | Identity and validity of the designation itself — the sponsor's authority to issue DS-2019s at all | | `authorized_regulatory_categories` | Which J-1 categories the sponsor may operate (program authority) | | `authorized_occupational_categories` | Which I/T occupational categories are in scope (occupational authority) | | `authorized_countries` | Which countries the sponsor may serve (country authority) | | `category_duration_limits` | Where DOS authorization is stricter than the regulation | | Site-visit and monitoring policy versions | Sponsor-policy obligations that vary by designation, versioned like evidence policy | | Designation artifacts + version/approval history | Source-of-truth documents, immutable versions | Rules reference sponsor authority as facts, so an out-of-scope placement — wrong category, wrong country, over the duration cap, or a lapsed designation — fails with an explicit reason code instead of being silently accepted. ### Eligibility Assessment Record **NEW** The assessment record is new; the rule evaluation it consumes runs on the existing Rules Engine. The per-applicant assessment is a **sponsor adjudication record** — the sponsor's acceptance or rejection of what the engine concluded — not another evaluation record and not an engine: > **Is this the Rules Engine? No — and the boundary is normative.** The Rules Engine already exists: it is the platform machinery that evaluates rules against facts and returns pass/fail results with reason codes. Nothing about it is rebuilt for Intern/Trainee — this scope only adds new **rules** and **facts** for it to run. The engine also already keeps its own **immutable evaluation records**: persisted fact snapshots, per-rule results, exact rule and bundle versions, reason codes, and deterministic replay. The Eligibility Assessment must not duplicate any of that — two competing records of what the engine concluded would be worse than none. The boundary, stated normatively: **the Rules Engine is authoritative for the calculated result and its facts snapshot; the assessment is authoritative for the sponsor's acceptance or rejection of that calculated result.** The assessment *references* engine evaluation IDs and adds only what the engine cannot know: the sponsor-reviewed route and occupational outcomes, the approver and their approval authority, the Compliance Opinion, timestamps, supersession, and any human findings not expressible as rules. It must be new because today there is no durable "here is the decision the sponsor made, and on what basis" artifact attached to the applicant — and regulations require a sponsor to explain a decision years later exactly as it was made. The Placement Assessment below follows the same pattern: engine = exists (reused), adjudication record = new (built). | Field | Purpose | | --- | --- | | `intern_result`, `trainee_result` | Sponsor-reviewed per-route outcomes with reason codes | | Results by occupational category / field | An applicant can qualify in Education but not Hospitality | | `verified_experience_months` (by category/field) | The computed Trainee-route input (see Open Decisions) | | `proposed_start_date_used` | The date the Intern graduation window was measured against (see the pre-placement date model below) | | Engine evaluation references | References to the evaluation records (`eligibility_path_evaluations`, `eligibility_evidence_references`); the assessment row carries `ruleset_key` / `ruleset_version`, and each immutable approval in `eligibility_approvals` stores its own `facts_snapshot` and `evidence_snapshot` copies | | Approver, approval authority, timestamps | Provisional calculations are automatic; approval is human, by a named authority | | Compliance Opinion + human findings | Sponsor judgment not expressible as rules (see Compliance Opinion below) | | `provisional` / `approved` status | Provisional results never gate anything downstream | | `supersedes_assessment_id` | New facts create a new assessment; nothing is rewritten | **Pre-placement date model.** Intern eligibility is measured against a start date — but early in an application no placement exists, so no defensible start date exists either. The assessment therefore operates at two levels. A **pre-placement route indication** uses a clearly identified planning date or date range (the applicant's stated intended start, or the earliest/latest realistic window) and is always labeled **provisional** — it steers evidence collection and pool placement, nothing more. **Placement-context eligibility** is re-evaluated against the actual proposed placement start date and is required before any placement approval. Participant dates never derive from the Operational Cycle (per Scope Decisions), so no cycle-derived date is ever used as the measurement basis. ### Eligibility Projection **NEW** Assessments are immutable, so over an applicant's life a chain of them accumulates — and "which one is current?" should never be a query every consumer answers for itself. The Eligibility Projection is the single derived **current view** per applicant: the latest approved assessment's outcome per route and category, plus any pending provisional result and open material-change review. It mirrors the platform's existing Rules → Effective Rules pattern: immutable versions underneath, one computed "what applies right now" view on top. | Consumer | Reads | | --- | --- | | Operations staff | The projection — current pools, pending reviews, what needs action | | Matching | The projection — only current, approved eligibility gates proposals (see Matching below) | | Applicant portal | The projection, translated to plain language | | Audit / compliance review | The **assessments**, never the projection — the projection carries no evidence snapshot and is not a decision record | The projection is recomputed whenever an assessment is approved or superseded or a provisional result lands; it stores nothing that cannot be rebuilt from the assessment chain. **The projection is not a readiness flag.** Four neighboring platform concepts answer four different questions, and they must never become interchangeable: | Concept | The one question it answers | | --- | --- | | Rules resolution snapshot (engine) | Which rules and parameters applied to this evaluation? | | Eligibility Projection (this record) | What is the applicant's current approved regulatory route / category eligibility? | | Lifecycle Readiness | Can this application take its next operational step, considering all gates? | | Matching suitability | Is this specific applicant / job-order pair compatible? | The Eligibility Projection never becomes a generic "ready / not ready" field — readiness is Lifecycle Readiness's job, and it consumes the projection as one input among many. ### Placement Assessment Record **NEW** Applicant eligibility says "who can this person be"; the Placement Assessment says "is *this* match lawful". Like the Eligibility Assessment, it is not an engine and follows the same adjudication boundary: the checks below run as rules on the existing Rules Engine, and this record preserves the sponsor's approval of *that specific match*, referencing the engine's evaluation records (which own the evidence snapshot and rule versions) rather than copying them. One per proposed applicant / job-order pair: | Check | Question | | --- | --- | | Route compatibility | Does the proposed participant type match an approved eligibility route? | | Category / field alignment | Does the applicant's eligible category match the order's category? | | Non-duplication | Is the training structured and guided, not a repeat of prior experience or ordinary employment? | | Duration validation | Within the route cap, the category cap, and any stricter sponsor limit? | | Hours | Full-time requirement for Trainee placements | | Prohibited activity | Unskilled/casual labor, childcare/elder care, patient contact, clerical percentage | | Host eligibility | Host Compliance Assessment passed (below) | | Sponsor decision | Approver, timestamp, engine evaluation references | ### DS-7002 Training Plan Record **NEW** Today the DS-7002 lives outside the system of record; this makes it a first-class versioned record attached to the placement: - Participant, host, site, and supervisor binding; approved participant type and occupational category (must match the Placement Assessment). - Phase structure — site, supervisor, duration, objectives, activities, supervision and evaluation methods per phase. - Signature state per required signatory (applicant, host supervisor, sponsor officer), with method and timestamp per signature. - Versioned: material changes after any signature create a new version requiring re-signature; prior versions retained with amendment history. ### Regulatory Decision **NEW** A platform concept: any regulated program ends in a locked sponsor decision. For Intern/Trainee the decision resolves to Intern or Trainee; for Teacher it would resolve to Teacher; future categories bring their own outcomes. It is the legal sponsor decision — the single authoritative, locked answer for this participant, and the basis every downstream regulated action (DS-2019 issuance, SEVIS registration, program reporting) works from: - Set only by a user holding `compliance.regulatory_decisions.set` (see RBAC below), only when the approved Eligibility Assessment permits that route and the Placement Assessment is approved. - Partner / job-order preference is stored separately as `proposed_route` and never auto-promotes. - Records the locked regulatory basis — assessment references, approved DS-7002 version, program dates — used for DS-2019 / SEVIS. - Carries the sponsor's Compliance Opinion (below) as its human judgment layer. **The decision has a lifecycle — it cannot be born final.** A final decision records the approved DS-7002 version, but the DS-7002 is drafted *against* an approved route — so a single-state decision would have to reference a document that did not yet exist when the decision was made. The lifecycle resolves this: | State | Meaning | | --- | --- | | `draft` | A route is proposed; nothing downstream may rely on it. | | `provisionally_approved` | The sponsor has approved the route sufficiently to draft the DS-7002 against it. This is the state the operating flow's "set the Regulatory Decision" step produces. | | `final` | Set only after the approved DS-7002 version exists with all required signatures. This — and only this — is the locked basis for DS-2019 / SEVIS issuance. | | `corrected` | Post-issuance changes create a corrected decision through the formal correction / amendment flow, never an edit; the prior state is retained. | ### Compliance Opinion **NEW** Rules produce pass / fail with reason codes — but a sponsor's judgment is richer than a boolean, and regulators expect to see the judgment, not just the rule output. The Compliance Opinion is the explicit recorded opinion attached to an approved assessment or Regulatory Decision: | Opinion | Meaning | | --- | --- | | **Approved** | The sponsor is satisfied; proceed. | | **Approved with Conditions** | Proceed, but named conditions must be met or monitored (e.g. a follow-up site visit, an evidence refresh by a date). | | **Rejected** | The sponsor declines, with recorded reasons — even if some rules technically pass. | | **Requires Further Evidence** | No opinion yet; specific evidence is named and requested. | The opinion never overrides a fail-closed rule (a sponsor cannot "approve past" a hard gate); it adds the human layer on top. **Conditions are structured obligations, not notes.** "Approved with Conditions" only works if each condition is machine-trackable. Every condition carries: a **type**, an **owner**, a **due date**, an **evidence requirement** (what proves it was met), a **`blocks_ds2019` flag** — the split between conditions that gate issuance and post-issuance monitoring obligations is explicit per condition, never implied — a **status**, the **resolution actor and timestamp**, and a defined **breach behavior** (what happens if the due date passes unmet). Conditions are tracked as work items so "with Conditions" cannot silently decay into plain approval, and the DS-2019 gate checks only the conditions flagged as blocking. The Compliance Opinion is strictly distinct from the platform's existing rule-override / waiver machinery, and the two do not substitute for each other. An override changes what the engine concludes — it acts on the input side, adjusting a specific rule's evaluation with its own recorded justification, and the engine's outcome then reflects it. A Compliance Opinion acts on the output side: it is sponsor judgment layered on top of whatever the engine concluded, overrides included. A sponsor who is uncomfortable with a technically-passing case records a Rejected opinion; a sponsor who believes a rule fired wrongly pursues an override through the engine's own channel — never by "approving past" it with an opinion. ## End-to-End Operating Flow The whole journey in plain English, start to finish: 1. Staff create the application by selecting Program and Operational Cycle. Nobody selects Intern or Trainee — that decision comes later. 2. Workflow Studio publishes the evidence-collection workflow for the selected program. 3. The applicant declares their education, work history, and occupational interests, and uploads the required evidence. 4. Globus automatically recalculates provisional eligibility whenever material evidence changes. 5. Operations and Compliance review the evidence and approve an Eligibility Assessment. 6. The applicant lands in the Intern pool, the Trainee pool, both, or neither — within one or more occupational fields. 7. A partner or staff member proposes a compatible job order (which may carry a preferred route). 8. Globus runs a Placement Assessment against the order's actual dates, category, field, duties, hours, and host status. 9. An authorized sponsor user approves the placement, records a Compliance Opinion, and sets the Regulatory Decision to `provisionally_approved` — Intern or Trainee. 10. The DS-7002 training plan is drafted against the provisionally approved route, completed, signed by all parties, and approved. 11. The Regulatory Decision moves to `final`, referencing the signed DS-7002 version — and only then does DS-2019 / SEVIS issuance proceed, on the locked regulatory basis. 12. Any later material change (dates, host, evidence) triggers a review — never a silent rewrite of the approved decision. The same flow as a diagram — who acts at each stage, and where the hard gates sit: ``` APPLICANT GLOBUS (automatic) SPONSOR STAFF ───────── ────────────────── ───────────── Application created ───────► evidence-collection (Program + Cycle only; workflow published no route choice) │ │ │ declares education, │ work history, interests; │ uploads evidence ──────────► provisional eligibility ▲ recalculated on every │ material evidence change │ │ targeted evidence ▼ request (only the ◄── evidence gap found Operations + Compliance affected record review and APPROVE the reopens) Eligibility Assessment │ ▼ applicant lands in a pool: Intern / Trainee / both / neither │ partner or staff proposes a compatible job order (may carry a preferred route — never decides it) │ ▼ Placement Assessment runs: dates, category, field, duties, hours, host status │ ▼ authorized sponsor user APPROVES placement, records the opinion, and sets the Regulatory Decision │ ▼ DS-7002 completed, signed by all parties, approved │ ══════════▼══════════ HARD GATE: all five conditions must pass ═════════════════════ │ ▼ DS-2019 / SEVIS issuance on the locked basis │ ▼ any later material change → review work item, never a silent rewrite ``` The same platform seen as an architecture rather than a journey. This is deliberately not a straight line: the Rules Engine feeds both the immutable assessment history and the live operational gates, and everything downstream reads the current projection — which is why evidence changes propagate everywhere without anyone reopening a workflow: ``` ┌─────────────────────────┐ │ Workflow Studio │ │ Evidence Collection │ └────────────┬────────────┘ │ ▼ ┌─────────────────────────┐ │ Evidence Verification │ └────────────┬────────────┘ │ ▼ ┌─────────────────────────┐ │ Canonical Facts │ └────────────┬────────────┘ │ ▼ ┌─────────────────────────┐ │ Rules Engine │ └────────────┬────────────┘ │ ┌───────────────┴───────────────┐ ▼ ▼ Eligibility Assessment Operational Gates (immutable history) (readiness / queues) │ ▼ Eligibility Projection (current operational view) │ ┌────────┴────────┐ ▼ ▼ Matching Applicant Portal │ │ ▼ ▼ Placement Proposal Targeted Remediation │ │ │ (new placement facts feed back into │ Canonical Facts → Rules Engine) ▼ Placement Assessment │ ▼ DS-7002 │ ▼ Regulatory Decision │ ▼ DS-2019 / SEVIS ``` Note the feedback loop: a placement proposal is not the end of eligibility — it *supplies new regulatory facts* (start and end dates, occupational category, hours per week, host status) that flow back into the same fact-and-rules machinery. Matching therefore both consumes eligibility and changes it. ## Operational Scenarios The operating flow above reads as a straight line, but Operations does not live in a straight line. Eligibility is constantly moving — not because regulations change, but because **evidence changes**: an employer refuses a reference, an applicant uploads an alternative document, a host moves an arrival date. The five scenarios below show what the re-evaluation machinery looks like as a normal working day. Each one is routine, not an edge case, and each card reads the same way: where the applicant stands before, what changes, and where they land after. The scenarios are illustrative — the authoritative rule logic lives in the Rules Engine sections that follow. > **Evidence-driven, not workflow-driven.** Most systems in this space are workflow-driven: complete a step, move forward, and going back means reopening everything. Globus inverts this. Evidence changes → facts change → rules re-run → the assessment picture changes → the workflow reacts. The workflow is a consequence of the evidence state, not the other way around. This single inversion — the Living Eligibility Model stated at the top of this page — is what makes every scenario below automatic instead of a manual unwind-and-redo. ### Scenario 1: Evidence verified — eligibility expands **Intern only → Intern + Trainee** — Trigger: a second employer reference is returned and verified The most common movement: an applicant gains a route because more evidence lands. (Both this scenario and the next assume the applicant's degree-route prerequisites are already met — the months of verified experience are the only moving part.) 1. Approved Eligibility Assessment V1: **Intern eligible, Trainee not yet** — only 9 verified months of experience. 2. The applicant adds a second employer; the reference is returned and verified. 3. Verified experience recalculates to 14 months; the affected facts update. 4. Rules re-run automatically; the Trainee route group now passes provisionally. 5. The provisional result differs from the approved one, so a material-change review work item is created; staff approve Assessment V2: **Intern + Trainee**. V1 stays on file, superseded. 6. The Eligibility Projection updates and the applicant automatically surfaces in the Trainee matching pool — no one reopened a workflow, no one re-entered data. ### Scenario 2: Evidence rejected — eligibility shrinks **Intern + Trainee → Intern only** — Trigger: an employer disputes a claimed employment; the verification is rejected The same machinery runs in reverse, which is exactly why it must be fail-closed. 1. Approved Assessment V1: **both routes eligible**, resting partly on 20 verified months. 2. An employer disputes the claimed employment; that verification record is rejected. 3. Verified experience drops below 12 months; rules re-run; the Trainee group now fails. 4. Material-change review fires; staff approve Assessment V2: **Intern only**, with the rejection as its recorded basis. 5. The projection updates and the Trainee matching pool no longer shows the applicant. Any in-flight Trainee job-order proposal is flagged for review rather than silently proceeding. ### Scenario 3: Start date moves — the Intern window closes **Intern eligible → Trainee only** — Trigger: the host moves the arrival date past the 12-month post-graduation window Start date is an eligibility **input**, not scheduling detail — this is the scenario that surprises most readers (it is the same mechanic as Worked Example D below). 1. Approved Assessment V1: **Intern eligible** — graduation was 10 months before the proposed start, inside the 12-month window. 2. The host moves the arrival date; the program now starts 14 months after graduation. 3. The placement-sourced start-date fact changes; rules re-run; the Intern route fails for this placement while the Trainee route still passes. 4. Material-change review; Assessment V2 approved; the projection updates and Matching automatically restricts the applicant to Trainee-compatible orders. ### Scenario 4: Targeted remediation — one record reopens **Trainee pending → Intern + Trainee** — Trigger: one of three employers cannot be verified The scenario that defines the applicant experience: fixing one thing never reopens everything. 1. Provisional result: **Intern eligible, Trainee pending** — one of three employers cannot be verified. 2. The applicant receives a targeted request naming exactly that employer and the reason ("employment could not be verified"), with the option to correct dates or provide an approved alternative document. 3. **Only that employment record reopens.** The other two employers, the education evidence, and every other completed step stay locked. 4. The applicant uploads a reference letter; it is verified; experience recalculates; rules re-run; the projection moves to **Intern + Trainee eligible** pending staff approval of the superseding assessment. 5. Staff approve — or decline, with reasons. Either way the full chain (claim → evidence → verification → recalculation → decision) is on file. The Workflow Studio mechanics behind this scenario: when an applicant declares an employer, the workflow creates a per-employer **employment card** carrying its own reference request, employment documents, alternative-evidence slot, and verification state. Cards succeed or fail independently — one failed card reopens alone while the rest of the application stays locked, and each card's verification feeds the experience recalculation on its own. That per-record granularity is what makes targeted remediation possible at all; it depends on the platform record-level remediation capability listed under Platform Dependencies. ### Scenario 5: DS-7002 amendment triggers reassessment **Approved chain → Reassessment required** — Trigger: the host amends the signed DS-7002 training plan The loop does not close at approval — the DS-7002 itself is regulated evidence. 1. Placement approved, Regulatory Decision set to **Intern**, DS-7002 signed by all parties. 2. The host restructures the training plan; the amended phases shift the activities from Hospitality into Business-dominant duties. 3. The DS-7002's fields — occupational category, dates, phases, objectives — are regulated facts, so the amendment changes canonical facts and rules re-run. 4. A new Placement Assessment is required (and a new Eligibility Assessment where applicable); the amended DS-7002 goes back through signatures. 5. DS-2019 issuance and any downstream SEVIS action stay blocked until the corrected chain — placement assessment, decision, signed plan — is complete again. Never a silent rewrite of the approved basis. ## Eligibility via the Rules Engine All Intern/Trainee eligibility logic lives in the Rules Engine as rules over canonical facts. The Eligibility Assessment orchestrates evaluations and records references to their results; it contains no eligibility logic of its own. ### Evidence Verification Pipeline The architecture this whole scope hangs on is one repeating pipeline, and it is worth stating explicitly because every regulated program will reuse it: ``` Evidence (uploaded documents, declared records) │ ▼ Evidence Verification (human or automated review; immutable verification records) │ ▼ Evidence Sufficiency ("do we have enough verified evidence to calculate?" — per fact) │ ▼ Canonical Facts (single agreed data points, registered in the facts catalog) │ ▼ Rules Engine (versioned rules evaluate the facts; pass/fail + reason codes; owns the immutable facts snapshot + rule versions per evaluation) │ ▼ Assessment (immutable decision record; references the engine evaluations) ``` Nothing downstream ever reads raw evidence: rules read facts, facts come only from verified evidence, the engine's evaluation records freeze both at evaluation time, and assessments point at those records. That is what makes a decision explainable years later. **Sufficiency is a distinct question from verification.** "Is this document verified?" is per item; "do we have enough verified evidence to calculate this fact?" is per fact — and it is the question Operations actually spends its day answering. - Three employers with two verified and one pending can be *sufficient* to compute verified experience — the pending one simply doesn't count yet. One verified employer out of three may not be. - Sufficiency is evaluated per fact against the versioned evidence policy. It is a concept in the pipeline, not a new entity. - An insufficient fact leaves its rules indeterminate — never defaulting to eligible — while generating the targeted evidence request that tells the applicant exactly what is missing. **Experience Verification** is the first-class worked instance of this pipeline — the Trainee route depends on it entirely, and today no part of it exists. The chain runs in four stages: 1. **Employment Record** — the applicant's declared job, dates, role, and field. 2. **Evidence** — contracts, reference letters, payslips backing that record. 3. **Verification** — an immutable per-item verification record: verified, rejected, or alternative approved. 4. **Verified Experience** — verified items roll up into qualifying months per occupational category and field (computed by the algorithm in Open Decisions), feeding the Rules Engine as `applicant.experience.verified_months_in_field`. Each stage is separately auditable: "the applicant claimed 24 months, we verified 18, here is why" must always be answerable. Like the taxonomy, this is built as a **platform evidence-computation service**, not an Intern/Trainee one-off — any future program that asks "how much verified experience does this person have?" reuses it. ### Canonical Facts > **The single largest work item in this scope.** None of the fact keys below exist in the live facts catalog today, and in this engine an unregistered fact makes a rule *permanently indeterminate* — it never fails loudly, it just never resolves. Every fact needs catalog registration **plus** resolver wiring, and several need resolver source paths that barely exist today (placement-, host-, designation-, and DS-7002-sourced facts). The plan per fact: - `applicant.degree.awarded_date`, `applicant.degree.institution`, `applicant.degree.field_of_study` — **Missing** (today: nearest is boolean-level degreeCertificateVerified / applicant.degree_equivalent_verified). Plan: Register attribute-level facts; resolver source: verified education evidence (document wave). - `applicant.enrollment.current` — **Missing** (today: not in the catalog). Plan: Register; resolver source: verified enrollment evidence. - `applicant.experience.verified_months_in_field` — **Missing** (today: not in the catalog — and the computation feeding it is an Open Decision). Plan: Register once the experience-months algorithm is specified. - `application.proposed_start_date` — **Missing** (today: nearest is programStartDate, sourced from the active season, not the placement). Plan: Register a placement-sourced fact; do not reuse the season-sourced one. - `placement.occupational_category`, `placement.occupational_field`, `placement.hours_per_week`, `placement.duration_months`, `placement.clerical_percentage` — **Missing** (today: no placement-sourced resolver path exists). Plan: New resolver source path (placement / job order) + registration. - `sponsor.designation.*` — **Missing** (today: nearest is single-value program.sponsor_designation). Plan: Register against the new Sponsor Authority entity. - `host.compliance_assessment_passed` — **Missing** (today: no host-sourced resolver path). Plan: New resolver source path (Host Compliance Assessment record) + registration. - `ds7002.complete`, `ds7002.signatures_complete` — **Missing** (today: not in the catalog). Plan: New resolver source path (DS-7002 record) + registration. - `englishProficiencyTests` — **Partial** (today: English proficiency exists as this catalog fact). Plan: Reuse the existing catalog fact where semantics match. ### Outcomes & Matching Effect Per-route rule groups produce richer outcomes than pass / fail — the engine also distinguishes indeterminate results, review-required cases, resolver errors, and stale or conflicted facts. The assessment **retains those route-level technical outcomes in full**; the fold below is the *operational projection only*, and two failure classes are never allowed to masquerade as ordinary states: a resolver or system failure must never display as `evidence_pending`, and a human-review case must never display as plain `ineligible`. The projection therefore exposes seven states — the five route states plus two safety states: | Outcome | Meaning | Matching effect | | --- | --- | --- | | **intern_only** | Meets Intern rules for the proposed start date; no Trainee route. | Only Intern-compatible job orders may be proposed. | | **trainee_only** | Meets a Trainee route; outside the Intern graduation window. | Only Trainee-compatible job orders may be proposed. | | **both_eligible** | Independently meets both. | Either route may be proposed; sponsor approves the final route. | | **evidence_pending** | A route exists on paper, but required evidence is unverified. | Not placement-ready; per-fact reason codes drive targeted evidence requests. | | **ineligible** | No current route passes. | Matching blocked, with reason and remediation options shown. | | **review_required** | The engine returned an indeterminate or review-flagged result; a human must adjudicate before any route state applies. | Matching blocked; a compliance review work item exists — never shown as plain ineligibility. | | **system_error** | A resolver failed or facts are stale / conflicted; the result is not trustworthy. | Matching blocked; surfaced to platform operations as a fault — never shown as evidence pending. | ### Re-evaluation & Supersession Re-evaluation is event-driven but never silently changes an approved decision. Three levels: | Level | System behavior | Human action | | --- | --- | --- | | 1. Provisional calculation | Re-run rules whenever a material fact changes. | None, unless the outcome differs. | | 2. Material-change review | When the provisional result differs from the approved result, create a compliance work item in the queue system. | Authorized staff review the change. | | 3. Superseding assessment | A new immutable approved assessment supersedes the old one; the chain is retained. | Sponsor approver records decision and basis. | What Operations actually sees when this fires is a before-and-after, not a raw rule dump: *previous projection* (Intern only) → *current projection* (Intern + Trainee) → *reason* (additional employment verified) → review → approve. Operations never manually decides whether to reassess — the system identifies the material change, creates the review work item, and presents the delta with its cause. Trigger events: education record created/corrected; enrollment, degree, or graduation evidence verified/rejected; employment record or dates changed; employment evidence or reference verified/rejected; occupational classification changed; proposed start/end date changed; job order proposed, changed, or withdrawn; host, site, supervisor, or workers' compensation status changed; DS-7002 content or signatures changed. ## Regulatory Bundle **Start from the live draft, not from zero.** The live Rule Library already contains `teach-intern-trainee-compliance` (draft v1, 13 published rules, precedence 400, manual-attach, pinned to the "Teach Intern and Trainee" program only). It already covers most of what this scope needs: intern and trainee eligibility verification, English proficiency, DS-7002 completeness, evaluation schedule, full-time training, host screening, site-visit requirement, placement-before-DS-2019, finances, duration cap, program exclusions, and not-ordinary-employment. Genuinely net-new rules: designation-scope, occupational-category alignment, clerical-percentage, and the granular route inputs (graduation window, experience months, five-year route). Bundle keys are **hyphenated** (`j1-standard`, `teach-intern-trainee-compliance`), matching the live library. > **This scope supersedes the pathway-discriminator decision.** A previously recorded platform decision resolved the intern-vs-trainee question with a registration-time discriminator on the application. This scope explicitly replaces that design with the dual-route model and its seven-state operational projection: classification is post-evidence and sponsor-owned under 22 CFR 62.22(d); per-route rule groups are evaluated independently; the projection fold lives in the Eligibility Assessment (a consumer of the engine, no engine changes). The two designs must not be implemented in parallel. **Draft-bundle migration.** As authored, the draft cannot publish: `j1.intern.eligibility_verified` and `j1.trainee.eligibility_verified` are both fail-closed and mutually exclusive, so publishing would fail essentially every applicant. Migration: demote the two route rules from required fail-closed gates to **advisory route-group evaluations** consumed by the Eligibility Assessment, and move the hard gate to **DS-2019 issuance on Regulatory Decision + matching approved route** — which is where this scope's SEVIS-gate section puts it anyway. **Attach strategy** (five I/T programs already live across brands): - The **category-scoped auto-attach bundles** `j1-intern` and `j1-trainee` are already seeded at precedence 300 on `visa_type: J-1` plus `category_code: intern_trainee`, modeled on `j1-camp-counselor`, carrying the 22 CFR 62.22 floors so every current and future I/T program gets the regulatory minimum automatically. - The **program-pinned bundle** retained for program-specific extras (e.g. Teach-specific policy). - **Explicit collision rules** when both attach to one application: precedence ordering, and no rule evaluated or counted twice. Both contract points are already implemented in the shipped seed and resolver. **Precedence:** in the seed `j1-standard` sits at 100, the category bundles (`j1-intern`, `j1-trainee`, `j1-camp-counselor` and the other category bundles) at 300 (the same band as `j1-baseline`), and the program-pinned `teach-intern-trainee-compliance` bundle at 400; confirm against the live library. **Attach predicate:** the bundle resolver understands `visa_type`, `program_model_type`, `category_code` and `allows_dependents`, so category-scoped auto-attach is already expressible: `j1-intern` and `j1-trainee` attach on `visa_type: J-1` plus `category_code: intern_trainee`. No new predicate is required. - The bundle definition needs an explicit `allowedCycleTypes` decision — the worked examples' "2027 Rolling" cycle must be within the bundle's allowed cycle types or program/season creation is rejected by the cycle-type model. Compliance-critical members are `lock_required`; bundles are immutable — adding a rule later means a new bundle version plus the standard migration flow. One correction to the shared-gates assumption: **banned-country checking is currently SWT-specific** (an SWT-eligibility country flag plus SWT sync), not a platform-layer gate — applying it to Intern/Trainee is new work, tracked in the gap table. ## Workflow Studio vs Rules Engine Workflow Studio controls what the applicant is asked; the Rules Engine decides what it means. The boundary, capability by capability: | Capability | Workflow Studio | Rules Engine / Compliance | | --- | --- | --- | | Ask for education and work history | Yes | No | | Required fields and conditional visibility | Yes | Consumes results where needed | | Repeatable employment records | Yes | Evaluates each record | | Request references / evidence | Yes | Determines verification status and qualifying months | | Decide Intern eligibility | No | Yes | | Decide Trainee eligibility | No | Yes | | Approve occupational alignment | No | Yes, with human sponsor review | | Open targeted remediation | Provides the UI capability | Creates the request and reason | | Select final participant type | No | Placement proposal + sponsor approval | | Generate DS-7002 obligations | No | Compliance / placement module | ## Program Configuration (P11.5) Intern/Trainee program configuration is Workflow Studio work in the Phase-2 configuration family (`P11.5: Program Configuration (Teacher Lounge)` owns the Teach trees; Intern/Trainee gets its own step trees in the same family): - One shared intake tree — identity, education evidence, employment evidence, English proficiency, banned-country gate, insurance — with **conditional evidence steps**, not separate hard-coded workflows per route: a current student needs enrollment evidence; a recent graduate needs graduation evidence; a potential five-year Trainee needs enough employment evidence to establish five qualifying years. - Step status uses the canonical vocabulary (`completed`, not `complete`); locking follows the Globus-authoritative step-locking contract. - Program-level configuration binds the offered occupational categories (a subset of sponsor-authority scope) and pins workflow, ruleset, and evidence-policy versions so in-flight applications stay on the version they started with. ## Applicant Portal Behavior The Applicant Portal is an **evidence portal, not an eligibility portal**: applicants manage their evidence — documents, work history, references — and the system manages eligibility. An applicant never edits, requests, or manages an eligibility status directly. - Registration collects no route choice — one "Intern / Trainee" application, one document checklist. - Internal recalculations are invisible. The portal shows a neutral status ("Your education and experience are under review") unless the applicant actually needs to act. - When action is needed, a **targeted evidence request** reopens only the affected record, never the whole step: > **Additional employment evidence required.** We could not verify your employment at Hotel ABC for January 2021 to December 2022. Please either correct the employment dates, or provide an approved alternative document. *(Only the Hotel ABC work-history record is reopened.)* - Assessment outcomes are surfaced in plain language ("You currently qualify for the Intern route") without exposing rule internals, reason codes, or staff notes. - The full loop from the applicant's side, end to end: status shows *"Intern: eligible · Trainee: under review"* → the applicant receives *"Additional evidence required — ABC Hotel, Jan 2022 – Dec 2023: employment could not be verified"* → they upload a reference letter → it is verified → the status becomes *"Intern: eligible · Trainee: eligible."* No manual reopening, no restarted workflow, no support ticket — the portal simply reflects the Eligibility Projection as it moves. - Route explanation content is a docs/help concern (P9 family), not portal logic. ## Matching, Job Orders & Placement Job orders for Intern/Trainee extend the existing job-order model: | Field | Notes | | --- | --- | | `occupational_category` + `occupational_field` | From the taxonomy; must be within program scope | | `proposed_route` | Optional partner preference; never authoritative | | Duties / training summary | Phase-structured enough to seed the DS-7002 | | `hours_per_week` | Full-time check input for Trainee. Exists today as `averageHoursPerWeek` — a string inside the job-order requirements blob — so the `placement.hours_per_week` fact resolver needs type coercion to a number | | Start/end dates and duration | Validated against route and category caps | | `clerical_percentage` + prohibited-activity attestations | Rules Engine inputs | - Matching reads the **Eligibility Projection**, never assessment records directly: it filters candidates by the projection's current outcome — a `trainee_only` applicant never surfaces for an Intern-preferred order and vice versa; `both_eligible` applicants surface everywhere. This keeps Matching decoupled from the assessment chain: it asks one question ("who is currently eligible for what?") of one derived view, and supersession or pending reviews change what Matching sees without Matching knowing why. **Matching is stateless with respect to eligibility**: it never caches or copies eligibility into its own tables — every search consumes the latest Eligibility Projection at query time. - Every proposed match creates a **Placement Assessment**; placement confirmation re-runs eligibility against the order's actual start date and category before the reservation hardens — the start-date flip (Worked Example D) is a first-class flow, not an edge case. - Matching is therefore a **feedback loop, not a terminus**: a proposed placement contributes new regulatory facts (dates, category, field, hours, host status) into the same fact-and-rules machinery that produced the eligibility it consumed. If those facts flip the projection — the start date moves, the category no longer aligns — Matching sees the change immediately and adjusts which opportunities the applicant surfaces for, with no manual intervention. ## Host Compliance Assessment Host compliance is an ongoing assessment over the host relationship, not a one-time pass/fail gate. A host must hold a current, passing compliance assessment before any placement approval, bringing together what today lives in separate places: - Legal identity (name, EIN), sites of activity, and revenue thresholds (which drive site-visit requirements). Employee count — the other threshold input — already exists as `total_employees` on the host organization profile, alongside `annual_revenue`. - Workers' compensation evidence, supervisor and facilities review. - Site-visit required / completed / waived status — including recurring site-visit obligations, not just the initial visit. - Approved occupational categories for that host, with approval and expiry status. - Room over time for the fuller host relationship: complaint history, monitoring findings, and suspension state, so a host in bad standing blocks new placements the same way a failed check does. The assessment result is a Rules Engine fact (`host.compliance_assessment_passed` — named after this entity, since fact keys are effectively immutable once frozen into the engine's evaluation records that assessments reference); reviews are immutable records, re-run on host material changes via the same re-evaluation machinery — the same assessment-record pattern used for applicants, applied to hosts. ## DS-7002 → DS-2019 / SEVIS Gate DS-2019 issuance (and therefore SEVIS registration) is gated on: 1. Approved Eligibility Assessment permitting the chosen route. 2. Approved Placement Assessment for the actual placement. 3. Regulatory Decision in state `final` (which itself requires the signed, approved DS-7002 version), with a Compliance Opinion of Approved — or Approved with Conditions where every condition flagged `blocks_ds2019` is satisfied; non-blocking conditions remain open as monitoring obligations. 4. DS-7002 current version complete with **all** required signatures. 5. All `lock_required` bundle rules passing. **The DS-7002 is regulated evidence, not just a document.** Once the sponsor approves the placement, its contents — occupational category, participant type, host, supervisor, dates, training phases, objectives — become regulated facts. Any subsequent change to those facts requires a new Placement Assessment, a new Eligibility Assessment where applicable, an amended DS-7002 back through signatures, and, if required, a corrected Regulatory Decision — all before DS-2019 issuance or any SEVIS action continues (Scenario 5 above walks through exactly this). The gate is a Rules Engine evaluation, so blocking reasons are enumerable and surface in the queue system like every other compliance gate. Missing or inconsistent data **blocks progression — it never defaults to eligible**. Post-SEVIS lifecycle (check-in, monthly check-in, extensions, completion) reuses the existing On-Program machinery, plus midpoint/final evaluation obligations generated from the approved program duration. ## Worked Examples Four realistic applicants, traced through the model end to end. ### Example A: Education applicant eligible as Intern only | | | | --- | --- | | **Setup** | Brand: Teacher Lounge · Program: Teach Intern and Trainee · Cycle: 2027 Rolling | | **Evidence** | Currently enrolled in a qualifying education degree; six months of relevant teaching-assistant experience | | **Intern route** | **Eligible** | | **Trainee route** | **Not yet eligible** — under 12 verified months | | **Category / field** | Education, Social Sciences, … · Early Childhood Education | | **Matching effect** | A 12-month education Intern job order may be proposed; Trainee job orders are blocked | ### Example B: Hospitality applicant eligible for both | | | | --- | --- | | **Setup** | Program: Hospitality Intern & Trainee (future program — not live today) | | **Evidence** | Hospitality degree; graduated eight months before the proposed start; two years of verified hotel Front Office experience | | **Intern route** | **Eligible** — for the proposed start date | | **Trainee route** | **Eligible** — through the degree + one-year route | | **Combined display** | Eligible for Intern or Trainee | | **Job order** | Hospitality/Tourism · Front Office · proposed type: Trainee · 12 months | | **Result** | **Compatible** — subject to sponsor approval and DS-7002 | ### Example C: Hotel marketing role classified as business | | | | --- | --- | | **Applicant** | Marketing degree; digital-marketing experience | | **Host / job order** | A hotel group · Digital Marketing role | | **Classification** | Management, Business, Commerce and Finance · Marketing — **NOT Hospitality Operations** | | **The rule** | The actual training activities — not the host's industry — determine the classification | ### Example D: Start-date change flips eligibility | | | | --- | --- | | **Approved assessment** | Intern **Eligible** · Trainee **Evidence pending** | | **The change** | Placement start date moves four months later | | **New provisional result** | Intern **Ineligible** (outside the 12-month graduation window) · Trainee **Eligible** once one more employer verification lands | | **System response** | Create a material-change review work item; do **not** silently change the approved route; the sponsor approves a new superseding assessment; placement and DS-7002 updated if needed, before DS-2019 | ## Globus Gap Analysis The gap analysis, measured against what the platform actually has. **Priority** says how urgent a capability is; **Complexity** says how hard it is to build: **Low** — configuration or a small extension of machinery that already works; **Medium** — a new component built on existing platform paths; **High** — new machinery, new resolver paths, or work blocked on an Open Decision. A Critical-priority / Low-complexity row is quick to clear; a Critical / High row is where the schedule risk lives. | Capability | Current Globus position | Required change | Priority | Complexity | | --- | --- | --- | --- | --- | | Eligibility rule evaluation | **Exists** — Rules Engine with reason codes and bundles | Author I/T route-input rules; no new engine. The engine exists, but see the Facts wiring row — rules cannot resolve without it | — | **Low** | | Facts wiring | **Missing** — none of this scope's fact keys are in the live facts catalog; an unregistered fact leaves a rule permanently indeterminate | Register every fact + wire resolver source paths (placement, host, designation, DS-7002 are new paths) — see Canonical Facts | **Critical** | **High** | | Immutable rulesets / versioning | **Partial** — draft bundle `teach-intern-trainee-compliance` (13 published rules) already exists | Reconcile / extend / migrate the existing draft; only route-input, designation, and taxonomy rules are net-new | **Critical** | **Medium** | | Re-evaluation on fact change | **Exists** — engine re-evaluation + queue work items | Wire I/T trigger events; add supersession on the assessment record | **Critical** | **Medium** | | Conditional evidence collection | **Exists** — Workflow Studio conditional steps | Author I/T step trees (P11.5) | **Critical** | **Medium** | | Audit with reason codes | **Exists** — platform audit standard | New event vocabulary, plus engine-evaluation references on every assessment (the engine owns the immutable evidence/rule snapshots) and supersession-chain links between decisions | **High** | **Medium** | | Banned-country gate | **Missing for I/T** — today's machinery is SWT-specific (SWT-eligibility country flag + SWT sync), not a platform-layer gate | Build or generalize a banned-country gate for I/T | **High** | **Medium** | | Occupational Category / Field taxonomy | **Missing** | New platform entity + program mapping | **Critical** | **Medium** | | Sponsor Authority | **Missing** | New platform-wide entity | **Critical** | **Medium** | | Eligibility Assessment record | **Missing** | New adjudication record referencing engine evaluations | **Critical** | **High** | | Eligibility Projection | **Missing** | New derived current-view entity over the assessment chain | **Critical** | **Medium** | | Experience Verification pipeline | **Missing** | Employment Record → Evidence → Verification → Verified Experience chain; verified-months computation (algorithm TBD — Open Decisions) | **Critical** | **High** | | Placement Assessment | **Missing** | New per-match record with non-duplication, hours, prohibited-activity checks | **Critical** | **High** | | Host Compliance Assessment (consolidated) | **Partial** — host vetting exists, not consolidated as one assessment fact | Consolidate into an assessment record + engine fact | **Critical** | **Medium** | | Job Order regulatory fields | **Partial** — hours/week already exists (`averageHoursPerWeek`) | Extend with category, field, route, clerical %, attestations (hours already there) | **Critical** | **Low** | | DS-7002 record | **Partial** — a seeded DS-7002 document type and the live `ds7002_completed_signed` rule exist | Build the versioned entity with per-signatory signature state | **Critical** | **High** | | Regulatory Decision | **Missing** | New locked decision entity with Compliance Opinion | **Critical** | **Medium** | | Record-level remediation | **Partial** — staff-side item-level review exists in the step-review panel | Portal-side single-record reopen (platform work-item mechanics; dependency, not owned here) | **High** | **High** | | Evaluation obligations (midpoint/final) | **Partial** — On-Program machinery exists | Generate obligations from approved duration | **High** | **Low** | | RBAC for regulatory decisions | **Partial** | New grants for assessment approval, compliance opinions, the Regulatory Decision, taxonomy, sponsor authority | **Critical** | **Low** | ## RBAC, Approvals & Audit - "Authorized Globus user" is never the final answer for a legal sponsor decision — every regulated action maps to a named permission. Eligibility determinations are already gated by the shipped `eligibility.approve` (approve / reject / revoke) and `compliance.console.view` (reads and re-evaluation). Further new permission families: `compliance.placement_assessments.review`, `compliance.regulatory_decisions.set`, `compliance.regulatory_decisions.correct`, `compliance.sponsor_authority.manage`, `compliance.occupational_taxonomy.manage`. Sponsor-authority and taxonomy grants are platform-admin level, and the platform's existing role split is respected: Compliance Admin authors rules and policy; Compliance Officer reviews, adjudicates, and overrides live cases. - **Segregation of duties:** a person who changes Sponsor Authority, the occupational taxonomy, or underlying compliance policy must not approve an applicant under the newly changed policy without independent review. The system enforces this as a review requirement, not a convention. - Partners can propose routes and submit job orders; they can read assessment outcomes for their own applicants (through the standard partner redaction/projection layer) but never approve. Regulated decisions cannot be made by partner users. - Audit events use the dotted-scoped vocabulary: `eligibility.determination.approve / reject / revoke`, `eligibility.assessment.evaluate`, `placement_assessment.created / approved / rejected`, `regulatory_decision.set / correction_requested`, `compliance_opinion.recorded`, `ds7002.version_created / signed / completed`, `occupational_category.*`, `sponsor_authority.*`, `host_compliance.*`. Every approval records actor, time, and the engine evaluation references that resolve to the exact ruleset version and evidence snapshot. Nothing is hard-deleted. Audit reads assessment records, never the Eligibility Projection. ## Platform Dependencies Work this scope needs but does not own: - **Record-level remediation** — re-requesting one failed evidence item without resetting the step. Platform work-item mechanics; Intern/Trainee is the first consumer. - **Sponsor Authority** — platform-wide; SWT and Camp will consume it too. - **Experience Verification / verified-experience computation** — a reusable platform evidence-computation service, not an Intern/Trainee one-off. - **Occupational Category taxonomy** — platform master data consumed by any program that classifies placements. > **Future platform consumers.** These capabilities are intentionally reusable beyond Intern/Trainee: Sponsor Authority, the Occupational Taxonomy, Experience Verification, the Eligibility Projection, the Regulatory Decision record, and record-level remediation. Future programs — Teach, Camp, SWT, and non-US programs — are expected to consume these platform services rather than build parallel ones. ## Open Decisions These questions must be answered before this scope can be fully built — each one is a formal architecture gate for the workstreams that depend on it. Each row states the question in plain terms, why it matters, and who owns the answer. | Decision | The question, in plain terms | Owner | | --- | --- | --- | | Experience-months algorithm | How exactly do we count months of experience? If someone worked two jobs at once, does that count once or twice? Does part-time work count in full or in part? What about gaps — and how close must a past job be to the training field to count as "in field"? Trainee rules cannot be written until this math is pinned down. | Compliance + platform | | Ten-month Intern buffer | Our internal process mentions a ten-month buffer, but no regulation requires it. Do we keep it as an official, adjustable sponsor policy — or drop it? | Compliance | | DS-7002 signature mechanics | How do people actually sign the DS-7002 — electronically through a provider, or by uploading a signed paper copy? Can different signers use different methods? And where is the form created and stored today? | Platform + compliance | | Combined vs split programs | Do applicants apply to one combined Intern/Trainee program, or to two separate ones? Splitting sounds simple but isn't: the rule bundles, the five live programs, and the automatic rule-attachment logic are all built around the combined category today. | Product | | Legal sponsor entity per brand | Do all our brands sponsor visas under one State Department designation, or several? The actual designation paperwork is the source of truth, and it must be confirmed before production. | Compliance | | Commercial vs Regulatory Program split | A "program" currently means two things at once: the product we sell and the visa category we sponsor under (acknowledged in Program Hierarchy Placement). Should those become two separate concepts — and if so, when? This is a platform-wide decision, not an Intern/Trainee one, and it recurs in every architecture review — it warrants its own standalone platform architecture proposal rather than remaining a row here. | Product + platform | | Bundle naming convention | The live Rule Library uses hyphenated bundle keys (`j1-standard`); some platform contract documentation uses underscores. Two spellings of a stable identifier cannot both remain standard. Resolution: one side adopts the other — the cheapest path is aligning the contract documentation with the live library, since renaming live bundle keys under five running programs is high-risk. Owned by the Rules Engine platform side, not this scope. | Platform | | Evidence policy | Which documents count as proof of past employment? Who is allowed to accept a substitute when the standard document can't be obtained? Reference letters are our own policy, not a regulation — so the policy must stay versioned and editable, never hard-coded. | Compliance | ## Rollout & Installed Base > **Rollout is a migration, not a launch.** Five Intern/Trainee programs are already live. Publishing a category auto-attach bundle whose facts are not wired yet would mass-fail (or flood review queues for) every in-flight applicant. Rollout requirements: - **Staged bundle attach.** Wire and verify facts first; attach the category bundle to one program (Teach Intern and Trainee, where the draft is already pinned), observe, then extend to the remaining four programs. - **Fail-safe mode per rule.** Each rule gets an explicit choice: fail-closed (blocks progression), advisory (informs the assessment), or monitor-only during rollout. The two route rules are advisory by design (see the bundle migration above); the hard fail-closed gate lives at DS-2019 issuance. - **Impact statement for existing programs.** Before any attach, an explicit analysis of how many in-flight applicants each rule would flag, and what the review-queue load looks like. - **Bindings + gate wiring per phase.** A published rule enforces nothing until it has evidence bindings and is wired into the relevant gate (SEVIS-readiness / placement). Each delivery phase below carries its own bindings-and-gate-wiring work, not just rule authoring. - **Cycle-type constraints.** The bundle's `allowedCycleTypes` must admit the live rolling cycles, or program/season creation is rejected. ## Delivery Sequence When this scope is decomposed into tickets (not yet done), the phases and their owning surfaces: - **1. Regulatory foundation** (Globus platform entities) — Occupational Category taxonomy, Sponsor Authority, program authorization mapping, canonical terminology. First because it prevents more data being created against ambiguous categories. - **2. Applicant eligibility** (Rules Engine (P3) + Program Configuration (P11.5)) — Facts registration + resolver wiring, evidence steps, Experience Verification pipeline, route rules, draft-bundle migration, Eligibility Assessment + Projection. Creates reliable Intern/Trainee pools. - **3. Portal remediation** (Platform + Applicant Portal (AP)) — Record-level evidence requests, selective reopening. Makes re-evaluation operationally usable. - **4. Host & job-order compliance** (Globus platform + matching) — Host Compliance Assessment, job-order extensions, prohibited-activity and duration checks. Prevents invalid matching. - **5. Placement approval** (Matching / job orders) — Placement Assessment, Compliance Opinion, Regulatory Decision. Controlled route selection. - **6. DS-7002 & SEVIS gate** (SEVIS lifecycle) — Versioned DS-7002, signatures, amendment flow, issuance gate. Completes the regulatory chain. - **7. In-program obligations** (On-Program lifecycle) — Midpoint/final evaluations, monitoring, amendments. Covers the lifecycle beyond issuance. Applicant-facing route explanations land in the P9 documentation family alongside phase 2. ## Key Risks | Risk | Impact | Mitigation | | --- | --- | --- | | One generic "category" field | Regulatory category, occupational category, and job field get conflated | Canonical entities and migration rules before implementation | | Job-order selection treated as final authority | Partner or Operations makes an unapproved regulatory classification | Sponsor approval + explicit permissions | | Counting total instead of relevant experience | Applicant incorrectly found Trainee-eligible | Calculate by occupational category/field from verified evidence only | | Reopening whole workflow steps | Applicant confusion, data loss, poor auditability | Record-level remediation, immutable versions | | Conflating cycle and participant duration | Invalid program length, reporting errors | Dates on placement / DS-7002; validate separately | | Hard-coding reference letters as regulation | Policy becomes inflexible and legally mischaracterized | Versioned evidence policy with controlled alternatives | | Silent changes after approval | Approved decisions and issued documents diverge | Material-change review + supersession, never rewrite | | Eligibility without host / DS-7002 controls | System looks compliant but permits invalid placements | Deliver the complete chain, not applicant rules alone | ## Conclusion Intern/Trainee is intentionally the first consumer of this architecture rather than a special case. The objective is to establish reusable platform capabilities — living eligibility assessment, sponsor adjudication records, verified-evidence computation, and regulated decision audit — that can support future regulated programs without creating parallel implementations. ## Related Pages - Rules Engine — canonical facts, bundles, and the Normative Contracts section. - Applicant Lifecycle — where the assessment and SEVIS gate sit in the pipeline. - Job Orders — the base model extended here. - Workflow Builder — step trees and conditional evidence mechanics.