SHOREX · DATA ADAPTOR

Wire sources, map data, see how it flows

The IT-side tool for connecting shore excursion source systems to the canonical data model. Adaptor setup at the top — connections and cell mapping. Below, follow one excursion through its lifecycle to see why the model is shaped the way it is.

v1 · mockup, not built ⓘ
01
ADAPTOR · sources, mapping, entities, fields

Interface connections, model, and field detail

Source connections (01A) feed the canonical model (01C) via field-level mappings (01D); the matrix (01B) wires each track × stage cell to a source.

01A · CONNECTIONS Source systems wired up for this tenant · health, role, contributed entities

Source systems shown here are for tenant solstice. Full adapter operations — reconciliation queue, dead-letter, canonical entity browser — live in the standalone shorex-adaptor/ page.

01B · CELL MAPPING Click a cell to inspect; matrix wires each track × stage to a source connection from 01A
Data sources
Global defaults · all ships, all seasons
Dispatch Tour Day
FIDELITY LADDER reaches Operating
SOURCES (PRIORITY ORDER)
35 cells · 14 with fallback sources
01C · CANONICAL ENTITIES The schema the adaptor produces · each entity has one authoritative source · Ring 1 (day one) → 2 (differentiator) → 3 (advanced)
01D · FIELD MAPPING One example: MXP → tour_instance · each (source × entity) pair has its own mapping
MXP → tour_instance 13 fields · 11 mapped, 2 source-limited

The Adaptor above wires the cells. To see why the model is shaped this way, follow one excursion from catalog to settlement — what each track records, how often it changes, and which phase it sits in.

02
FOLLOW ONE TOUR · one excursion, catalog to settlement

How one tour moves through its lifecycle

Four beats in the life of a single excursion. Each beat shows the phase it's in, how often its data changes, and what each of the five tracks records. Below, the same lifecycle drawn as nested phases.

02A · STORYBOARD One excursion, catalog → settlement · phase color · how often each step changes
1 season → many voyages → many tour days → departures → bus-level dispatch
02B · NESTING The same lifecycle, nested by phase — Season outermost, settlement last
Stages as nested object boxes with slim close-in and post-recon sections, colored by phase STAGE 1 · SEASON Season the planning horizon STAGE 2 · CLOSE-IN STAGE 3 · VOYAGE Voyage STAGE 6 · PR VOYAGE STAGE 4 · CLOSE-IN STAGE 5 · TOUR DAY Tour Day STAGE 6 · PR TOUR DEPARTURE Departure(s) bus-level dispatch units STAGE 7 · POST-CRUISE Post-Recon final settlement After all tour and voyage actuals are captured (slims to the left), final GL postings, credits, and loyalty close out the books. PHASE Pre-Cruise Operational Post-Cruise slim sections = transitional close-in (Stage 2/4) and per-level post-recon (Stage 6)

Mockup · for design discussion, not built · content mirrors content/*.md