A Mac mini on the boat.
Ingests sensor data, runs the local services, hosts the user-facing apps, and keeps working when the boat is off-grid. Apple Silicon gives useful local inference at the wattage budget a cruising boat actually has.
For the geeks
Same product. Different lens. If you want to know how it actually works — to contribute, fork, audit, or run it on infrastructure you control — this is for you.
Short version: 32°N is a small set of platform services with a growing collection of narrow apps on top, an AI layer with typed access to all of it, and a deployment model that runs from a Mac mini on the boat out to a cloud you can swap in and out. The whole stack is MIT-licensed.
01 · The shape of the system
Apps don't know about each other. They know about the platform. New apps inherit identity, data, events, AI access, and audit for free.
Ingests sensor data, runs the local services, hosts the user-facing apps, and keeps working when the boat is off-grid. Apple Silicon gives useful local inference at the wattage budget a cruising boat actually has.
Apps depend on the platform — not on each other. Identity, data store, event bus, AI gateway, audit log, sync, MCP server, agents. New apps inherit all of it.
Each app does one job well — anchor, weather, electrical, comms, log, security audit, and so on. Writing a new app means implementing platform contracts, not negotiating proprietary device protocols.
02 · How it reads the boat
Off-the-shelf NMEA-2000 gateway — Actisense NGT-1, iKonvert, Yacht Devices YDWG-02 — plugs into your existing network. USB or Ethernet into the hub. Parser service emits typed events onto the bus.
Bluetooth and WiFi-attached devices (Victron VE.Direct, certain battery monitors, weather stations) feed through their own adapters into the same bus.
Every reading is timestamped, source-tagged, and persisted. Apps don't poll devices; they subscribe. AI subscribes to the same bus.
New apps don't write new ingestion code — the data model is already there. Same for the AI. Same for external agents talking in over MCP.
The schema is open and documented. No proprietary blob formats. No "let me check whether we can give you that data back."
schema/v1/wind.json describes the wind event shape.
schema/v1/battery.json describes batteries. Every
schema is in the public repo.
03 · AI
The AI layer has typed access to every reading the bus emits, every app's current state, and a per-boat knowledge base. The anchor app and the weather app don't need to know about each other. The AI does.
Specific agents handle specific jobs — anchor watch, passage planning, anomaly detection, the rest. They have scoped access to the platform services and act on their own under defined conditions.
The agent layer is part of the platform, not bolted onto individual apps. Anomaly detection, passage planning, and "is this a good window to leave" are AI surfaces sitting on top of the shared data model.
32°N exposes a Model Context Protocol server. External AI tools — your Claude or ChatGPT instance, a research agent on your laptop, anything that speaks MCP — can connect and get scoped access to the same boat data and tools the built-in agents use.
Not a custom API per partner. Just MCP.
Bring your own models, eventually. Today the AI gateway routes to a curated set of frontier models. Down the road, point it at your own self-hosted model — whatever fits your privacy and capability requirements.
04 · Security
I spent the last decade in software supply chain security. I'm not interested in shipping a marine platform that any teenager with a Flipper Zero can walk onto. Security is in the architecture, not added in a later release.
Every piece of hardware that talks to 32°N — sensors, instruments, gateways, phones, tablets — is registered, identified, and scoped to specific permissions. Add a device, it goes through registration. Remove one, its credentials are revoked.
Nothing connects to the system that hasn't been explicitly admitted.
Apps run with least-privilege scopes against the platform services. The audit log is structured, queryable, and tamper- evident.
If you use my hosted instance, it replicates to the cloud, and it is portable out by design — there is no "premium export feature."
If you self-host, nothing leaves the hub unless you point it somewhere yourself.
The schema is open. The licence forces it to stay that way.
05 · Running it yourself
All three modes share the same source. There is no "open core" with paid features sitting on top. That's a project-stance commitment, not a structural guarantee — MIT permits open-core. If I ever break the stance, the same source is still available to fork.
Mac mini on the boat, my hosted instance for the cloud side. You connect a gateway, sign in, you're running.
Mac mini on the boat, your own cloud (any provider, or a server in your house) for the rest. I publish container images.
Hub and cloud both yours. Fork the repo, build, deploy. Same code as my instance — no diverging "cloud edition."
06 · What I'm explicitly not doing
One SDK, one licence, public repo. There is no separate "partner SDK" with different terms.
Packages, registries, normal tooling. If your stack works with npm-class tooling, it works here.
My hosted instance runs the same code as the public repo. MIT doesn't legally require that — it's a project-stance commitment. The source is public; if it ever diverges, you'd see the diff.
Opt-in only. If you turn it on (please do — it makes the project better for everyone), you can see exactly what gets sent, and turn it off any time.
The hub is Mac mini–tested only right now — focus, not architecture. Other hub platforms come after 1.0.
Not taking outside contributions until 1.0 lands. Once it does, the doors open — with plain-English terms and a clear PR process.
07 · Where to look
Links go live as URLs firm up. The repo is the source of truth.