Clinical reality is not a clean workflow. Pain and disability documentation is often created under stress, low energy, and low trust.
Most health tracking apps assume the opposite.
They assume account creation. They assume always on sync. They assume the user is willing to route intimate data through third party analytics and cloud storage.
That collection model is not neutral. For many people it is dangerous.
PainTracker is built to reduce the collection surface area without breaking the core job.
The user keeps authority. The system remains usable when the network is absent. The export is a deliberate action.
Minimization delta in plain language
Before: the common pattern is account-first logging, centralized storage, and sharing assumptions baked into the default path.
After: day-to-day records stay local by default, core use does not require sign-up, and export happens only when the user initiates it.
That is the core claim. Less dangerous collection, same useful product.
Threat model in plain language
The primary threat is not a hacker fantasy. The primary threat is institutional and interpersonal pressure.
An insurer asks for records. A clinician dismisses symptoms. A landlord demands proof of disability accommodations. A partner demands access to a device.
A protective health journal must assume that the data can be used against the user. So the architecture reduces the surface area.
Design constraints
Low cognition operation Capture the minimum useful signal with the fewest steps Never punish partial entries
Degraded connectivity Function offline Preserve progress through interruptions Avoid loading spinners as a dependency
Privacy as default No telemetry by default No central database requirement for core use No background sharing
Reversible sharing Exports are explicit A user can decide what to share and when
Architecture
PainTracker uses a local-first model.
Entries are stored on the device. The app is usable without connectivity. The core interaction is fast logging.
When the user needs a proof artifact, the system produces an export.
That export can be shared with a clinician or kept for personal continuity. It is created by the user, not by a server.
The design choice is not just “local-first.” It is collection discipline. Only collect what the core workflow needs, keep it under local control, and make sharing explicit.
This approach is not anti cloud. It is pro boundary.
Cloud features can be added as optional modules. But the base layer must remain protective.
What makes it protective
A protective tool is quiet.
It does not force identity. It does not require trust. It does not collapse when a server fails. It does not turn the body into an analytics or advertising profile.
It gives the user a stable interface to their own life.
Proof surfaces
The dossier is the operational summary. It contains the constraints, the minimization boundary, and the architecture artifacts.
If you want to inspect the system as an auditor, start with
The project dossier at /projects/pain-tracker The live deployment and repository links inside that dossier The export and architecture artifacts that show the collection boundary in practice
If you want the doctrine behind the architecture, read
The doctrine post at /writing/protective-computing-doctrine