tensr.fitness

Notes Arc E — Tools and trust Post 14 of 14

Open data, closed care.

No sensor required

Every fitness app you’ve used has had at least one moment where you wanted to leave and couldn’t. Or you wanted your data — your workouts, your weights, your years of history — and got a lossy CSV six business days later. Or you got nothing.

This is so common it doesn’t even register as a problem until you try to leave.

What “your data is yours” actually means

In tensr, the database is a SQLite file on your device. Not a representation. Not a cache. The actual database the app reads and writes is a file you can copy off the device, open in any tool that reads SQLite, query directly, and walk away with.

Four things that aren’t aspirational — they’re the contract:

CommitmentWhat it means in practice
Local-first by defaultRecording works fully offline. The app writes to local SQLite first; sync is later, if you opt in.
Open formats foreverExports to SQLite, NDJSON, CSV (and Parquet for large datasets). Schema documented and versioned.
Schema migrations forward-onlyWhen the schema changes, your old recordings remain queryable. We don’t break backward compat.
Lossless exportsEvery metric we compute is exportable, not just raw force samples. What the cloud sees, the user can take.

If tensr.fitness goes away, your training history keeps working with any tool that reads those formats. That’s the floor.

Why it matters

The thing that makes data ownership feel like a luxury is that it’s almost always sold as one. “Pro tier: data export.” “Annual subscription required for historical access.” “API rate limits prevent bulk extraction.”

The pattern is so ingrained that the question is usually “how much will this cost me to leave” rather than “do I own this.” But for tensr the answer to the second question is the only one that needs to be defensible: yes, you own it; no, leaving costs nothing.

Two reasons this commitment is structural, not just a feature bullet:

The data is the most personal thing the app touches. Your training history is years of behavior. It’s where you were strong, where you were weak, when you took breaks, when you came back. If anyone has to own that, it’s you.

Trust scales the business, not lock-in. A user who can leave whenever they want and chooses to stay is a user who values what we provide. A user who can’t leave has no signal to give us about whether we’re earning their attention. The first is durable; the second decays.

What to track together

The values stack works as one set of guarantees, not five separate features.

LayerThe commitment
RecordingWorks offline. Free tier, no account, no cloud.
StorageSQLite on device. The user’s file.
SyncOpt-in. Useful, never required.
ExportAll metrics, all formats. Not paywalled.
SchemaForward-only migrations. Old data stays readable.

The thing that makes this work as a business — what sqlite-at-the-core.md calls “open data, closed care” — is that the file format is open, but the discipline of running the corpus is not. A fork can read your SQLite. It cannot read everyone else’s. It cannot canonicalize movement labels at scale. It cannot maintain the metric library, the sensor adapters, the cohort benchmarks.

We give away the recorder. We earn the right to keep the history.

What gear it needs

N/A. The values stack is a software contract, not a hardware question. The Tindeq, the C06, the KForce-Link — all write to the same SQLite, all export to the same formats. The data ownership commitment doesn’t change with the price of your sensor.

What to do tomorrow

From the app, export your last session as SQLite. Open it in any SQLite tool — sqlite3 on the command line, DB Browser for SQLite if you prefer a GUI, a Python notebook, whatever you have around.

Run a query. Anything. Count your reps. Average your peak forces. Pull the eccentric durations into a histogram.

The point isn’t the query result. The point is that you can run it at all, on a file you fully own, with no app installed and no account required.

A specific exercise for the data-owners’ club: take that exported SQLite and load it into something tensr doesn’t make. A spreadsheet. A Jupyter notebook. A Grafana dashboard. See what your data looks like outside the app.

That’s the thing every other fitness app you’ve used has prevented. tensr’s whole stance is built around the fact that you should never have to fight to do it.

Local-first by default. Open formats forever. The data is yours.


What this looks like in tensr.fitness. Open the app, pair a sensor, and the metrics in this post are on the screen the moment you start a set.

A note on the data. Every force sample you record stays on your device unless you opt into sync. The file format is open — SQLite, CSV, NDJSON, all readable with any tool. More on that in the FAQ.

data