Concrete First

"Don't turn a guess into architecture. A guess nobody revisits is how accidental architecture is born."

The Rule Against Premature Certainty

Waystone's architecture document carries an unusual instruction to itself: keep open questions explicitly open; do not turn guesses about frameworks, vendors, or storage into accidental architecture. That is the concrete-first principle. You do not choose the database, the map provider, or the deployment topology until a real vertical slice makes the decision useful. Not because decisions are bad, but because a decision made before you have evidence is a guess wearing a decision's clothes — and guesses that nobody flags as guesses harden into architecture that everyone later assumes was reasoned.

What This Looks Like in Practice

The v0 engine stores journeys as plain files — a journey record, a plan document, an append-only breadcrumb log — rather than starting with a database schema. The geocoder and the map tiles are named as v0 choices, explicitly replaceable behind the engine's own endpoint. And the document maintains a standing Open Decisions list: migration tooling, routing and elevation providers, offline packet storage, the conflict-resolution surface, the native-client threshold. Each one is a place where the honest answer is "not yet decided," written down as such instead of quietly defaulted into.

Why the Explicit List Matters

Every project makes provisional choices. What is rare is writing down which choices were provisional. That list is what lets a future reader — future-Dad, future-Pippa, future-you — tell the difference between "we chose this for a reason" and "this is just what we grabbed to get moving." Without the list, both look identical in the code six months later, and nobody dares change the second kind because it might be the first. The Open Decisions section is not indecision; it is a map of where the architecture is still allowed to move.

Code

Provisional vs decided — say which is which·text

DECIDED (a slice proved it)
  cwkPippa owns the brain          # invariant, not up for debate
  plan/actual never merge          # invariant
  capture commits locally first    # invariant

V0 CHOICE (replaceable, behind our own endpoint)
  file store, not a DB yet         # a real slice will tell us
  this geocoder, these map tiles   # swap without touching callers

OPEN DECISION (honestly undecided, written down)
  migration tooling + when to move beyond the current store
  routing / elevation / offline-map providers
  conflict-resolution UX for diverged edits
  the evidence threshold for a native client

# The value is the LABEL. Without it, six months later a guess
# and a decision look identical -- and nobody dares touch either.

Exercise

Open a project you work on and find three technical choices that are load-bearing today. For each, ask honestly: was this reasoned from evidence, or grabbed early to get moving and never revisited? Now try to find any place where that distinction is written down. If it isn't, every provisional choice in that codebase has quietly been promoted to architecture.

Hint

The tell is when you ask 'why is it this way?' and the answer is 'it's always been that way'. That is a guess that was never labeled and has now calcified. Writing 'this is a v0 choice, replaceable' next to it at the time costs one line and saves the next person from treating your shortcut as doctrine.