The odometer

Component status and the commitments that guide the work. Read the north star for the direction; use this page to check what exists.

The mission is to turn the intelligence people rent into capability they own: private, inspectable AI on hardware they control, which they can keep running after leaving a provider.

Status of record

What's running, what's measured, what's promised

Status as of 2026-08-14. Any tag change updates this date. What has been measured, with the numbers and their hedges, is governed by the claim ledger; this table reports component state and defers to the ledger wherever the two could disagree.

• RunningLocal runtime. mlx-go runs capable AI inference and training on hardware people already own (Apple silicon today), with a conformance harness checking model implementations against reference outputs.
• RunningLocal proxy. Sits between you and the rented AI, on your side of the line. Routes calls between a frontier API and a model on your own machine, and, with your permission, keeps the private, encrypted record that later teaches your own model.
• RunningPeer transport. go-iroh brings the iroh peer-to-peer transport to Go (encrypted direct connections, hole-punching, relays), the wire that group training rides on. Public code, with a dedicated performance lab measuring it against the native Rust implementation; those numbers publish with their confounds, not before.
• MeasuredTwo-machine exchange and merge. Two Apple Silicon machines independently fine-tuned, exchanged, and robust-merged real LoRA adapters over a real network to byte-identical files, three consecutive rounds, validation loss falling from 6.07 to 2.23. Published with its failures. That was two machines, not a group.
• In buildThe learning loop. The captured record fine-tunes a small model in your own custody, a replay harness scores it against the frontier baseline, and qualifying calls route locally. First task: code-review triage, chosen because it runs on a permission-clean record the company already owns. The loop is claimed when the unplug test passes on it, and the numbers get published either way.
• In buildGroup training. Coordinated multi-node training: machines that trust each other pooling what they learn without pooling the raw work. Unclaimed until it runs.
• In buildContribution verifier. The inbound gate: checks a training contribution before it merges. One measured early result: re-executing a sparse sample caught 82 percent of one defined corruption while sampling under half a percent of the bytes, in one setup. A gate in progress, not a shield.
• In buildGuard at the door. Outbound screening: a local model flags protected health information, credentials, and privileged material before anything leaves your machines. Necessarily local; a cloud checker would itself be the leak. A screen that helps you catch mistakes, not a compliance guarantee.
• RunningAgent security tools. skiff wraps policy, credentials, and audit around AI agents on the customer's side of the line; cove gives resettable, inspectable Mac environments.
• PlannedInterpretability on hardware you hold. Tools to look inside the models you distill: small, task-scoped, weights in your custody, the most tractable setting for it. Distillation isn't assumed to preserve the teacher's guardrails, so the answer is inspection you can run yourself. Inspection tooling, never a verified-safe stamp.

The supporting tools include GPU trace analysis, model-IR conformance checks, FFI verification, and benchmark rigs. Their evidence supports the claims above.

The part that keeps me honest

Three lines I won't cross

Each commitment has a failure you could identify in the product or in a deal the company makes:

1. The user's side, never the watcher's. The same stack could be sold to the people I'm building against. It won't be. The tools serve the person holding the machine, never the one watching it.
2. No lock-in. Always exitable. Own your data, read the code, run it offline. If a customer can't leave, the dependency trap is just rebuilt. The door stays open by design.
3. Inspectable. Never trust-me. The code in the sensitive path stays small and open enough that you (or your security team) can read what's actually there. Verify me, don't trust me.

Funding the work

Who would pay for it

The intended customers are regulated teams, security-conscious operators, and founders who want to keep control of their systems. They would pay for local, private, auditable AI. Serving them is how the company plans to fund the work.

Owning the system also gives you an independent place to inspect its behavior. You can keep your own logs, run checks, and decide what evidence you accept.

I want enough revenue to keep building indefinitely while preserving the three commitments above.

I'd rather build the counterweight and not own most of it than build the centralized version and own all of it. The point is that the alternative exists.

The map

Where to go next

Every public page in this set (who each is for, and which one to trust when they seem to differ) is indexed in one place: the map.