---
title: "Applicant Portal — My Documents & Resources"
slug: applicant-portal-surfaces
section: Applicant Journey
status: draft
description: "The Applicant Portal renders two content surfaces — My Documents and Program Resources."
last-updated: 2026-06-19
---

# Applicant Portal — My Documents & Resources

# Applicant Portal Surfaces — Globus Source of Truth

The Applicant Portal renders two content surfaces — My Documents and Program Resources. This page is the single normative statement of what each surface shows and, more importantly, who decides what is shown. The answer for both is the same: Globus decides, the portal renders. The portal holds no hard-coded list of documents or resources — it presents exactly what Globus supplies for the applicant’s program, season, lifecycle stage, and rule outcomes.

> **Architecture Principle — Globus decides, the portal renders**
>
> The Applicant Portal does not decide what documents or resources to show. It is a rendering surface. Globus — through Workflow Studio, the Rules Engine, Document Management, and the Resource Library — computes the authoritative set of document slots and program resources for each applicant based on their program, season, lifecycle stage, and rule outcomes, and the portal renders that set faithfully. Any list baked into portal code is a bug, not a contract.

## Architecture Principle

Every surface in the applicant experience is downstream of Globus configuration. Two consequences follow, and they apply to both surfaces on this page:

- No portal-side catalogs. The portal must not maintain its own list of “documents a J-1 needs” or “resources to show before departure.” Those lists are resolved server-side and delivered to the portal per request.

- Content changes without portal deploys. Because the lists come from the published workflow version, the active rule bundle, and the Resource Library, a program admin can change what an applicant sees by editing configuration — not by shipping portal code.

- Same applicant, different surface over time. As the applicant advances through lifecycle stages, slots and resources appear or unlock. The portal re-renders whatever Globus currently resolves; it does not gate stages itself.

## The Two Surfaces

My Documents

Documents and evidence the applicant provides (plus sponsor-issued artifacts they receive), with per-document review status.

Source of truth: Globus via Workflow Studio, Rules Engine, and Document Management.

Program Resources

Program-published handbooks, orientation videos, insurance information, and placement information packs — read-only for the applicant.

Source of truth: Globus Resource Library, configured by Program, Season, and Lifecycle Stage.

## My Documents

“My Documents” is the applicant-facing view of the documents and evidence tied to their participation. It is a rendering of the document slots Globus has determined this applicant must satisfy, plus any sponsor-issued artifacts they receive. The applicant uploads, re-uploads rejected items, and downloads issued documents — but the slot list itself is owned by Globus, not the portal.

### The Document Set

The full set spans applicant-uploaded evidence, sponsor-issued artifacts, and the existing database-driven categories. Which of these appears for any given applicant is resolved from their program, season, stage, and rule outcomes — this is the superset, not a checklist every applicant sees.

| Document | Owner | Scope | Notes |
| --- | --- | --- | --- |
| doc | | scope | notes |

_(row above is a template, repeated for each data row)_

> **Owner is not the same as uploader**
>
> Most documents are applicant-owned and applicant-uploaded, but the DS-2019 is Globus-issued — the applicant receives and downloads it, never uploads it. Signed contracts are co-owned: Globus presents the agreement and captures the signed artifact. The portal must render an upload affordance only for slots the applicant is responsible for providing.

### Governing Globus Systems

Three Globus systems jointly determine the My Documents surface. None of this logic lives in the portal:

### Carried-Forward Schema Gap

> **No applicant-scoped documents table — reported, not solved**
>
> The conceptual “My Documents” surface implies identity-bound documents that follow the person across re-applications. Today they do not. The documents table requires applicationId (.notNull()), so every document is bound to a single application attempt. There is no applicant_documents table backing the identity-bound design, so passport scans and other identity artifacts cannot be reused across attempts without manual recopy. This page documents the surface honestly: the gap is carried forward, not closed. See the audit on Applicant vs Application Data and the storage callout on Document Storage .

## Program Resources

“Program Resources” (the Resource Library surface) is the applicant-facing view of program-provided reference material — content the program publishes to the applicant rather than collecting from them. Unlike My Documents, this surface is read-only for the applicant: there is no upload, no review state, only consumption.

### Resource Types

| Resource Type | Description | Example |
| --- | --- | --- |
| type | desc | example |

_(row above is a template, repeated for each data row)_

### Globus Resource Library

The source of truth for Program Resources is the Globus Resource Library — a program-managed catalog of resources. The portal queries Globus for the resolved resource set and renders it; it does not host, version, or curate resource content. As with documents, access to resource files flows through Globus-signed, short-lived proxy URLs — the portal never receives a raw storage path.

> **Surface contract here — deeper engineering spec on its own page**
>
> This page establishes the surface-level contract for Program Resources: what the surface shows and that the Resource Library is its source of truth. The deeper engineering spec — the Resource Library data model, the admin authoring surface programs publish through, versioning, and the Program/Season/Lifecycle-Stage keying — lives on Globus Resource Library .

### Configured by Program, Season & Stage

The Resource Library is keyed on three axes. The same applicant sees a different resource set as any of them change:

## Rendering Contract

For each surface the division of responsibility is explicit: Globus supplies the resolved, authoritative set and all access tokens; the portal renders that set and handles the user interaction. The portal never substitutes its own judgement for Globus’s.

### My Documents — Supplies vs Renders

| Globus supplies | Portal renders / is responsible for |
| --- | --- |
| globus | portal |

_(row above is a template, repeated for each data row)_

### Program Resources — Supplies vs Renders

| Globus supplies | Portal renders / is responsible for |
| --- | --- |
| globus | portal |

_(row above is a template, repeated for each data row)_

### Conditional-Rendering Inputs

Both surfaces are driven by the same four inputs. These are the only things that change what an applicant sees — and all four are evaluated by Globus, not the portal:

## Related Pages
