---
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-10-07
---

# Applicant Portal — My Documents & Resources

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.

> **Content gap — unauthored lists and tables**
>
> The conversion of this page left several lists and tables as empty templates. The Document Set, Resource Types and both Supplies-vs-Renders tables hold a single placeholder row, and the lists under Governing Globus Systems, Configured by Program, Season & Stage, Conditional-Rendering Inputs and Related Pages are empty. The principles and the status split above are authoritative; the missing enumerations still need their owner to author them. For the live My Documents routes see [Applicant Portal Endpoints](/docs/applicant-portal-endpoints).

> **Status split (verified 2026-07-04): My Documents LIVE — Program Resources DESIGN-ONLY**
>
> My Documents is live and now fully Globus-backed. As of BOP PRs #1310/#1312/#1313 (header-authenticated portal document routes) the PPPToo controller (documents.controller.ts, JWT-guarded) proxies list, required-documents catalogue, upload (images up to 10MB, documents up to 20MB; PDF/DOC/DOCX and JPEG/PNG/GIF/WebP/HEIC/HEIF), versions and download straight to Globus with ownership enforced server-side; the interim GCS store survives only as a read fallback for legacy ppp2/ document ids. List items carry id, fileName, documentType (default 'general'), status (default 'pending_review'), downloadUrl, createdAt, official, rejectionReason; skill certifications post documentType='skill-certification' (AP-5). Note the portal's real status vocabulary — the Missing/Uploaded/Verified/Rejected/Expired chip set described below is the design intent, not the wire values. Official documents (PPPToo #319, #378, verified at development HEAD): the BFF list omits any DS-2019 (documentType 'ds-2019') whose status is not 'verified', marks a verified DS-2019 official, and returns downloadUrl as an authenticated BFF path only when Globus supplied a same-origin /api/portal/documents/:id/download path (otherwise null). The download route re-reads the applicant's own list, validates that exact path and streams it; an absent document, an unverified DS-2019 and an upstream 404 all return the same 'Document unavailable' 404. The Documents page shows 'Official program documents' in labelled groups — DS-2019 (View / Download, or 'Your DS-2019 is not available yet.'), Signed agreements (signed-agreement and terms-acceptance rows, or 'No signed agreements are available yet.'), and Other official documents (only when present). Signed-agreement rows show a readable display title derived from the filename (e.g. Camp Counselor Participant Agreement) with the original filename kept as the hover title and the download filename, plus a status pill (an unrecognised status shows 'Status unavailable'); a row with no download URL shows no View/Download actions. Globus now also supplies presentation metadata for these rows (BOP #2429, verified at development HEAD in server/services/portalDocumentProjection.ts): GET /api/portal/applications/:appId/documents (and documents-by-step) returns displayName ('Signed Agreement' for the signed-agreement type, 'DS-2019' for ds-2019) and presentationGroup 'official-program-documents' on those rows, where Globus's official flag stays true only for signed agreements (with createdAt set to the acceptance's signing date) and is false for DS-2019; Host Agreement classification is unchanged. Program Resources has no backend: PPPToo has no resources controller and the backing Globus Resource Library is entirely unbuilt — treat that half of this page as target-state.

> **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. The portal shows a DS-2019 only once it is verified; an unverified DS-2019 is neither listed nor downloadable. 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. Issuance timing is governed host-side: the DS-2019 slot stays unissued while the placement host fails the issuance guard — for camp placements that includes hosts still pending verification (refused with 403 `HOST_VERIFICATION_REQUIRED` even though the host is otherwise operational). The portal simply renders the slot as not-yet-issued; the gate itself is specified on Host Portal Governance → Operating Agreement (DS-2019 Guard) and Camp Program Divergence.

### 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 (applicant_documents) requires applicationId (.notNull()), so every document is bound to a single application attempt. There is no person-level 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