“This place exists.”
Coordinates, a name, a category, a road network. True, and the same answer at every hour of every day, for every traveler.
The intelligence layer for discovering the real world.
Give your visitors, guests and AI assistants a verified, continuously maintained understanding of what is worth seeing, where to go, and what will actually work at the hour they arrive — inside the product you already have.
435,576 verified places · 815 signed scenic routes · 2,095 surfaced lookouts · 63 national parks · 189 public-land units · MCP-ready
Don’t just give people a map. Give them judgment.
“This is worth stopping for, it sits on your route, it will be open when you get there, and there is still light.”
Verified places, routing, and reasoning against the arrival hour — opening times, daylight and weather — weighted by what the traveler said they came for.
Built for anyone who has to be right about a place.
Find yours and jump to what you could build with it.
You are not buying one API.
Four layers, each useful on its own and stronger together. What reaches your product is the top of a corpus, a reasoning engine and a protocol that were built to sit under one another.
- What exists
Byway Atlas
435,576 verified places, 815 signed scenic routes, 63 national parks and 189 public-land units. Every entity traces to a public record by its OpenStreetMap id, so any figure can be checked without asking us.
- What makes sense
Byway Engine
Route planning and spatial reasoning, then the part that is hard to copy: opening hours, daylight and weather evaluated against the hour of arrival rather than the hour of planning. A routed day, not a list of coordinates.
- What fits this person
Byway Compass
Interests supplied with the request already weight the plan — waterfalls over museums, quiet over crowded. The learned per-traveler model that sharpens this over many drives is Byway Compass, today a traveler-facing product.
Learned profiles for institutions: future
- Where the intelligence goes
Byway MCP
A live Model Context Protocol server, listed in the official registry, so an assistant or an application reads the atlas and calls the engine directly. It is the API — there is no second one to wait for.
Put Byway inside your product.
Your customers do not need another app. Byway can be the intelligence behind the one they already use.
- Destination marketing
- Turn a destination site into a trip planner: routes, stops and itineraries beyond the five attractions everyone already lists.
- Tourism boards
- Give static destination content a route to travel on, ordered by what a visitor actually said they came for.
- Parks and public lands
- Surface scenic routes, overlooks, campgrounds and visitor centers that are already in the corpus, against real access and opening constraints.
- Hospitality
- Answer the question a guest actually asks at the desk: it is two o'clock and I have until dark — what is worth doing from here?
- Automotive
- Scenic discovery and stop recommendations inside the vehicle, on the same corpus and engine the Byway app drives.
- Travel and mobility platforms
- Add route and destination discovery without building a geographic reasoning engine and then maintaining it.
- AI and agent platforms
- Reach verified places and route intelligence over MCP, with no integration to build first.
- Enterprise and custom
- Build a discovery experience the categories above do not describe, on the same infrastructure.
What this looks like for one destination.
A visitor to Asheville, North Carolina, types a sentence into a tourism site that has Byway underneath it.
“I have one day near Asheville. I like waterfalls, scenic roads and quiet places. I need to be back by seven.”
- Signed routes within reach
- 10, including Blue Ridge Parkway, French Broad Overview, Drovers Road
- National park
- Great Smoky Mountains National Park
- Public-land units
- 2
- Campgrounds
- 16
The engine orders those against the clock: what is open when the visitor would arrive, whether daylight holds to the last stop, what the weather does to an overlook, and which of them answers “waterfalls and quiet” rather than “waterfalls” alone. Your site renders the result. The reasoning is ours to maintain.
Every count and route name above is read from Byway’s committed registries at build time · see the Asheville page
A model knows the world. It does not know this hour.
Language models carry a great deal about places. What they do not carry, and cannot derive:
- which places are real, and which the model composed
- which road is actually scenic, and which merely connects two points
- what is open at the hour someone would arrive
- whether daylight lasts to the final stop
- whether a stop fits the day at all
- how to build a feasible multi-stop route rather than a list
Byway is the grounded layer underneath. Its architecture is built to answer from structured, validated entities rather than from generic knowledge — every candidate stop traces to a public record before it reaches a traveler.
That is a design, not a guarantee about a model’s prose. What Byway constrains is the set of things a recommendation can be about.
One connection to Byway’s real-world intelligence.
A compatible assistant or application discovers Byway’s tools and reasons over the atlas and the engine directly. Questions it can carry:
- Find scenic routes near Asheville.
- What can I realistically see between these two cities tomorrow?
- Find overlooks along this route that will be open when I arrive.
- Plan a two-day scenic journey for someone who prefers nature and avoids crowds.
The atlas read surface. These touch no paid provider and answer anonymously.
search_places · get_place · search_byways · get_byway · places_on_byway · search_lookouts · search_destinations · get_itinerary
Journey generation spends real money at a routing provider on every call, so it is metered against a verified identity. In an assistant this is the traveler who connected Byway. Server-to-server journey generation for an institution is arranged directly — that conversation is what the contact form is for.
- plan_drive — builds the routed, arrival-aware day
- places_along_route — what stands along a given line
Byway doesn’t just describe the world. It helps decide what to do in it.
Traditional geographic data
- Coordinates
- Names
- Categories
- A road network
- Points of interest
Byway
- Verified places, traceable to the public record
- Signed and scenic route relationships
- Routing and feasibility
- Arrival-hour reasoning
- Opening times, daylight, weather
- Interests weighted into the order
- Narration from verified fields
- A generated, drivable journey
One integration, four layers deep.
Your website, app, assistant or vehicle
what your customer touches
Byway MCP
one connection, machine-readable
Byway Engine
routing, arrival-hour reasoning, feasibility
Byway Atlas
verified places, routes, parks, public land
The public record
every entity traceable by its OpenStreetMap id
Acquire the capability, not the maintenance.
- Time to market
- Launch discovery without building a geographic reasoning stack, then staffing it forever.
- Better visits
- Move from a static list of recommendations to a journey that accounts for the day.
- Deeper exploration
- Send visitors past the obvious attractions to secondary destinations and the roads between them.
- AI readiness
- Be reachable through the assistant interfaces people are starting to plan in.
- Maintained, not frozen
- The corpus and the engine keep moving, instead of thousands of hand-written recommendations going stale.
AI should not invent the world. It should reason over it.
- Entities come from public records
- Every place carries its OpenStreetMap id. A buyer can check any row against the source without asking Byway.
- Routes trace to their designation
- Signed byways come from the federal register and the state rosters that designate them, not from an editor's judgment.
- The engine reasons over known entities
- Candidates are drawn from the corpus. The engine chooses among things that exist rather than proposing destinations.
- Narration compresses, it does not invent
- Prose is written from verified fields. Where a field is missing, the sentence is missing.
- Conditions are evaluated against arrival
- Opening times, daylight and weather are checked for the hour a traveler would be there, not the hour they asked.
Your customers don’t need another app.
Byway already runs across these. The same corpus and the same engine sit under all of them, which is why the intelligence can move into yours.
- The web
- iOS and Android
- CarPlay and Android Auto
- AI assistants
- Tourism and destination sites
- Hotel and property experiences
- Enterprise platforms
Byway’s own CarPlay and Android Auto work is roadmapped and carries no date, by policy — those ship when Apple and Google clear them.
Start with one call. Expand from there.
- 01Search verified places and read one back
- 02Discover signed and scenic routes
- 03Surface what stands along a route
- 04Generate a routed, arrival-aware journey
- 05Weight it with the interests a traveler states
- 06Connect an assistant over MCP
The tool schemas, the endpoint and worked examples are on the Byway MCP reference. Public tools need no key; wider limits are arranged.
Build the next generation of destination discovery.
Built for organisations that help people discover the world. Tell us what you are building, which layers you need, and roughly what volume you expect. Licensing is arranged case by case.
Where Byway already reaches: coverage, scenic byways, lookouts and Byway AI. Creators publish onto the same corpus through the marketplace.