Architecture
32°N is not a monolith with everything glued together inside it. It is a set of independent pieces with a defined order: hardware at the bottom, a data bus in the middle, platform services on top of that, apps on top of those, and a cloud layer that adds capability without being required for anything critical.
I made those choices deliberately. Each one is a design constraint that keeps the whole thing from becoming unmanageable as it grows. Here is what those choices are, and why I made them.
01 · Hub-first design
Everything on the boat connects to the hub. The hub owns the database, runs the apps, and mediates cloud sync. Nothing talks to anything else directly.
The boat's instruments — GPS, depth, wind, AIS, battery monitors, anything on NMEA-2000 — all feed into the hub through a standard gateway. The hub parses those readings, puts them onto the bus, and persists them to the local store. From that point, all apps see the same data, formatted the same way.
This matters at sea. If your chartplotter and your anchor watch disagree about your position because they are each reading the GPS differently, that is a problem. Hub-first means one parse, one source of truth, consumed by all.
A boat offshore has no internet. The hub is designed so that the whole product works in that state — no degraded mode, no features locked behind a connection. Charts, routing, anchor watch, logbook, electrical monitoring: all local.
When connectivity returns — marina WiFi, satellite, coastal LTE — the cloud layer picks up. But the hub never waited for it. The hub is the product. The cloud is an extension.
02 · Apps as processes
Each app is its own service running inside the hub OS. They publish to the bus. They never read each other's databases directly. The platform is the intermediary for everything.
The anchor watch does not know the chartplotter exists. The weather router does not reach into the logbook. Each app speaks to the platform — it subscribes to bus events, reads from the shared data store through the platform's data layer, calls AI through the gateway — and that is it.
This is how the app catalogue can grow without the whole thing becoming spaghetti. Adding a new app does not require touching any existing app's code. Removing one does not break anything else.
What every app inherits when it targets the platform: identity and device registration, the shared data store, the event bus subscription model, the AI gateway with typed tool access, the audit log, and sync. The app implements its own business logic. The platform handles everything else.
This is also what makes extensions viable. A third-party app gets the same substrate as a first-party one. The contracts are the same, the licence is the same, the capabilities model is the same. There is no "partner API" with different terms.
03 · The data bus
Every meaningful event on the boat flows through a typed, versioned, source-tagged bus. Apps subscribe. They do not poll. The schema is open and lives in the public repo.
A wind reading arrives from the NMEA-2000 gateway. The parser
emits a wind.apparent event tagged with the source device,
a millisecond timestamp, and the payload — speed, angle, confidence.
That event is the bus message every subscriber gets.
The chartplotter subscribes to display the wind indicator. The weather router subscribes to factor current conditions into routing decisions. An AI agent subscribes to watch for wind shifts that might affect the anchor. One event, three consumers, no polling.
The schema is versioned — schema/v1/wind.json,
schema/v1/battery.json, and so on — and it is in the public
repo. When a schema changes, the version increments. Subscribers
declare which versions they support.
This is not SignalK, not a third-party message broker. It is 32°N's own native bus designed from the start to carry the data model the platform needs. The structure is open. There are no proprietary blobs. If you want to write a subscriber, you have everything you need.
04 · Cloud
The cloud adds sync, share-links, frontier AI access, and a hosted hub option. But the boat works without all of it. If the cloud goes down, the boat keeps running.
Four things require the cloud: syncing your data across multiple devices (phone, tablet, laptop), routing AI requests to frontier models like Claude, generating share-links for your passage plan, and the option to run the cloud services on my hosted instance instead of your own hardware.
Everything else is local. AI inference for time-critical functions runs on the Mac mini's Apple Silicon. Charts are cached. The local data store holds your history. The bus runs locally. None of that touches the cloud.
The cloud services are not a single monolithic API you either use or don't. They are separate services — sync engine, AI gateway, share-link service — each independently pointed at whatever infrastructure you want to run it on.
My hosted instance is the default and the easiest path. But you can point the sync engine and AI gateway at your own servers. I publish container images. Swap one service, leave the others. The licence ensures the code you are running is the same as the code I am running.
05 · Diagram
The hub runs on the boat. The cloud extends it. The sync arrow between them only flows when there is a connection — and the hub does not need it to keep running.
06 · Design principles
These are not aspirations. They are constraints I enforce in code review.
Hardware and the bus change the least. Apps change the most. Nothing in a higher layer can break the contract of a lower one. An app can be rewritten or replaced without touching the bus schema. A new bus schema version does not break existing apps that have not opted into it.
Apps depend on the platform. Apps do not depend on each other. If the anchor app imports anything from the chartplotter, that is a review failure. The platform services are the only shared code.
This rule is why I can add a new app without a risk assessment of what it might break.
Sensor data is parsed once, at the hub. Every consumer — apps, AI, external integrations — reads from that same parsed, typed, timestamped stream. There is no secondary parsing layer, no per-app format negotiation.
The hub does not ask the cloud for permission to do anything. When cloud is available, they sync. When it is not, the hub queues changes locally and syncs when connectivity returns. The boat's operation never depends on a round-trip to a server.
The platform hub explains all five layers. The developer guide covers schemas, contracts, the SDK, and how to write an extension that targets the platform.