Adding a Projection

"A new view is not a new feature to wire up. It is just another reader asking the model a new question."

The Payoff of One Model

Everything in this track has been building to a practical reward. When there is one canonical model and every surface is a projection of it, adding a new view is cheap and safe. A new projection does not need its own storage, its own sync logic, or its own copy of the trip. It needs exactly one thing: a way to read the canonical state and render it. The globe, the place lens, a planned-geometry layer, a fatigue heatmap, a "places Mom liked" filter — each is just another reader, and none of them can corrupt the others because none of them writes.

Compare the Two Worlds

In a marker-database design, every new view is a small nightmare: it needs its own store, it has to be kept in sync with the others, and every write path has to remember to update it. Add five views and you have five things that can silently drift out of agreement. In a one-model design, add five views and you have five readers of the same truth — they cannot drift, because there is nothing to drift from. The cost of a new projection collapses from "a new synchronized database" to "a new query and a render." That is not a minor optimization; it is what makes the geography a growing hierarchy instead of a fixed set of screens.

Why the Future Rings Are Cheap

This is exactly why Waystone can ship the Journey Map first and leave the Globe and Place Lens as future rings without any anxiety. Those rings are not blocked on new infrastructure — the canonical state they will read already exists. When the Globe arrives, it will not add a "globe database"; it will add a globe reader over journeys and flags that are already there. The one-model discipline you paid for up front is what makes every future view a small addition instead of a new subsystem. Polymorphism is not an abstract virtue here — it is the reason the roadmap is affordable.

Code

The cost of a new view, two designs·text

MARKER-DATABASE DESIGN            ONE-MODEL DESIGN
----------------------------------------------------------
new view needs:                   new view needs:
  - its own store                   - a query over canonical state
  - sync with every other view      - a render
  - a slot in every write path

5 views = 5 things that drift    5 views = 5 readers, zero drift

# add_projection(model):
#     data = model.query(...)   # read only
#     render(data)              # no storage, no sync, no write
# That's the whole cost. The Globe and Place Lens are this.

Exercise

Imagine one new view you'd want over your own accumulated data — a heatmap, a timeline, a filtered list. In your current tools, would adding it mean building a new synchronized store, or just writing a new query over data that already exists? The answer tells you whether you have one model with many readers, or many little databases pretending to agree.

Hint

If a new way of looking at your data would require re-entering or re-syncing the data, you don't have one model — you have copies. The whole value of one-model-many-views is that the next view is a query, not a migration.