Adaptive Experiences
Submission Architecture
Adaptive Experiences
This document answers a specific question visitors naturally ask: "Are these just five different prompts?" The answer is no — and this page explains why.
The Problem This Solves
Adaptive Experiences only works if every perspective begins from the same place. If one perspective receives "loves live entertainment" and another receives "likes shows," those are already different starting points. The perspectives diverge before they've done any thinking — and the differences in their outputs reflect the prompt, not the perspective.
The submission architecture exists to prevent that. Its job is not to interpret the situation. Its job is to preserve it faithfully, so that every perspective receives an equivalent foundation before it begins.
Four Layers
Every Adaptive Experience submission is structured into four layers. These are extracted from the user's situation — not invented, not inferred, not improved.
1. Scenario
What is happening? The scenario captures the basic situation in neutral terms.
Example: Three adults visiting EPCOT during the Food & Wine Festival, rope drop to close.
The scenario is not a goal. It does not say what a good day looks like. It describes the situation that exists before any perspective has thought about it.
2. Participants
Who matters, and what do we know about them? Participants are described by the observations the user provided — not by inferences the architecture made.
Example:
Three adults. One has visited EPCOT many times. One dislikes motion-intensive and spinning rides; Remy's causes motion sickness. One loves aquariums. All three enjoy live entertainment.
These are observations, not judgments. The architecture does not infer fitness level, personality, budget, family dynamics, or previous experience beyond what the user stated. If it wasn't said, it isn't in the packet.
3. Constraints
What cannot change? Constraints become the physics of the problem — the boundaries every perspective must work within.
Example:
• Rope drop to close
• No dining reservations
• One person cannot do spinning rides or Remy's
• All three willing to use Lightning Lane
• Food and Wine Festival is the primary context
Constraints are not negotiable. A perspective that ignores a constraint has failed the exercise, not solved it differently.
4. Priorities
How does the user define success? Priorities are the hierarchy the submission preserves — because different priorities produce legitimately different solutions, and that divergence is the point.
Example priority order:
1. Great shared day for all three
2. Food and Wine Festival experience
3. Aquarium time for the person who cares about it
4. Live entertainment
5. Efficient ride coverage
A perspective that weights the aquarium above everything else is not wrong — it's operating from a different priority order than the one the user provided. The submission architecture makes that priority order explicit so every perspective is working from the same hierarchy.
What the Architecture Deliberately Excludes
The submission architecture does not infer what isn't stated. It does not add:
- Age, fitness, or mobility assumptions
- Budget estimates unless the user specified willingness to spend
- Personality or family dynamic readings
- Previous Disney knowledge beyond what was described
- Preferences the user didn't mention
This is the hardest part of the architecture to maintain. The temptation is to fill in gaps — to assume that three adults at Food and Wine Festival probably want to drink, or that someone who loves aquariums probably wants to move slowly through the park. Those may be reasonable guesses. They are still guesses, and the submission architecture doesn't make them.
The design principle is simple: preserve what is true, avoid inventing what wasn't said.
The Normalized Submission Packet
After the four layers are extracted, they're assembled into a normalized submission packet — the same document handed to every perspective before any writing begins.
Here is the actual packet used for the EPCOT Food and Wine experience:
Scenario: Three adults, EPCOT, Food and Wine Festival, rope drop to close.
Participants: Three adults. One highly experienced with EPCOT. One cannot do spinning rides or Remy's Ratatouille Adventure (motion sickness from motion plus 3D). One has a strong interest in aquariums. All enjoy live entertainment.
Constraints: Rope drop start. Close of park end. No dining reservations. No spinning rides for one participant. Remy's excluded. Lightning Lane available. Food and Wine Festival is the primary experience context.
Priorities: Shared great day. Food and Wine Festival. Aquarium experience. Live entertainment. Efficient ride coverage.
Every perspective — Harbor, Bo Ra, Nam, Min, Jae — received this packet and nothing else before generating their approach. The differences in their recommendations reflect differences in what they value, not differences in what they were told.
Why This Matters
The submission architecture is what makes Adaptive Experiences something other than five different prompts. Without it, each perspective would receive a slightly different version of the situation, shaped by whoever wrote the prompt that day. The outputs would be inconsistent — and the differences between perspectives would tell you more about prompt variation than about genuine perspective divergence.
With a normalized submission, the differences become meaningful. When Harbor and Min reach opposite conclusions about how to structure the afternoon, that divergence is a real signal — not an artifact of different inputs.
The submission architecture doesn't solve the problem. It describes the problem faithfully, so that five different kinds of thinking can each solve it in their own way.
What Comes Next
The companion document, Response Architecture, explains what happens after the normalized packet is handed to each perspective — how each voice processes the same information differently, what each one is optimizing for, and how the Final Synthesis integrates the outputs without flattening what made each perspective distinct.
Together, these two documents form the structural backbone of how Adaptive Experiences works.