PainTracker is a privacy first, offline first pain tracker built for the moments that matter.
No cloud dependency. No surveillance business model. Client side encryption where it counts.
This page is the front door for the CrisisCore catalog around PainTracker,
Protective Computing, and trustworthy offline-first systems.
If you are living with chronic pain, start with the product and the evidence.
If you are building health software, start with the architectural constraints.
If you are auditing claims, start with the failure modes and the proof.
If you want privacy-first, offline health tech to exist without surveillance funding it: sponsor the build → https://paintracker.ca/sponsor
Start with the route that matches your goal
1. If you want the Protective Computing doctrine
Start here:
Architecting for Vulnerability: Introducing Protective Computing Core v1.0
Then read:
Protective Computing Is Not Privacy Theater
Then close with:
The Stability Assumption: The Hidden Defect Source
Then use the citable canon:
The Overton Framework is now DOI-backed
2. If you want the reference implementation path
Start with the architecture:
Offline-first without a backend: a local-first PWA architecture you can trust
Then read the boundaries underneath it:
Three storage layers in an offline-first health PWA: state cache vs IndexedDB vs encrypted vault
Service workers that don't surprise you: deterministic caching for offline-first PWAs
Exports are a security boundary: the moment local-first becomes shareable
Maintaining truthful docs over time: how to keep security claims honest
3. If you want the failure-mode and testing path
Start with what breaks in the wild:
Service Worker Failure Modes in Offline-First PWAs
Then read the recovery and migration boundaries:
Rollback Patterns in Offline-First PWAs
Testing IndexedDB Schema Migrations in Offline-First PWAs
Offline Queue Replay and Idempotency in Offline-First PWAs
If you want the boundary question that sits under those tests, add:
Trust Boundaries in Client-Side Health Apps
4. If you want the trust and release path
Start with:
Quality gates that earn trust: checks you can run, not promises you can't
Then read:
ProofVault as a Release Artifact: Turning Trust Into Something You Can Verify
Preview Mode First: Agent Plans as PRs
The Overton Framework is now DOI-backed
If you want the raw series pages
CrisisCore Build Log:
dev.to/crisiscoresystems/series/34363
Protective Computing in Practice:
dev.to/crisiscoresystems/series/35109
Try it or support it
Try PainTracker
paintracker.ca
Star the repo
github.com/CrisisCore-Systems/pain-tracker
Sponsor
github.com/sponsors/CrisisCore-Systems
One honest note about scope
This is not medical advice.
This is infrastructure. The goal is to help you track reality without giving away control of your data.
If you are building something similar
What is the one rule you use to make sure your offline features never surprise the user
Support this work
- Sponsor the project (primary): https://paintracker.ca/sponsor
- Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker
Top comments (0)