---
title: "Glossary"
slug: glossary
section: Reference
status: stable
description: "Key terms and definitions used across the Sponsor Ecosystem"
last-updated: 2026-10-07
---

# Glossary

Key terms and definitions used across the Sponsor Ecosystem

## Organizational Terms

The designated sponsor organization authorized by the U.S. Department of State to administer
Exchange Visitor (J-1) programs. The sponsor operates multiple brands and programs.
A top-level organizational unit within the sponsor. Each brand operates independently with
its own programs, partners, and compliance rules. Brands: Alliance Abroad, Wild Packs,
Teacher Lounge, StepWest, GeoVisions.
A specific exchange visitor program within a brand. Each program has its own eligibility
rules, seasons, quotas, and compliance requirements. Example: “Camp Counselor” within the Camp brand.
A time-bounded operational period within a program. Each season has its own quota allocation,
timeline, and cohort of applicants. Example: “Summer 2025” for Camp Counselor.
## System Terms

The sponsor back office and system of record. Globus manages all operational data, RBAC,
compliance, and government integrations. All external portals integrate directly with Globus.
The participant-facing web application where applicants submit their exchange visitor
applications, upload documents, and track program progress.
The host organization-facing web application for job order management, placement confirmations,
compliance, and logistics coordination.
The recruitment partner-facing web application for applicant submission, quota management,
and post-SEVIS milestone tracking.
The automation orchestration platform used for workflow automation, notifications,
system integrations, and reporting exports.
## Compliance & Government

Student and Exchange Visitor Information System. The U.S. government database that tracks
all J-1 exchange visitors. Sponsors must report participant data to SEVIS.
Certificate of Eligibility for Exchange Visitor Status. The official document issued by
the sponsor that allows an exchange visitor to apply for a J-1 visa.
The non-immigrant visa category for exchange visitors participating in approved programs
in the United States, including work and study-based exchanges.
The process of confirming a participant’s arrival and active participation in the program.
Required within a specified window after the program start date.
The dependent visa for spouses and minor children of J-1 exchange visitors. J-2 dependents
require their own SEVIS records and DS-2019 issuance, linked to the primary J-1 applicant.
A spouse or minor child of a J-1 exchange visitor who requires their own SEVIS record,
DS-2019 document, and lifecycle tracking. J-2 dependents are managed as linked records
under the primary J-1 applicant in Globus, with independent biographical data sync and
status tracking. Termination of the J-1 record cascades to all linked J-2 dependents.
A grouped submission of SEVIS operations (record creation, amendment, or status update)
processed together. Each batch tracks individual participant results (success, validation error,
partial success, or system error) and supports retry logic for failed submissions.
A digital certificate used to authenticate Globus with the SEVIS API. Certificates are
managed with SHA-256 fingerprint validation, expiry monitoring, and environment derivation
(production vs. test determined by the certificate, not a manual toggle).
An on-site inspection of a host employer conducted by the sponsor to verify program compliance,
working conditions, and participant welfare. Required by Department of State regulations.
Responsible Officer and Alternate Responsible Officer. Designated individuals authorized to
sign DS-2019 forms and manage SEVIS records on behalf of the sponsor organization. Credentials
are tracked with rotation schedules and expiry dates.
## Operational Terms

