DEV Community

CrisisCore-Systems
CrisisCore-Systems

Posted on • Edited on • Originally published at dev.to

Start Here: PainTracker and the CrisisCore Build Log

#privacy #security #pwa #architecture

Start from the resource hub: pain tracking resources

PainTracker is a privacy-first, offline-first pain tracker built for moments where stability has already failed.
No cloud dependency for the core workflow. No surveillance business model. Client-side protection where the data boundary demands it.

This page is no longer just a list of posts.
It is the front-door protocol map for the CrisisCore catalog around Protective Computing, PainTracker, and the implementation evidence behind both.

If you are here to understand the doctrine, start at Layer 0.
If you are here to audit the engineering, walk the stack from Layer 1 through Layer 4.
If you are here to decide whether these claims are earned, follow the artifact and release path, not just the rhetoric.

If you want privacy-first, offline health tech to exist without surveillance funding it: sponsor the build → https://paintracker.ca/sponsor

The protocol stack

Layer Component Function Start here
0 The Protocol The doctrine, threat model, and legitimacy test. Architecting for Vulnerability: Introducing Protective Computing Core v1.0
1 The Cryptography Local authority, subpoena resistance, and explainable client-side protection. Client-Side Encryption for Healthcare Apps
2 The Resilience Offline-first storage, deterministic caching, and degraded-mode behavior. Offline-first without a backend: a local-first PWA architecture you can trust
3 The Human UX Trauma-informed interaction, coercion resistance, and protective friction. Trauma-Informed React Hooks
4 The Artifacts Export boundaries, release proofs, and evidence users can carry out of the app. ProofVault as a Release Artifact: Turning Trust Into Something You Can Verify

Layer 0: The Protocol

This is the doctrine layer. Read this path first if you want the argument underneath the rest of the system.

  1. Architecting for Vulnerability: Introducing Protective Computing Core v1.0
  2. Protective Computing Is Not Privacy Theater
  3. The Stability Assumption: The Hidden Defect Source
  4. Protective Computing Canon v1.0 is now DOI-backed

Layer 1: The Cryptography

This layer answers the hard question: what makes the system harder to seize, subpoena, or casually over-collect?

  1. Client-Side Encryption for Healthcare Apps
  2. If Your Health App Can't Explain Its Encryption, It Doesn't Have Any
  3. No Backend, No Excuses: Building a Pain Tracker That Doesn't Sell You Out
  4. Keeping Your Health Data Out of Court

Layer 2: The Resilience

This layer covers degraded-mode behavior. It is where the system proves it still works when signal, battery, or continuity starts collapsing.

  1. Offline-first without a backend: a local-first PWA architecture you can trust
  2. Three storage layers in an offline-first health PWA: state cache vs IndexedDB vs encrypted vault
  3. Service workers that don't surprise you: deterministic caching for offline-first PWAs
  4. Service Worker Failure Modes in Offline-First PWAs
  5. Rollback Patterns in Offline-First PWAs

Layer 3: The Human UX

This layer explains why the interface is allowed to resist speed, reduce pressure, and adapt to instability instead of optimizing for throughput.

  1. Trauma-Informed React Hooks
  2. Trauma-informed UX + accessibility as architecture (not polish)
  3. The Micro-Coercion of Speed: Why Friction Is an Engineering Prerequisite
  4. Coercion-Resistant UX: Designing Interfaces That Don't Pressure Users Under Stress

Layer 4: The Artifacts

This layer is where claims become evidence. If you want to know whether the system can produce legible proof without leaking everything else, read here.

  1. Exports are a security boundary: the moment local-first becomes shareable
  2. WorkSafeBC-oriented workflows without overclaims: structured summaries, careful language
  3. Quality gates that earn trust: checks you can run, not promises you can't
  4. ProofVault as a Release Artifact: Turning Trust Into Something You Can Verify
  5. Maintaining truthful docs over time: how to keep security claims honest

Two series, two jobs

Use the series pages as operating modes, not just categories.

If you want context first before the protocol map, start with
Two People, Same Body,
the origin story behind why Pain Tracker was built.

What this front door is doing now

This index is meant to move the catalog away from a chronological feed and toward a structured engineering protocol.
The point is not to explain taste. The point is to show which layer a post belongs to, what threat model it addresses, and what kind of proof it contributes.

The next gaps to close are two bridge posts that turn the protocol map into a cleaner sequence.
The Layer 1 bridge belongs immediately after the cryptography posts above.
The working title is: Subpoena-Proofing by Design: Why Real Zero-Knowledge Has No Back Door.

The Layer 4 bridge belongs immediately after the artifact and WorkSafeBC workflow posts above.
The working title is: Bureaucratic Combat: Turning Pain Into a WorkSafeBC-Ready Audit.

Route into the proof network

Start with CrisisCore Systems
crisiscore-systems.ca

Read the Protective Computing library
protective-computing.github.io

View 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 not a claim of perfect security.
This is infrastructure intended to help people track reality without surrendering unnecessary control.

If you are building something similar

Which layer is still weakest in your system: doctrine, cryptography, resilience, human UX, or artifacts?

Support this work

Top comments (0)