ATLAS
Context-aware interfaces + governance
Atlas is an exploration of context-aware interfaces. I wanted to see how an interface could adapt as a traveler’s situation changed—and then understand what kind of governance was needed to keep those adaptations controlled, predictable, and explainable.
I used travel as the test case because the context can change quickly: preparation progress changes, the trip gets closer, or a flight is cancelled.
Launch Live Prototype ↗
Built with
React · TypeScript · Vite · Zod · Vercel
Starting With Context
Most interfaces ask people to navigate the same structure regardless of what is happening around them.
I wanted to explore a different model: what if the interface could respond to the current situation and change what it prioritized?
Atlas uses a small set of structured context signals:
trip timing
preparation progress
flight status
These signals live in the application state. Changing the flight-status dropdown, for example, does not simply send the user to another page. It updates the current context, triggers the rules again, and causes the interface to recompute what should be shown.
From Context To Interface
The prototype follows a simple flow:
TravelContext → rules → InterfaceSpec → validation → component registry → interface
The rules determine which experience state should take priority.
If the traveler is still preparing, Atlas keeps preparation tasks prominent. Once those tasks are complete, the experience shifts toward departure readiness. If the flight is cancelled, recovery information and actions become the priority while previously completed progress is preserved.
The result is an interface that changes because the underlying context changed, not because the user navigated to a different predetermined screen.
Then came the harder question
Once Atlas could change dynamically, I needed to answer a different question:
What keeps an adaptive interface from changing in ways I never intended?
That led to the governance layer.
Rather than allowing the prototype to render arbitrary UI, Atlas generates an InterfaceSpec describing the state, intent, sections, order, and decisions behind the interface.
Before anything renders, the specification is validated.
Each section must use an approved component and provide data that matches that component’s schema.
Launch Live Prototype ↗
Built with
React · TypeScript · Vite · Zod · Vercel
Governance As A Boundary
The component registry defines what Atlas is allowed to render. That boundary became useful while I was prototyping with Claude.
When the system reached flight and hotel information, none of the existing components were a good semantic fit. They were not tasks to complete or statuses to resolve; they were simply important trip details.
Instead of forcing the content into the closest available pattern, the mismatch was surfaced for a decision: use an existing approved component or deliberately extend the system.
I chose to add DetailCard, along with its schema and registry entry.
That changed how I thought about governance. It was not only about preventing unsupported output. It also created a deliberate path for the system to evolve when a new pattern was genuinely needed.
Testing the boundary
I also wanted to demonstrate what happens when the right answer is no.
The prototype includes a predefined request for an AirportMap.
Atlas can interpret the requested capability, but AirportMap is not part of the approved component registry.
The request is blocked and the last valid interface stays in place.
Interpret → Validate → Adapt or preserve
That gave me both sides of the governance model:
Extend intentionally when the system genuinely needs a new pattern.
Block safely when a request falls outside the defined system.
Guiding the experience
Because the concept is easier to understand through interaction, I added a short walkthrough that takes the reviewer through the system one behavior at a time:
Preparing for your trip → Ready to go → Travel plans changed → System transparency → Governance
The walkthrough lets someone change the context, see the interface respond, inspect the decision logic, and then test the governance boundary themselves.
What I learned
Atlas started as an experiment in context-aware interfaces.
The more interesting part became what happened after the interface was allowed to adapt.
The prototype helped me separate the responsibilities:
Context provides the signals.
Rules decide what matters.
The interface spec describes the result.
Schemas validate it.
The component registry defines what is allowed.
The question ultimately became less about generating interfaces and more about:
How can an interface respond to changing context without giving up control?
Prototype
Built with
React · TypeScript · Vite · Zod · Vercel
Built through AI-assisted prototyping with Claude and refined in Codex.
My role
Product design, interaction model, system behavior, governance approach, testing, and prototyping direction.