A single attempt at one program in one season. Lives in the `applications` table
and references an `applicant`. Contains workflow status, submittedAt, placement
link, SEVIS link, application-scoped documents, and audit trail. Re-applying for a new
season produces a new application row, not a mutation of the prior one. Distinct from
“Applicant” — see Applicant Data vs Application Data.
The identity slice of the participant record — first name, last name, email,
nationality, brand scope, external CRM/partner ID. Stored on the `applicants`
table and reused across every program attempt the person makes. Rule of thumb: if it would
still be true with no program, it’s applicant data. See the canonical boundary page
for the field-level map and the Partner Visibility Matrix.
The classification axis on every Workflow Studio field that decides where the captured value
is stored: `applicant` means the value is promoted onto the `applicants`
row and persists across every program attempt the person makes; `application` means
the value stays on the per-attempt snapshot. Required field metadata under the
Field Classification Contract — see that page for the decision tree, examples, and the
baseline audit of how this is decided implicitly today.
A Workflow Studio field marked `core: true` in its classification metadata, meaning
other systems (SEVIS, partner portals, host placement cards, reporting) are allowed to
reference it by a stable name. Renaming or removing a core field is a breaking change and
requires a versioned step revision. Non-core fields stay in the snapshot for workflow and
reporting use only and must not be bound to by external consumers. Orthogonal to Field Scope:
a field can be applicant-scope and non-core, or application-scope and core.
A named, partner-facing destination where a Workflow Studio field appears
(`recruiter.summary`, `recruiter.profile`, `host.talent_card`,
`host.profile`, `staff.profile`, or the `workflow_tab_only`
fallback). The `surfaces` slot on every field is required by the Field
Classification Contract; the closed taxonomy of surface names and the rendering contract
each portal must honour live in the Dynamic Field Surface Spec. A field with no surface
defaults to `workflow_tab_only` and triggers an authoring-time warning.
The generic section every partner applicant detail surface
(`recruiter.profile`, `host.profile`, `staff.profile`)
must include to auto-render Studio fields tagged for that surface. Defined by the
Dynamic Field Surface Spec. Renders fields in workflow step order using the field’s
authored label, with audience filtering applied by the step-level `data_scope` and
the platform PII registry — **not** by a per-field redaction enum or a
`partner_visibility` predicate, both of which were explicitly rejected and are
listed in `DEPRECATED_DATA_ACCESS_TERMS` (`shared/contracts/dataAccessContract.ts`).
The section is present
even when zero fields are tagged for the surface — its presence is the contract.
The implicit destination for any Studio field whose `surfaces` slot is empty:
`workflow_tab_only`. The value is captured and stored normally and is reachable
from the staff Workflow tab, but no recruiter, host, or curated staff section ever
renders it. Workflow Studio shows a dismissible warning at authoring time when a field
falls into the fallback so the gap is loud, not silent. Defined by the Dynamic Field
Surface Spec.
A captured value that lives in the `portal_step_snapshots` row for a single
application, keyed by the step’s `step_key`. Every Workflow Studio field starts
as a snapshot field; fields classified as applicant-scope are then promoted onto the
`applicants` row by `biographicalSync`. Today the promotion is decided
by a hardcoded allow-list of step_keys, not by field metadata — see the Field Classification
Contract’s runtime audit for details.
The per-attempt slice of the participant record — programId, seasonId, workflow
status, submittedAt, placement link, application-scoped documents. Stored on the
`applications` table. Meaningless without a program/season context. Each
re-application creates a new row; partners only see the rows they are authorized for via
their org-scoped agreement.
The unified demand-side entity in the Globus ecosystem. Represents a specific job opportunity
created by a host organization with built-in capacity management. Includes role definition,
structured matching requirements (must-have vs nice-to-have), compensation (wage in dollars),
SEVIS classification details, housing, and amendment tracking. Manages its own capacity
(position count, filled count, fill rate) with pause/resume/cancel controls. Statuses:
draft, pending_review, submitted, in_review, partially_approved, approved, rejected, revision_requested, active, paused, cancelled (there is no closed status). Supports inline approval queues with partial
approval and auto-rejection, cloning with housing carry-forward, and post-approval hooks.
Previously a separate entity representing a countable open slot within a job order.
Vacancies have been unified into the Job Order model. Capacity is now managed directly
on the job order via position count and filled count fields. Use “Job Order” and
“job order position” instead.
A time-bound hold on a job order position. Prevents double booking and job hoarding. Includes
an expiry timer, quota integration, and automatic release logic. Converts to a confirmed
placement or expires. Counted against the job order’s remaining capacity. Full
state-machine and timer contract:
Quota Model → Reservation Hold Policy & Auto-Expire
The active period of a reservation, bounded by
`holdExpiresAt`,
during which the held seat counts against the job order’s capacity. A hold ends in
one of these end states —
`Confirmed`
(user-confirmed before TTL; a confirmed hold can still be cancelled if its placement is later torn down),
`Expired`
(TTL elapsed, auto-flipped by the sweeper),
`Cancelled`
(user-released before TTL), or
`Declined`
(host declined the match). See
Quota Model → Reservation State Machine
The configurable per-program TTL applied at reservation insert — system default
7 days (RESERVATION_RULES.BASE_DURATION_DAYS), overridable through the Rule Library hold window on the brand / program / season scope chain. The value in effect
at insert time is captured in
`holdExpiresAt`
and frozen on the row; later edits do not retroactively change existing reservations.
Setting registry:
Settings & Feature Flags → Documented Program-Scope Settings
The 10-minute batch job that performs the only system-driven
`Active → Expired`
transition for reservations. For every row whose
`holdExpiresAt`
has passed, the sweeper flips status, decrements
`positionsReserved`,
and writes one append-only audit row — all in a single transaction. Distinct from
the Reservation Countdown Scanner which only emits the 24h-warning notification. Job
spec:
Batch Jobs → reservation-expiry-sweeper
The canonical specification covering how Globus serializes concurrent reservation
writes against the same job order position, what the losing caller observes, and how
the system catches any duplicate that slips through. Has three parts: a row-level
lock (`SELECT … FOR UPDATE`)
on the job order row inside the reservation transaction with a re-check of the
placement cap; a stable
`HTTP 409 Conflict`
response carrying error code
`RESERVATION_POSITION_TAKEN`
(defined in the next entry);
and a nightly
reservation-placement-integrity-scan
backed by a partial unique index on active reservations and placements (fix #1894).
Full spec lives in
Globus Layers → Reservation Concurrency & Placement Integrity
The canonical error code returned as `HTTP 409 Conflict`
when two reservation writes race for the same job order position and one loses the
row-level lock. Carries a stable, applicant-safe message portals may surface verbatim.
Defined in
Globus Layers → Reservation Concurrency & Placement Integrity
and surfaced in the
Integration Contract Status Code Reference
A time-bound recruitment authorization between the sponsor and a partner. Contains start/end
dates, program and season permissions, quotas, country/job restrictions, and status
(active / probation / suspended). When expired, access is auto-revoked.
Globus’s event-driven integration mechanism. When state changes occur, structured events
are written to the outbox and consumed by external systems (n8n, portals, HubSpot) to stay
synchronized without polling or direct coupling.
An immutable record of every change in Globus. Tracks who changed what, old value, new value,
timestamp, and source (portal/API). Critical for sponsor compliance, legal defense, and
government audits.
A season-level rule that takes precedence over the program default. Allows sponsors to adjust
eligibility criteria, quotas, or compliance rules for a specific operational cycle without
modifying the permanent program definition.
The allocated number of exchange visitors a partner or program can accept within a season.
Quotas are managed at the brand and program level within Globus.
Role-Based Access Control. The permission system that governs what users can see and do
based on their role, brand scope, and program scope.
An international recruitment organization that recruits and submits applicants for exchange
programs. Partners are scoped to specific brands and have allocated quotas.
An organization in the United States that provides placement, employment, or training
opportunities for exchange visitors. Hosts create job orders and confirm placements.
Host organizations follow a lifecycle starting with pending_verification status.
The initial status of a newly created host organization. The organization undergoes
automated verification (web search + AI analysis) and sponsor review before being
activated. Replaces the previous prospecting/onboarding statuses. For non-camp program
types, this status blocks all portal operations until activation. For program type
camp, a host with an accepted operating agreement operates the portal fully while
pending — verification gates DS-2019 issuance only (403 `HOST_VERIFICATION_REQUIRED`
until passed). See Host Portal Governance → Camp Program Divergence.
The governance framework that defines how host organizations move through lifecycle
states (pending_verification, active, probation, suspended, terminated), what approvals
are required at each transition, and how suspension/reactivation flows work. All transitions
are audit-logged.
An automated verification process that runs when a host organization is created.
Combines web search queries and AI analysis to validate the organization’s legitimacy,
business registration, and compliance history. Produces a risk score for sponsor review.
A required document that host organizations must maintain throughout their lifecycle,
such as business licenses, insurance certificates, housing inspection reports, and tax
documentation. Tracked with submission, review, expiration, and renewal status.
An immutable record of every host suspension, reactivation, and termination event.
Captures the acting user, timestamp, reason, and associated compliance documents.
Available for regulatory review and sponsor compliance audits.
The person record. Stable identity across program attempts within a brand — one row
per person per brand in the `applicants` table. An applicant can have many
applications (one per program/season attempt). Distinct from “Application”,
which is the per-attempt record. See Applicant Data vs Application Data.
The confirmed match between an applicant and a job order position at a host organization.
Increments the job order’s filled count. A confirmed placement is required before DS-2019
issuance. Entity chain: Job Order → Reservation Hold → Placement.
The canonical Layer 7 contract that governs every reservation and placement write
path. Reservation holds are `active`, `confirmed` (the host portal labels this *hired*), `cancelled`, `declined` or `expired`; only an `active` hold moves to `confirmed`, `declined` or `expired`, and a `confirmed` hold can still be `cancelled`. `placements.status` is `confirmed` or `active` while the placement is live and `cancelled`, `ended` or `completed` once terminal. Each placement transition mutates
`placements.status`,
updates the linked job-order capacity counter, and inserts an audit row
**in a single database transaction**; if any of the three writes fails,
all three roll back. Defined in
Globus Layers → Reservation & Placement State Machine
A `(from, to)`
pair listed in the Layer 7 transition matrix as either
**allowed** (human-driven: confirm, cancel, or decline a reservation hold) or
**system-only** (for reservation holds, `active` → `expired`, driven by the auto-expire sweeper). Allowed transitions trigger the atomic three-write contract (status +
capacity counter + audit row). Anything outside the matrix is an Invalid
Transition (422). The full matrix lives in
Globus Layers → Transition Matrix
A placement transition request whose
`(from, to)`
pair is not in the allowed or system-only rows of the Layer 7 transition matrix.
A reservation hold transition outside the allowed set is rejected with `HTTP 422 Unprocessable Entity`
and the error code
`INVALID_RESERVATION_TRANSITION`; cancelling an already-cancelled placement returns 409 `PLACEMENT_ALREADY_CANCELLED`. No `PLACEMENT_INVALID_TRANSITION` code exists.
Distinct from `RESERVATION_POSITION_TAKEN`
(409): 422 means the transition can never be valid for this state, while 409 means
a concurrent caller won the race on the Reserve edge. Recovery is in the
Invalid Placement Transition runbook
The canonical Layer 7 audit contract: every placement carries a chronological,
append-only record of every status change it has ever undergone. Each entry captures the
actor (user id, display name, and role at the time of change), timestamp, previous and
new status, a required machine-coded reason, an optional free-text note, and the
originating correlation id. Rows are insert-only — corrections are made by appending
a new transition, never by editing or deleting an existing one. Exposed via
`GET /api/admin/placements/:id/history` — JSON by default, CSV with stable
column order when called with `?format=csv` (there is no `.csv` path variant) —
and the host-scoped `GET /api/partner/host/placements/:id/history`. The admin
route is gated by `placements.view` and both honour the placement’s brand /
program / season scope. See
Layer 7 — Placement Status History
A tracked change to an approved or active job order. Each amendment records the version number,
changed fields, reason, timestamp, and the user who made the change. Amendments maintain an
audit trail of all modifications after initial approval.
The built-in capacity tracking on each job order. Includes position count (total authorized),
filled count (confirmed placements), fill rate (percentage filled), and operational controls
(pause, resume, cancel).
A sponsor-initiated request for the host to modify a submitted job order before approval.
Includes revision notes explaining what changes are needed. The job order returns to an
editable state until the host resubmits.
A configurable, multi-factor scoring system that evaluates applicant-to-job-order fit using weighted
rules. Supports hard filters (must-have), soft scoring (nice-to-have), preference matching (bilateral fit),
bidirectional gap analysis, and program-specific weight profiles. Advisory only — produces ranked
recommendations for staff review, does not auto-place.
The rules-driven engine within Globus that governs applicant state transitions, compliance
checks, and step completion. Defines what actions are possible at each stage.
Configurable business logic that governs eligibility, required documents, deadlines, and
compliance conditions for each program and season. Rules are enforced by the Workflow Engine.
Each rule field carries a source classification (compliance or business) that determines
who can modify it and how it affects workflow publishing. See
Program Rules — One-Page Read
for the canonical story.
A rule field classified as compliance-mandated by a compliance officer. Compliance rules
are set by government regulation or federal program requirements and appear as locked,
read-only toggles (with a shield icon) on the Program Rules page for program managers.
Uncovered compliance rules block workflow publishing as errors. Managed via the
compliance.rules.manage permission with effective dating and audit trail.
A rule field classified as a business decision that programs can adjust freely. Program
managers with program_rules.edit can toggle business rules on or off as needed. Uncovered
business rules produce warnings (not errors) in the Workflow Studio Rules Coverage Panel
and do not block publishing.
The designation applied to each rule field in programRuleVersions indicating whether the
rule is compliance-mandated or a business decision. Stored in the compliance_rule_definitions
table with effective date, created-by user, and classification reason. Determines toggle
editability on Program Rules and publish-blocking severity in Workflow Studio.
The mechanism by which Globus ensures rules and compliance requirements are met before
allowing state transitions. Prevents non-compliant actions at the system level.
A request to extend a participant’s program duration beyond the original end date
on the *same* DS-2019. Subject to duration validation, SEVIS amendment triggers,
season boundary rules, and carry-forward logic. Program Extensions modify the existing
program timeline without creating a new application or restarting the lifecycle. Not to be
confused with **Reservation Extension**.
A partner’s request to extend a time-limited hold on a job position (capped at RESERVATION_RULES.MAX_EXTENSION_DAYS = 4 days, one extension per host-applicant). Has no impact on SEVIS or program duration. Subject to per-type
extension caps and sponsor approval above the auto-approve threshold. See Partner Governance
— Reservation Rules.
A re-application for a new program season after completing a previous one. Unlike Program
Extensions (which modify the current timeline on the same DS-2019), Program Renewals create
a new application record in the target season with a new DS-2019. Eligibility is evaluated
based on completion status of the prior program and program-specific renewal rules. Document
renewals (insurance, licenses) and agreement renewals (partner / host agreements) are
separate concepts.
The difference between applicants ready for placement and available job order positions, calculated
per program, season, and skill category. A positive gap indicates oversupply; negative indicates undersupply.
The authoritative list of rule types the eligibility engine recognises, each with a typed
parameter schema, a canonical resolved shape, and a documented default-fallback that
matches the legacy `programRuleVersions` reader byte-for-byte. Lives in
`shared/schema.ts` as `RULE_TYPE_CATALOG`. Expanded under task #197
to unblock cutover ticket #209.
A scoped operational threshold (e.g. SEVIS cadence numbers, sponsor capacity, escalation
day numbers) that follows the same brand → program → season scoping as authorable
rules but is exposed via the settings surface, not the Rule Builder. Distinguished from
authorable rules in the Rule-Type Catalog by `classification = "engine_setting"`.
A deterministic, pure function (one per rule type, registered in
`NEW_CANONICALIZERS`) that the cutover parity script uses to compare the legacy
`programRuleVersions` reader output against the new resolved snapshot. The
guard test `LEGACY_RULE_KEYS_WITH_CANONICALIZERS` fails the build if a legacy
key is added without a matching canonicalizer.
The automatic publication of structured operational events into the Event Outbox when a capacity
threshold is crossed. Auto-publish creates awareness and triggers downstream actions without
blocking intake or altering application flow.
## Architecture & Development

A classification assigned to each API endpoint indicating its maturity and change policy.
Tiers include stable (no breaking changes), beta (may change with notice), alpha (expect changes),
internal (Globus-only), and deprecated (scheduled for removal).
A URL-safe, globally unique identifier for a sponsor brand (e.g., “alliance-abroad”).
Used for portal routing, white-label URL resolution, and brand-specific theming via the bootstrap context.
A brand's human-readable `name` is globally unique alongside its slug. Comparison is
whitespace- and case-insensitive at the application layer (the normalizer trims and case-folds
before the pre-flight check), so “Alliance Abroad” and “alliance abroad” collide. See
Program Register → Brands — Global Uniqueness
for the full contract and 409 payload.
A program's `name` is unique *within its brand*, not globally — two brands can each
run a “Camp Counselor” program. Enforced by a partial unique index on
`(brand_id, lower(trim(name)))` with the same whitespace/case-fold normalization. See
Program Register → Programs — Brand-Scoped Uniqueness
A program-scoped, lowercase snake_case identifier derived from a season's name by
`deriveSeasonKey()`: lowercase, non-alphanumeric runs collapse to `_`, edge
underscores trim. “Summer 2026 — Pilot” → `summer_2026_pilot`. Unique per
`(program_id, season_key)`. See
Program Register → Seasons — Program-Scoped Uniqueness
Google Cloud Build — the former CI/CD pipeline for Globus services; building, testing and deploying now run in GitHub Actions (deploy-feature-request.yml / trusted-deploy-dev.yml, deploy-release-qa.yml and deploy-prod-bluegreen.yml since the 2026-10-06 move to the sandbox branching model; deploy-development.yml, deploy-qa.yml and deploy-production.yml are disabled). The cloudbuild-*.yaml files remain in the repo.
A Domain-Driven Design bounded context within the Globus codebase. Each module maps to one
capability layer and contains its own routes, services, repositories, and domain models.
Cross-module communication uses domain events, not direct imports.
The formal state progression for seasons: draft → open → active → closing →
closed → archived. Transitions are system-enforced and determine what operations are
permitted at each stage.
The machine-readable API specification standard used by Globus. Auto-generated from route
definitions and Zod schemas. Drives client SDK generation, documentation, and CI validation.
A JSON configuration object defining portal-specific styling: header background, sidebar background,
button style (rounded/square/pill), and font family. Served via the bootstrap context so portals
render brand-specific visual identity without hardcoding.
The maximum number of participants a season can accept. When capacity is reached, new applications
are either waitlisted or rejected depending on program configuration.
A capability domain in the Globus architecture. The system is organized into 10 layers (0–9),
each responsible for a distinct concern: identity, programs, seasons, applicants, workflows,
rules, job orders, matching, communications, and automation. Lower layers must stabilize
before upper layers can safely build on them.
A project-level checkpoint that marks when all tasks in a project are complete and the
capability is production-ready. Each numbered project in the Globus roadmap (P1, P2, P3, …)
has a gate milestone that must pass before dependent projects can proceed.
The catalog of reusable step definitions that make up application workflows. Each step
defines content (forms, uploads, instructions), visibility rules, and completion criteria.
Steps are composed into program workflows via the Workflow Builder.
The configuration interface for composing application journeys. Combines steps from the
Step Library into ordered workflows with phases, milestones, and conditional visibility.
Defines how applicants move through each program.
An entity-agnostic operational work queue that assigns tasks to staff members with priority,
SLA tracking, and claim/release mechanics. Supports any entity type (applicants, partners,
job orders, housing) and includes bulk actions, facet filtering, export, and inline row actions.
The operational model defining a partner’s capabilities and autonomy level. Three models
exist: Standard (basic recruitment), Managed (sponsor-controlled operations), and Regional
Operator (delegated authority with expanded capabilities). The model determines which
features and data a partner can access.
The linkage between a participant and their accommodation during the program. Covers host
family placements, dormitory assignments, and independent housing with compliance tracking
for safety inspections and suitability standards.
A central registry in Globus that tracks all AI-powered features with their status,
configuration, versioning, and feature flags. Capabilities include document extraction,
text review, and translation assist. All AI outputs are advisory — no autonomous
decisions affect applicant lifecycle or compliance status.
A versioned, database-stored template used to render notification content. Templates support
dynamic variable interpolation, brand-specific overrides, and channel-specific formatting
(email, SMS, in-app, Slack). Templates are managed through the Globus admin interface
without code deployments.
The mechanism by which a participant’s record transitions across season boundaries during
an extension. The original season record is completed with a carry-forward flag, a new
record is created in the target season linked via carry_forward_from_id, and placement,
compliance history, and SEVIS linkage are preserved.
## Finance & Billing

Determines who pays for an application’s charges. Values include SELF_PAY (applicant pays directly),
DDP (Deferred Payment Plan), PARTNER_PAYS (partner collects and remits), SPONSOR_PAYS (sponsor absorbs cost),
and SPLIT (charges divided between multiple parties). Stored as a DB-driven lookup.
The aggregate payment status of an application. DB-driven values include NOT_BILLABLE_YET, INVOICED,
PARTIALLY_PAID, PAID, OVERDUE, ON_HOLD, and WAIVED. Displayed in portals and admin views.
A DB-driven table of all fee types the organization can issue (program fee, SEVIS fee, insurance,
housing deposit, extension fee). New fee types are added as database rows, not code changes.
The external financial system of record. Owns invoices, payments, refunds, credit memos, and accounting
journals. Globus triggers financial events; NetSuite handles all accounting truth.