---
title: "Overview"
slug: overview
section: Overview & Architecture
status: stable
description: "Multi-Brand Governance & Operating Model"
last-updated: 2026-10-07
---

# Overview

Multi-Brand Governance & Operating Model

## How to Read These Docs

Pick the trail that matches your question. Each row is ordered — read left to right.

| You want to… | Read, in order |
| --- | --- |
| Understand the whole system | Overview (this page) → Ecosystem Model → Architecture Diagram → Data Flows |
| Follow an applicant end-to-end | Applicant Lifecycle → PPPToo Architecture (as-built journey) → Applicant vs Application Data |
| Build against a portal API | Globus Portal API Reference → the portal's Endpoint Reference (Applicant / Host) → Integration Contract |
| Work on Globus internals | Capability Layers → Rules Engine → Queue System → Workflow Studio |
| Operate / debug the platform | Infrastructure & Environments → Automation (n8n) → Webhook Event Registry |
| Check delivery status | Delivery Overview → Project Status → Team & Capacity |

> **Agents: trust pages marked as-built over target-state**
>
> Where a page documents a target-state contract that differs from what runs today, it carries a status callout near the top (e.g. Direct vs Partner Entry). Implementation ground truth for the applicant intake lives on PPPToo Architecture and Globus Portal API Reference ; endpoint pages state their extraction date.

## Purpose & Scope

The Sponsor Ecosystem Architecture defines the unified operating model for all sponsor brands and systems. It establishes the governance structure, system boundaries, data flows, and role-based access controls across the full lifecycle — from recruitment and intake to placement, compliance, and program completion.

This architecture provides a scalable, multi-brand ecosystem that separates authority from experience layers, centralizes compliance within the Sponsor Core (Globus), and enables controlled distribution through applicant, host, and partner portals that integrate directly with Globus.

> **Extensible by Design**
>
> This architecture is intentionally extensible, allowing future expansion into finance, reporting, analytics, and additional operational modules without architectural redesign.

## Globus Replaces Hanover

Globus is the new system replacing Hanover for managing Alliance Abroad program operations. Hanover is the legacy platform historically used to manage applicant, host, placement, and program records. Globus is the modern replacement — with updated workflows, improved data visibility, and a centralized, role-scoped experience for teams.

> **Use Globus as the source of truth going forward**
>
> New and ongoing work should be completed in Globus. Hanover should only be used for historical reference or specific legacy workflows when explicitly instructed. During the transition period, some historical information may still exist in Hanover, but it is no longer the place to manage active operations.

The two systems cover the same core business areas. The table below shows what each area looked like in Hanover and where that work happens now in Globus.

| Area | Hanover (legacy) | Globus (now) |
| --- | --- | --- |
| Applicants | Applicant profiles, program details, status tracking | Centralized applicant records and status management |
| Hosts | Host organization records and related details | Host profiles, locations, and related operational data |
| Placements | Placement and job-related information | Placement tracking and program coordination |
| Programs | Program participation and lifecycle tracking | Program workflows, participant progress, and operational reporting |
| Reporting | Older operational data and reference exports | Improved access to business data and aggregate insights |

### Transition Rules

Enter new applicant, host, placement, and program updates in Globus, not Hanover, unless there is a documented exception. / Use Hanover only to look up historical data, or for a specific legacy process that has not yet moved to Globus. / When a workflow exists in both systems, complete it in Globus. Hanover is no longer the system of record. / If a record is missing or conflicts between systems, treat Globus as authoritative and escalate the discrepancy to your team lead.
> **Data migration**
>
> Historical Hanover data may be retained for reference, migration, validation, or audit purposes. Where data has been migrated into Globus, Globus is authoritative; records that still require a Hanover lookup are the documented exceptions. Access to Hanover may still be required for some roles depending on the need for historical reference.

## Architecture Principles

The architecture is designed to scale across brands, programs, seasons, and future system expansions including finance, reporting, and analytics.

## Inviolable Laws

These rules are absolute and must never be violated by any agent or contributor. They define the non-negotiable boundaries of the platform.

## System Landscape

The ecosystem consists of core operational systems and supporting infrastructure layers.

### Core Systems

### Supporting Systems

## Tech Stack & Quality

The platform is built on a modern, tested, production-grade stack with rigorous quality gates enforced on every commit.

## Design Goals

> **Key Design Goals**
>
> The system must support multi-brand operations from day one. Each brand operates independently with its own programs, seasons, partners, and compliance rules — while sharing a unified platform for governance, reporting, and technology.

Establish Globus as the unified sponsor back office across all brands / Unify all sponsor operations under a single governance model / Support independent brand operations with shared infrastructure / Enable scalable partner recruitment across programs / Maintain SEVIS compliance across all J-1 programs / Provide executive-level visibility across the entire ecosystem
## Strategic Summary

This is not a CRM. This is a Global Sponsor Operating Platform with controlled external distribution networks — an ERP for J-1 sponsor operations.

Decoupled systems with clear boundaries / Centralized authority in a single core / Time-bound partner governance / Quota-based fairness controls / Post-SEVIS transition model / Field-level permission enforcement / No hardcoding / No annual duplication