BodyLore

It records what happened, not what an app thinks it means

Medications, allergies, conditions, symptoms, appointments, procedures, labs, vaccinations, vitals, measurements, sleep, activity and attachments. One coherent home for a history otherwise scattered across portals, apps, bottles and memory.

Private Self-hosted API-first Feature complete, not deployed
Get in touch
Overview

A record, not an opinion.

Most health apps interpret. They take what you logged and hand back a verdict, a score, or a suggestion whose reasoning you cannot see. BodyLore records the thing that happened and keeps the interpretation separate from it, because the record is what you will still need in ten years and the interpretation is not.

Suggestions run condition to symptom and never the reverse, which is the enforceable direction. A record is keyed on the person it is about rather than on whoever is holding it today, so it can change hands without moving.

It is one of three apps that talk to each other directly, and that list is closed. What an integration is permitted to see is enforced rather than described: enabling one is not the same as handing over a category.

How

What it keeps.

Keyed on the person
The subject of a record, the account allowed to act on it, and the grant between them are three separate things, which is what lets a record change hands without moving.
An emergency card with no way back
Printable, carrying no credential, no endpoint and no route back into the app. It is useful to somebody holding it and useless to somebody who steals it.
Attachments that take their bytes with them
Encrypted, never served from a guessable address, and gone for real when deleted rather than merely unlinked.
644 tests against real Postgres
Run against real Postgres semantics rather than a mock, because the rules this app holds are enforced in the schema and a mock would agree with anything.
Status

Everything on the build order is built.

The data layer, the API over both credentials, the observation log, scoped tokens with the permission model enforced, the identity split with handover, insights, the injection map, encrypted attachments, the emergency card, an export of the whole record, and an OpenAPI document generated from the schemas that validate the requests, so it cannot describe a field the handler will not accept.

What remains is the deploy directory as a runbook, and the open findings in a security review that says what it did not cover.

Handling of data is covered in the Locke Werks Privacy Policy. For access, or a conversation about what it would take to use this, write to nyx@lockewerks.com.