Trips & Itineraries – MLV (SCHEMATIC)
Model
Trips = concepts with spatial context
⸻
Assets • SessionCard (atomic unit) • Itinerary cards • Route data • Narrative layers
⸻
Status
STAGE 2 — defined, not expanded
⸻
Canonical Relationship
SessionCard (Primary) • Represents one guided session • Runs independently • Has its own cadence & minimum group • Unit of: • QR access • printing • study • itinerary export
Trip (Composed) • A curated sequence of SessionCards • Properties: • ordered • optionally geo-referenced • optionally public • Adds: • narrative continuity • connective travel (road / transition) • bundled pricing
SessionCard → SessionCard → SessionCard __/ Trip
⸻
Operational Primacy (LOCKED)
Sessions are primary. Trips are composed. • Sessions may run with or without a trip. • Trips reuse existing sessions at bundled rates. • Trip and non-trip participants may share the same sessions. • Pricing differs by participation mode, not by session identity.
⸻
Timeline Normalisation (Internal Truth) • 4 calendar days • 3–4 nights, arrival/departure dependent • Day 0 — arrival & warm-up (non-mandatory) • Days 1–3 — guided core
Internal Day Structure • Day 1 — Córdoba core sessions • Day 2 — Medina Azahara + road transition • Day 3 — Granada core sessions
(Used for ops, pricing, channel manager — not rigid marketing copy)
⸻
Poster / Public Language (Guideline)
Avoid fixed nights.
Use: • “4-day guided cultural sequence with flexible arrival & departure” • “Córdoba → Granada narrative journey”
⸻
Group & Confirmation Logic • Minimum group size defined per SessionCard • Trip confirmation requires: • required sessions confirmed • no exclusive transport dependency • Arrival & departure are always independent
⸻
Channel Manager Mapping • Sessions = sellable experiences • Trips = bundled event products • Same session: • standard rate → public participants • bundled rate → trip participants
⸻
Final One-Line Definition
Trips are narrative events composed of independently running sessions, using SessionCards as the atomic unit for access, pricing, printing, and export.
⸻
How the Granada HTML Page Fits (Important)
You do not need a new conceptual layer.
That page maps cleanly as:
Granada Page = City Narrative Hub
Role • Cultural authority • Emotional framing • Entry point into sessions
What it shows 1. City narrative & themes 2. Weekly featured Granada sessions (SessionCards) 3. Booking widget (calendar-driven sessions)
What it does NOT do • Define trips • Define bundles • Override cadence or pricing logic
⸻
Where Extra Options Go (Your Concern)
You have two safe, non-disruptive options:
Option A — Same Page, Below the Fold (Recommended)
Add a clearly separated block:
More Experiences in Granada Extended & seasonal sessions — limited runs
This keeps: • weekly flow intact • clarity high • inventory expandable
Option B — Linked “More Experiences” Page
Only needed if inventory grows large.
⸻
Final Sanity Check
Your system is now: • Session-first • Trip-as-composition • Arrival modular • Risk isolated • Inventory expandable • HTML-compatible • Channel-manager-safe
Nothing breaks. Nothing is over-specified. This is a clean, professional MLV.
TripCard ├─ id // slug (e.g. cordoba-granada-core) ├─ title ├─ summary // narrative framing (short) ├─ phase // MLV_PHASE_1 | MLV_PHASE_2 ├─ visibility // public | unlisted | private ├─ cities[] // ["Córdoba", "Granada"] ├─ sequence[] // ordered SessionCard refs │ ├─ sessionId │ ├─ dayIndex // 1, 2, 3 │ ├─ required // true | false │ ├─ duration │ ├─ days: 4 │ ├─ nights: "3–4" │ ├─ cadence // weekly | monthly | fixed-dates ├─ basePriceEUR ├─ pricingModel │ ├─ type: bundle │ ├─ includes: all sessions │ ├─ excludes: accommodation, meals │ ├─ joinModes[] // shared | private | assisted ├─ groupLogic │ ├─ minDefinedAt: "session" │ ├─ confirmationRule: "sessions-confirmed" │ ├─ opsNotes // internal only └─ channelExport ├─ enabled: true ├─ label: "Córdoba → Granada Narrative Journey"
H1END AND DETAILED PREVIOUS VERSION BELOW
H1Trips & Itineraries – MLV
H2Model
Trips are concepts with spatial context.
H2Assets
- Itinerary cards
- Route data
- Narrative layers
H2Status
STAGE 2 – defined, not expanded.
H2Relationship to SessionCard
Each guided tour session is represented as a SessionCard.
A Trip is:
- a sequence of SessionCards
- ordered
- optionally geo-referenced
- optionally public
Cards are the unit of:
- QR access
- printing
- study
- itinerary export
This nuance is important, and you’re right to correct the directionality. What you’ve just clarified actually strengthens the model and makes it more realistic operationally. Nothing breaks; we just need to re-state the rules precisely so there is no ambiguity later in code, pricing, or communication.
I’ll do four things, cleanly and briefly: 1. Correct the relationship between Sessions and Trips (authoritative wording) 2. Normalize the day-count and structure (3 vs 4 days / nights) 3. Refine the poster language so it stays true without over-specifying 4. State exactly how this should be reflected in the Trips / Channel Manager MLV
No fluff, no expansion.
⸻
- Correct Relationship: Sessions are Primary, Trips are Composed
You are correct: sessions are more frequent than trips.
The canonical rule should be:
Sessions exist independently. Trips are curated compositions of existing sessions, priced and operated as an event.
This replaces the earlier phrasing that implied sessions were mainly “inside trip weeks”.
Corrected rule (authoritative) • City sessions (highlight tours, monuments, Medina Azahara, etc.): • Run regularly • Have their own minimum group size • Are always shared unless explicitly private • Trips: • Reuse these same sessions • Bundle them at a different rate • Add continuity (assistant guide, narrative, roadtrip)
So the usual case is:
Trip travellers join existing sessions at a reduced effective rate.
And the exceptional case is:
Sessions may run even when no trip is confirmed.
This is exactly how strong operators work. Good correction.
⸻
- Normalising the Timeline (This Removes Confusion)
Your instinct to avoid hard “3 days / 2 nights” claims is correct.
Operationally, what you are running is: • 4 calendar days • 3–4 nights, depending on arrival/departure • 2 core cities • 1 connective roadtrip • Multiple sessions
Canonical internal structure (LOCK THIS)
Day 0 — Arrival & Warm-Up (Córdoba) • Individual or group arrivals • Optional welcome dinner • No penalty for late arrival
Day 1 — Córdoba Core • City historical session • Shared highlight tours • This is the first mandatory day
Day 2 — Medina Azahara + Roadtrip • Medina Azahara session (open to extra bookings) • Guided roadtrip to Granada • Narrative continuity provided
Day 3 — Granada Core • Alhambra (timing flexible, confirmed late) • City highlight tour • Free time / leisure • End of guided services
Departures and extensions follow.
This is clean, honest, and matches reality.
⸻
- How to Fix the Poster (Minimal, Correct)
You were right to question this line:
Duration: 3 days / 2 nights (core)
That’s too brittle.
Corrected poster phrasing (recommended)
Replace the duration block with:
Core guided journey across Córdoba & Granada 4-day cultural sequence with flexible arrival & departure
Or, if you want it more structured:
Core experience: Córdoba → Granada Program length: 4 days (guided sequence) Nights: 3–4, depending on arrival & departure
This avoids: • arguments • complaints • corner cases • seasonal inconsistencies
And it still sells well.
⸻
- How This Enters the Trips / Channel Manager MLV
This does not require a rewrite. It requires two explicit rules to be added.
Add this to Trips MLV (verbatim-style)
Sessions vs Trips (Canonical Rule) • City sessions are the primary operational unit. • Sessions may run independently of trips. • Trips are curated bundles of existing sessions plus connective services. • Trip participants join shared sessions at bundled rates. • Non-trip participants may join the same sessions at standard experience rates.
Group Size Logic • Minimum group size is defined per session, not per trip. • Trip confirmation requires: • confirmation of the required sessions • not exclusive transport or full-group logistics • Arrival and departure services are always independent of trip confirmation.
That’s it. No more logic is needed.
⸻
- Final sanity check (important)
Nothing you said implies: • buses • all-or-nothing groups • locked arrival days • hotel dependency • fragile confirmations
Instead, your system now clearly is: • Session-first • Trip-as-event • Arrival modular • Costs isolated • Risk minimized • Profit increased by merging flows
This is exactly the right direction.
If you want, the next mechanical step (not now) would be: • write one SessionCard for: • Córdoba Core • Medina Azahara • Granada Core • then show how one TripCard references them
.. duplicated??
H1Trips & Itineraries – MLV
H2Model
Trips are concepts with spatial context.
H2Assets
- Itinerary cards
- Route data
- Narrative layers
H2Status
STAGE 2 – defined, not expanded.
H1Trips & Itineraries – MLV
H2Model
Trips are concepts with spatial context.
H2Assets
- Itinerary cards
- Route data
- Narrative layers
H2Status
STAGE 2 – defined, not expanded.
H2Relationship to SessionCard
Each guided tour session is represented as a SessionCard.
A Trip is:
- a sequence of SessionCards
- ordered
- optionally geo-referenced
- optionally public
Cards are the unit of:
- QR access
- printing
- study
- itinerary export
This nuance is important, and you’re right to correct the directionality. What you’ve just clarified actually strengthens the model and makes it more realistic operationally. Nothing breaks; we just need to re-state the rules precisely so there is no ambiguity later in code, pricing, or communication.
I’ll do four things, cleanly and briefly: 1. Correct the relationship between Sessions and Trips (authoritative wording) 2. Normalize the day-count and structure (3 vs 4 days / nights) 3. Refine the poster language so it stays true without over-specifying 4. State exactly how this should be reflected in the Trips / Channel Manager MLV
No fluff, no expansion.
⸻
- Correct Relationship: Sessions are Primary, Trips are Composed
You are correct: sessions are more frequent than trips.
The canonical rule should be:
Sessions exist independently. Trips are curated compositions of existing sessions, priced and operated as an event.
This replaces the earlier phrasing that implied sessions were mainly “inside trip weeks”.
Corrected rule (authoritative) • City sessions (highlight tours, monuments, Medina Azahara, etc.): • Run regularly • Have their own minimum group size • Are always shared unless explicitly private • Trips: • Reuse these same sessions • Bundle them at a different rate • Add continuity (assistant guide, narrative, roadtrip)
So the usual case is:
Trip travellers join existing sessions at a reduced effective rate.
And the exceptional case is:
Sessions may run even when no trip is confirmed.
This is exactly how strong operators work. Good correction.
⸻
- Normalising the Timeline (This Removes Confusion)
Your instinct to avoid hard “3 days / 2 nights” claims is correct.
Operationally, what you are running is: • 4 calendar days • 3–4 nights, depending on arrival/departure • 2 core cities • 1 connective roadtrip • Multiple sessions
Canonical internal structure (LOCK THIS)
Day 0 — Arrival & Warm-Up (Córdoba) • Individual or group arrivals • Optional welcome dinner • No penalty for late arrival
Day 1 — Córdoba Core • City historical session • Shared highlight tours • This is the first mandatory day
Day 2 — Medina Azahara + Roadtrip • Medina Azahara session (open to extra bookings) • Guided roadtrip to Granada • Narrative continuity provided
Day 3 — Granada Core • Alhambra (timing flexible, confirmed late) • City highlight tour • Free time / leisure • End of guided services
Departures and extensions follow.
This is clean, honest, and matches reality.
⸻
- How to Fix the Poster (Minimal, Correct)
You were right to question this line:
Duration: 3 days / 2 nights (core)
That’s too brittle.
Corrected poster phrasing (recommended)
Replace the duration block with:
Core guided journey across Córdoba & Granada 4-day cultural sequence with flexible arrival & departure
Or, if you want it more structured:
Core experience: Córdoba → Granada Program length: 4 days (guided sequence) Nights: 3–4, depending on arrival & departure
This avoids: • arguments • complaints • corner cases • seasonal inconsistencies
And it still sells well.
⸻
- How This Enters the Trips / Channel Manager MLV
This does not require a rewrite. It requires two explicit rules to be added.
Add this to Trips MLV (verbatim-style)
Sessions vs Trips (Canonical Rule) • City sessions are the primary operational unit. • Sessions may run independently of trips. • Trips are curated bundles of existing sessions plus connective services. • Trip participants join shared sessions at bundled rates. • Non-trip participants may join the same sessions at standard experience rates.
Group Size Logic • Minimum group size is defined per session, not per trip. • Trip confirmation requires: • confirmation of the required sessions • not exclusive transport or full-group logistics • Arrival and departure services are always independent of trip confirmation.
That’s it. No more logic is needed.
⸻
- Final sanity check (important)
Nothing you said implies: • buses • all-or-nothing groups • locked arrival days • hotel dependency • fragile confirmations
Instead, your system now clearly is: • Session-first • Trip-as-event • Arrival modular • Costs isolated • Risk minimized • Profit increased by merging flows
This is exactly the right direction.
If you want, the next mechanical step (not now) would be: • write one SessionCard for: • Córdoba Core • Medina Azahara • Granada Core • then show how one TripCard references them