DEV Community: CrisisCore-Systems

Testing IndexedDB Schema Migrations in Offline-First PWAs

CrisisCore-Systems — Tue, 19 May 2026 16:00:00 +0000

Migration behavior in production build: download a private pain tracker

This is the migration-safety stop in the failure-mode and testing path.

Read first:
Service Worker Failure Modes in Offline-First PWAs
and
Rollback Patterns in Offline-First PWAs

Then continue to:
Offline Queue Replay and Idempotency in Offline-First PWAs

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

If you want the privacy boundary that makes migration fidelity matter, add:
Trust Boundaries in Client-Side Health Apps

IndexedDB migrations look straightforward right up until real users keep
their data for months.

In a fresh test database, everything feels clean.

The new schema opens.
The upgrade callback runs.
The happy path passes.

That is the easy part.

The hard part is what happens when the app updates on a device carrying
old drafts, stale references, interrupted writes, half-finished queues,
or records created by code you already forgot you shipped.

That is where migration testing stops being a storage detail and starts
becoming a trust boundary.

Because once an offline-first app stores real user history locally, a
bad migration does not just break a test.

It rewrites memory.

The real risk is not schema change

The real risk is silent damage.

If the app crashes loudly during an upgrade, at least you know something
went wrong.

If the app opens successfully but drops a field, misreads a record,
or detaches related data from its references, that is worse.

Now the system looks functional while carrying false history forward.

That is why migration testing has to check more than "did the database
open?"

It has to check whether meaning survived.

Fresh databases prove almost nothing

One of the easiest ways to lie to yourself is to test only against a
brand-new database.

That tells you the latest schema can initialize.

It does not tell you whether upgrades are safe.

Real migration testing needs historical fixtures.

Version 1 data.
Version 2 data.
Malformed edge cases you know used to exist.
Partially populated records.
Unexpected nulls.
Old optional fields that later became required.

If you do not test against old shapes, then you are not really testing
migration behavior.

You are testing installation.

Those are not the same thing.

Test the shape and the meaning

A migration test should not stop at structural validity.

Sure, you should verify that records match the new schema.

But that is only the first layer.

You also need to verify that the record still means what it meant before
the upgrade.

Did drafts stay attached to the right entity?
Did timestamps remain interpretable?
Did queued actions still point to the correct records?
Did attachments keep their references?
Did flags and defaults preserve prior user intent rather than rewriting
it?

Schema correctness is not enough if the migration preserved bytes but
lost the user's history.

Partial failure is where real migrations are judged

This is the part teams skip because it is awkward.

What happens if the upgrade starts and does not finish cleanly?

What happens if one object store changes and the next one fails?

What happens if the browser is closed mid-upgrade?

What happens if the app throws after rewriting records but before
finalizing related references?

If your tests never model partial failure, then your migration story is
too optimistic for offline-first software.

Real devices lose power.
Tabs get killed.
Users close the app.
Storage operations throw.

The migration path has to survive ugly timing, not just ideal timing.

Long-delayed clients are not edge cases

One of the hardest realities in offline-first systems is the user who
skips several versions.

They do not upgrade from version 5 to version 6.

They upgrade from version 5 to version 11.

That means migration testing cannot assume every intermediate release ran
in order on the device.

You need to know whether:

the upgrade path can move across multiple versions safely,
the app can still interpret very old local records,
old feature data can be preserved or explicitly retired without ambiguity,
queued work created under older assumptions still degrades safely.

If your migration tests only cover the immediately previous version, you
are testing the release train, not the real world.

Test against bad data on purpose

A protective migration suite should include ugly fixtures intentionally.

Not because the app should accept every corrupted record forever.

Because real local data is messy.

Browsers crash.
Old bugs leave strange shapes behind.
Optional fields become required later.
Manual imports create awkward combinations.

Migration tests should include:

missing fields,
extra fields,
invalid enum values,
orphaned references,
stale queue entries,
duplicate identifiers,
records that are valid enough to exist but not clean enough to trust.

That is where you learn whether the migration fails soft or silently
corrupts the state model.

Rollback safety belongs in migration testing too

Migration testing is not only about moving forward.

It is also about understanding what happens if the release needs to be
pulled back.

Can the previous version tolerate the newly written records for one
release window?

If not, is that explicit in the rollout plan?

Do you snapshot before destructive rewrites?

Do you retain enough metadata to restore meaning if the migration proves
wrong in the wild?

If those answers are unknown, the migration is not well tested enough to
ship confidently.

A good migration test suite usually covers five things

1. Fresh install

Prove the newest schema initializes correctly.

2. Upgrade from every supported historical version

Prove old local states land in the new shape without losing meaning.

3. Partial failure and interruption

Prove the app fails safely when upgrade steps do not complete.

4. Compatibility of related state

Prove queues, drafts, references, and attachments still line up after the
migration.

5. Recovery behavior

Prove the app can explain what happened, preserve what is safe, and avoid
continuing with corrupted assumptions.

That is a much higher bar than a single upgrade callback test.

It is also much closer to reality.

The user never sees the migration directly

That is what makes this dangerous.

Users do not watch the upgrade transaction happen.

They only see the aftermath.

Their notes are there or not.

Their queue resumes cleanly or not.

Their saved state still makes sense or not.

So the migration test suite is one of the few places where you can catch
history loss before it becomes part of the product.

That is why this is not just a database concern.

It is product integrity work.

The deeper rule

Offline-first apps have to carry old local reality forward without
falsifying it.

That means schema migrations need more than correctness on a clean
machine.

They need proof under messy data, delayed upgrades, partial failure, and
mixed-version history.

If the migration test suite cannot demonstrate that, then the app is not
really proving upgrade safety.

It is just hoping the user's device is kinder than production usually is.

Next in the failure-mode path:
Offline Queue Replay and Idempotency in Offline-First PWAs

Support this work

Sponsor the project (primary): https://paintracker.ca/sponsor
Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker

Subpoena-Proofing by Design: Why Real Zero-Knowledge Has No Back Door

CrisisCore-Systems — Fri, 15 May 2026 16:00:00 +0000

User-controlled export boundary: WorkSafeBC pain documentation tool

If you want the short Layer 1 path into this argument, read these first:

This piece is the bridge between the polemic and the implementation.

If you want privacy-first, offline health tech to exist without surveillance funding it: sponsor the build → https://github.com/sponsors/CrisisCore-Systems

When people say they want software to be subpoena-proof, they usually mean
something too vague to build and too dramatic to defend.

Not invincible.

Not outside the law.

Not protected from a compromised device, a coerced unlock, or a user who
chooses to export their own records.

Something narrower than that, and more real.

It means reducing what the software operator can produce in the first place.

Boundary notes, because truth matters

This is not legal advice.
This is not a claim of perfect secrecy.
This is not a claim that local encryption defeats malware, device seizure after unlock, or physical coercion.

What it is claiming is narrower and more important.

If the architecture keeps plaintext off your servers, keeps keys out of your
custody, and avoids privileged recovery paths, you have materially less to hand
over when somebody comes asking.

That is what subpoena-proofing by design means here.

Most subpoenas are custody problems before they are cryptography problems

People love to jump straight to the algorithm.

AES-GCM.
PBKDF2.
Key sizes.
Iteration counts.

Those matter.

But the first question is not which cipher you used.

The first question is who has the data.

If the application server stores plaintext, mirrored exports, recovery keys,
support snapshots, or admin-readable backups, then the argument is basically
over. The system may be encrypted at rest in some narrow operational sense,
but the operator still sits inside the custody chain.

That means the operator can be compelled.

And if the operator can be compelled, the user is not relying on math. They are
relying on policy, promises, and the hope that the organization holding the
data will defend them better than it defends itself.

That is not zero-knowledge.

That is delegated trust with nicer copy.

Zero-knowledge is a custody architecture, not a badge

The phrase gets abused constantly.

Sometimes it means end-to-end encryption.
Sometimes it means encrypted sync.
Sometimes it just means the company wants to sound careful while still keeping a reset path and a support console behind the curtain.

For sensitive personal records, I use a stricter test.

Zero-knowledge means the operator does not hold what would be required to reconstruct the user's plaintext records in ordinary service operation.

That usually implies at least four things.

The user secret is derived locally, not issued from the server.
The encryption key boundary stays on the device, or at minimum outside the operator's unilateral custody.
Plaintext records are not silently mirrored into operator-readable storage for convenience.
There is no privileged "forgot password" or admin recovery path that secretly bypasses the whole story.

Miss any of those and the zero-knowledge claim starts collapsing.

The forgot-password flow is usually the confession

This is where a lot of products accidentally tell on themselves.

If the app can reset the one thing that protects the records, you need to ask what exactly is being reset.

There are only a few real possibilities.

Either:

the operator can reissue access to readable data,
the operator can re-wrap the stored key material,
or the operator never truly surrendered custody in the first place.

That does not automatically make the product malicious.

It does make the phrase zero-knowledge very hard to defend.

In a local-first architecture, the absence of a universal recovery flow is not a UX omission.

It is often the cost of honesty.

If the passphrase-derived key never leaves the device and the operator does not keep a second route around it, then some forms of recovery stop being available.

That is frustrating.

It is also what makes the custody boundary real.

Local derivation changes what the operator can disclose

This is where the cryptography starts to matter.

If the user secret is stretched locally into a key and that key is used to unwrap or derive local encryption capability, the operator is no longer sitting on a central decrypt button.

At a high level, the shape looks like this:

const passphraseMaterial = await crypto.subtle.importKey(
  'raw',
  new TextEncoder().encode(passphrase),
  'PBKDF2',
  false,
  ['deriveKey']
);

const localKey = await crypto.subtle.deriveKey(
  {
    name: 'PBKDF2',
    salt,
    iterations: 310000,
    hash: 'SHA-256',
  },
  passphraseMaterial,
  { name: 'AES-GCM', length: 256 },
  false,
  ['encrypt', 'decrypt']
);

The point of a pattern like this is not that PBKDF2 is magical.

The point is that the derivation happens on the user's side of the boundary.
The operator is not issuing a reusable server-side decrypt capability every
time the account opens.

That changes the disclosure story.

If asked for the records, the operator may be able to produce:

application source code,
architectural documentation,
exported audit evidence the user explicitly chose to share,
encrypted blobs if any exist in transmitted or backed-up form,
and high-level metadata that was actually retained.

What the operator cannot honestly produce is plaintext it never possessed.

That is the design win.

Subpoena resistance starts with non-possession

This is the part that matters more than the slogan.

A protective system should try to make non-possession structurally true.

Not as a policy preference.

As an architectural fact.

No backend for the core record path.
No silent cloud copy of health notes.
No analytics stream full of intimate behavioral events.
No support bundle that scoops up body logs and free text because debugging was easier that way.
No operator-held recovery secret waiting to become the real product.

Once those surfaces exist, they will eventually be demanded by somebody.

That is why local-first matters here. It is not just a resilience property. It is a disclosure minimization property.

Exports are where zero-knowledge can be quietly undone

A lot of teams get the storage story mostly right and then destroy it at the edge.

They encrypt the vault.
They derive keys locally.
They avoid server custody.

Then they add:

a plaintext export emailed through a support workflow,
an unencrypted backup written to a cloud folder by default,
a PDF artifact that leaks more than the user intended,
or a debug mode that bundles sensitive records for troubleshooting.

That is not a small side issue.

That is the boundary reopening.

Zero-knowledge claims only stay credible if the export surface is treated as a separate trust boundary with its own minimization rules, user control, and honest warnings.

If you want the full argument there, read Exports are a security boundary: the moment local-first becomes shareable.

If the boundary cannot be audited, it is not real

There is a simple reason I do not trust zero-knowledge as a homepage adjective.

It is too easy to say.

The only version that matters is the one somebody else can inspect.

That means the system should be able to explain:

where plaintext exists,
where it does not,
where keys are derived,
where keys are stored or wrapped,
what metadata is retained,
what exports look like,
what recovery is impossible by design,
and what threat model the boundary is actually defending against.

If the answer is "trust us," the answer is no.

If the answer is "here is the code path, the storage model, the failure mode, and the limit," now we are at least speaking honestly.

What this does not protect you from

This boundary is strong for some threats and weak for others.

It helps against operator overreach, central breach surfaces, routine legal demand directed at the service, and the quiet accumulation of extra copies nobody needed.

It does not solve:

a compromised operating system,
spyware or malicious extensions,
a device seized while already unlocked,
screenshots or shoulder surfing,
a user who exports and shares plaintext,
or legal compulsion aimed directly at the person holding the device.

That limitation does not make the architecture fake.

It makes it specific.

Specific is better than theatrical.

The tradeoff is the proof

The technical reality of zero-knowledge is less glamorous than the sales pitch.

It means accepting tradeoffs.

Harder recovery.
Less centralized observability.
Fewer support shortcuts.
More careful export design.
More pressure on documentation to stay truthful.

Good.

Those costs are not a UX accident.

They are exactly what keep the boundary from being imaginary.

If a system wants all the convenience of centralized custody and all the
branding benefits of zero-knowledge at the same time, it is usually hiding the
second path somewhere.

That hidden second path is the whole problem.

The protective test

Protective Computing asks a blunter question than normal security marketing.

When the user is in pain, under administrative pressure, trying to document reality, and one institutional letter could force disclosure, what does the system make possible?

Can the operator read the record?
Can the operator reset the boundary?
Can the operator quietly centralize the data later?
Can the operator explain what would and would not exist if somebody came with paperwork?

If the answer is clear, limited, and technically enforced, the system is earning something.

Not invulnerability.

Legitimacy.

That is the standard.

Not whether the homepage sounds careful.

Whether the custody chain stays narrow when the pressure becomes real.

Support this work

Sponsor the project (primary): https://github.com/sponsors/CrisisCore-Systems
Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker

Rollback Patterns in Offline-First PWAs

CrisisCore-Systems — Tue, 12 May 2026 16:00:00 +0000

Verify rollback assumptions: private offline pain tracking app

This is the second stop in the failure-mode and testing path.

Read first:
Service Worker Failure Modes in Offline-First PWAs

Then continue to:
Testing IndexedDB Schema Migrations in Offline-First PWAs

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

If you want the trust boundary underneath rollback risk, add:
Trust Boundaries in Client-Side Health Apps

Rollback sounds simple until the app keeps state locally.

If all you have is a server and stateless clients, rollback usually means
deploy the old version and move on.

That is not what happens in an offline-first system.

In an offline-first app, the old version is still running in someone's
tab. The new version may already be installed in a waiting service
worker. The local database may already have been migrated. A queue of
pending writes may have been created under assumptions the rollback does
not understand.

So when people say "just roll it back," what they often mean is:

put old code back on the server and hope the client does not notice.

That is not a rollback strategy.

That is a prayer circle with version numbers.

Rollback stops being simple the moment data moves locally

The hard part is not code deployment.

The hard part is state continuity.

Once the app stores drafts, queues, attachments, preferences, IndexedDB
records, background sync state, or cached workflows on the device, the
client has its own history.

That history does not disappear just because you redeployed yesterday's
bundle.

Now the rollback has to answer harder questions.

Can the old code read the records the new code already wrote?
Can the old queue processor safely replay pending mutations?
Can the old UI interpret the local state it is about to render?
Can the old service worker serve assets that still match the current
shell?

If the answer is no, then you did not roll back.

You only changed one side of a split system.

The real danger is mixed-version reality

Offline-first systems do not roll forward or backward in a single clean
motion.

They overlap.

One user is still on the old app.
One user already activated the new service worker.
One user has the new schema but the old tab still open.
One user went offline during the bad deploy and comes back after the
rollback.

That means both versions can be real at the same time.

And that is the condition your rollback plan actually has to survive.

Not the clean lab scenario.

The overlap.

Because overlap is where silent damage happens.

The app does not necessarily explode.

It just starts reading state with the wrong assumptions.

That is how records get dropped, queues get replayed twice, attachments
lose references, and local history becomes less trustworthy than the
server version you were trying to save.

The first rule: not every migration is reversible

Teams get into trouble when they treat rollback as if every schema
change can be undone just because the code can be redeployed.

That is false.

Some migrations are additive.

Those are the easy ones.

Add a field.
Add an index.
Introduce metadata the old code can ignore.

Other migrations are destructive.

They rename fields, collapse structures, normalize records into new
tables, rewrite identifiers, or delete legacy forms the old client still
expects.

Those changes may not have a safe reverse path.

And if they do not, the rollback plan has to say that honestly.

You do not get to call a migration reversible just because you wish it
were.

Good rollback plans start before the deploy

Rollback is designed before the release, not during the outage.

If the only time you ask how to recover is after the migration already
ran in the wild, you are late.

A safer release process asks upfront:

Is this migration additive or destructive?
Can old code tolerate the new records for one release window?
Can new code tolerate old records for one release window?
Is there a compatibility bridge period?
Do we need a snapshot or export before mutation?
What happens to queued writes created during the bad release?
Can the service worker keep serving a safe shell if activation is blocked?

That is what real rollback engineering looks like.

Not confidence.

Preparation.

Compatibility windows matter more than clever rollbacks

The safest rollback is often the one you barely need because versions
were built to overlap safely.

That means one version should usually tolerate the next version's data
shape for a while.

And the next version should usually tolerate the previous version's data
shape for a while.

That window matters.

Because the world does not update at once.

Tabs stay open. Devices go offline. Queues wake up late. Background sync
replays stale work. Service workers activate at inconvenient times.

If the system requires atomic upgrade across all clients to remain safe,
the system is too brittle for the environment it claims to support.

Queue safety is part of rollback safety

This part gets missed constantly.

Offline-first apps do not just store data. They store pending intent.

Queued writes, unsent forms, attachment uploads, background sync jobs,
retry tokens, optimistic mutations. Those are all promises the app made
to the user.

If rollback ignores the queue, the app can come back in a state where:

old mutations replay against the wrong schema,
the same mutation gets applied twice,
a retried request becomes destructive,
records created by the bad version can no longer be reconciled.

That is why rollback-safe systems need idempotent writes, durable queue
metadata, and enough version context to decide whether a pending action
is still safe to replay.

Otherwise rollback becomes replayed corruption.

Backup is not optional if the migration risk is real

If a release can damage meaningful local data, then backup is part of the
release boundary.

Not an extra.

Not a future improvement.

Part of the boundary.

That does not mean every app needs a dramatic export ritual before every
deploy.

It does mean critical local data should have some recovery path if a bad
migration lands.

That could mean:

a local snapshot before destructive migration,
a journal of transformed records,
an export path that preserves restore fidelity,
a recovery mode that can rehydrate from last-known-good data.

What matters is not the mechanism.

What matters is that the user's history is not one failed deploy away
from being rewritten into nonsense.

Rollback UI should tell the truth

When recovery happens, the interface has to be honest about what is
going on.

Not vague.

Not soothing.

Honest.

The user needs to know things like:

This update was not applied safely.
Your local data is intact.
Some pending changes are being held until compatibility is restored.
You may need to refresh.
Here is what was preserved.
Here is what still needs review.

That is the right kind of friction.

Because when the app has already lost certainty, pretending everything
is seamless only turns a deployment issue into a trust issue.

Service workers need rollback discipline too

Service workers make rollback harder because they extend the release
surface.

Now you are not only thinking about bundles and local data.

You are thinking about:

whether a bad worker should activate,
whether a waiting worker should be abandoned,
whether versioned caches still point at a safe shell,
whether stale assets keep a broken release alive longer than intended.

A protective system treats the worker as part of rollback design, not a
separate browser detail.

If the worker can keep handing out a poisoned shell after rollback, then
the rollback is incomplete.

What migration guardrails actually look like

Good migration guardrails are not exotic.

They are disciplined.

They look like:

explicit schema versions,
compatibility checks before mutation,
additive changes before destructive changes,
reversible steps where possible,
snapshots before risky rewrites,
idempotent queue replay,
version-aware recovery logic,
refusal to continue when safety cannot be proven.

That last one matters.

Sometimes the most protective thing the app can do is stop.

Not because stopping is elegant.

Because silent corruption is worse than visible interruption.

The standard is not "Can we revert the deploy?"

That is too shallow.

The real question is:

Can this system recover from a bad release without rewriting the user's
local history into something false?

That is the standard.

Not whether CI is green.
Not whether the old container can still boot.
Not whether the dashboard says rollout complete.

Whether the user's data, pending intent, and local continuity survive the
mistake.

That is what rollback has to protect.

The deeper rule

Offline-first apps do not get to treat rollback as a server-only event.

They carry state in the wild.

That means recovery has to be designed for mixed versions, delayed
clients, local data history, and queued intent that outlives the deploy.

If your rollback plan only restores the code and leaves the user's local
reality to fend for itself, then it is not really recovery.

It is abandonment with version control.

Next in the failure-mode path:
Testing IndexedDB Schema Migrations in Offline-First PWAs

Support this work

Sponsor the project (primary): https://paintracker.ca/sponsor
Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker

Privacy-first, offline-capable, trauma-informed, open-source health tools should be the default

CrisisCore-Systems — Sat, 09 May 2026 02:04:25 +0000

Try the local-first flow: private offline pain tracker

Privacy-first, offline-capable, trauma-informed, open-source health tools should be the default

(Version 5: Coercion-resilient consent + implementation science completion)

If you want privacy-first, offline health tech to exist without surveillance funding it: sponsor the build → https://github.com/sponsors/CrisisCore-Systems

Most pain-tracking apps I tried made me want to throw my phone across the room.

The evidence for pain diaries is strong, and chronic pain is everywhere, but most tools feel like surveillance systems pretending to be care. They prioritize data extraction, cloud integration, and paternalistic UX over privacy, autonomy, and trauma awareness.

Drawing on the design choices, architecture, and open-source ecosystem around PainTracker.ca (plus the Dev.to build logs, the X account, and the CrisisCore-Systems GitHub org), I argue that privacy-first, offline-capable, trauma-informed, open-source tools should become the default standard in digital health. But this paper also makes a harder claim that earlier drafts left implicit: architecture that protects against corporate surveillance can still fail under institutional power. If patient-controlled sharing becomes a condition of credibility, medication continuation, or care access, “consent” can degrade into coerced disclosure. A trauma-informed system cannot define consent solely as a UI action. It must account for coercive contexts and implement workflows that preserve autonomy under pressure.

Positionality and method

(Why this paper is written this way)

I write as both a chronic pain patient and a systems designer building through fluctuating capacity, including flare days where attention collapses, fine motor control degrades, and “one more form” is not a reasonable ask. These constraints are not aesthetic preferences; they come from repeated contact with the failure modes of mainstream tools in low-resource, high-stress conditions. That lived contact is also a form of stress testing: it reveals where designs break first, and who pays the cost.

This is a design-based argument grounded in lived experience and a public, inspectable implementation. It treats architecture and interaction design as evidence about what is technically feasible and what harms are structurally produced (or prevented) by default patterns in digital health. It does not claim that randomized controlled trials (RCTs) are “wrong” as a general epistemological framework; instead, it argues that trauma-informed tools require evaluation regimes that can measure power, coercion risk, and capacity collapse—outcomes that standard RCT endpoints often exclude or flatten. RCTs may remain useful for specific clinical endpoints, but they are insufficient as the sole legitimacy structure for tools whose core harms (or safety) emerge from context, power asymmetry, and implementation reality.

Abstract (250–300 words)

Background: Pain diaries and longitudinal symptom tracking are widely supported in chronic pain care. However, many mainstream pain-tracking apps are built around cloud dependence, account-centric workflows, and engagement mechanics that can feel coercive or unsafe—especially for people living with trauma. Empirical audits have documented privacy risks in accredited health apps, including opaque data transmission and weak safeguards (Huckvale et al.), and public polling shows widespread concern about health-app privacy (Teale).

Objective: To argue that privacy-first, offline-capable, trauma-informed, open-source architectures should be treated as the default standard for digital health tools—and that this standard must include coercion-resilient consent workflows to prevent institutional leverage from replacing corporate surveillance.

Methods: Using PainTracker.ca as a concrete countermodel (a progressive web app with offline-first behavior, local-only encrypted storage, no default telemetry, and crisis-aware UX), this paper analyzes how architectural choices and interaction patterns shift privacy risk, autonomy, psychological safety, and crisis usability compared with typical cloud-centered pain apps documented in prior audits. It also extends the analysis to implementation science: how patient-controlled sharing functions in time-pressured care, and how power asymmetry can convert “voluntary sharing” into coerced disclosure.

Results: Local-first architectures reduce structural privacy risk by removing centralized data hoards and third-party analytics pathways. Trauma-informed, crisis-aware UX improves usability under low-capacity conditions. However, patient-controlled sharing introduces a remaining vulnerability: in clinical contexts, dependency and gatekeeping can make export actions effectively mandatory. This paper therefore specifies coercion-resilient consent principles (minimum-necessary summaries, layered disclosure, refusal-safe alternatives, time-bounded access, and clinic-realistic implementation kits) and proposes measurable endpoints for coercion risk.

Conclusions: Privacy-first, offline-capable, trauma-informed, open-source tools should be a normative baseline for evaluation, procurement, and funding—paired with coercion-resilient clinical workflows that preserve autonomy under pressure. The question is no longer whether such tools are possible; it is whether institutions will choose them and protect patients from both corporate surveillance and institutional leverage.

Keywords

privacy-by-design; offline-first; trauma-informed design; chronic pain; progressive web apps; implementation science; coercion-resilient consent

I. Introduction

Digital health is marketed as a future where granular, real-time data powers individualized treatment. If that promise were real, chronic pain should be one of its clearest success stories. In Canada, the Canadian Pain Task Force estimates that about 7.6 million people—roughly one in five—live with chronic pain (Health Canada). Chronic pain is not only common; it is often lifelong and tightly bound up with disability, depression, substance use, and socioeconomic precarity (Health Canada). On paper, digital tools for tracking symptoms, function, and treatments should anchor humane, data-informed pain care.

The market moved fast. App stores are full of pain trackers, migraine diaries, and chronic illness apps with tens or hundreds of thousands of downloads. One Android pain app lists 100K+ downloads, indicating real demand (CareClinic). Clinicians are also nudged toward electronic questionnaires and patient-reported outcome measures. At UW Medicine’s Center for Pain Relief, the PainTracker questionnaire is completed prior to visits to monitor pain, mood, sleep, and function over time (University of Washington, “PainTracker”). This looks like an evidence-based success: pain research meets ubiquitous personal computing.

My lived experience said otherwise—and it aligns with known barriers to incorporating diary data into clinical reality. Marceau et al. report that physicians cited being too busy and often forgetting to incorporate diary summary data into visits (Marceau et al.). That “too busy” constraint is not a minor detail; it shapes what kinds of tools can survive implementation. As someone with chronic pain and trauma, I found many tools unusable during flares, cognitively overwhelming, and psychologically unsafe. Many demanded account creation, passwords, and constant connectivity precisely when I was exhausted, dissociated, or in severe distress. Others nagged me with notifications and streak metrics that felt less like support and more like compliance enforcement. The underlying message was clear: perform your pain inside our system, on our terms, or your pain does not count.

At the same time, empirical work shows that many health apps are structurally risky from a privacy perspective. In a systematic assessment of apps previously listed in the UK NHS Health Apps Library, Huckvale and colleagues found serious gaps: 89% (70/79) of apps transmitted information to online services; among apps sending identifying information, 20% (7/35) had no privacy policy and 66% (23/35) did so without encryption; and many privacy policies failed to clearly describe what data was included in transmissions (Huckvale et al.). Public surveys show a matching pattern: 64% of U.S. adults were concerned about the privacy of their health information on an app (Teale). Over and over, the system asks people in pain to trade away privacy and autonomy for hypothetical clinical benefit.

PainTracker.ca is a deliberate refusal of that trade. It is a privacy-first, offline-capable, trauma-informed progressive web app (PWA) that runs entirely in the browser and stores encrypted data locally rather than uploading it to remote servers. The codebase is open-sourced under the MIT license in the CrisisCore-Systems GitHub org (CrisisCore-Systems / pain-tracker). I built it for people like me: chronic pain patients and trauma survivors who need something that still works during their worst hours without quietly turning their suffering into somebody else’s data asset (CrisisCore Systems, “Trauma-Informed Design”; “Building a Pain Tracker”).

Two questions drive this paper:

How does PainTracker.ca respond—architecturally, ethically, and experientially—to the failures of mainstream digital pain tools?
What additional requirements (implementation science, coercion-resilient consent) are necessary so that patient-controlled sharing does not become coerced disclosure in clinical contexts?

II. Chronic pain and why tracking still matters

A. Chronic pain as structural public health crisis

Chronic pain is a structural public health problem, frequently interwoven with mental health conditions and substance use, and disproportionately affecting people facing marginalization and precarity (Health Canada). Many report being disbelieved or dismissed; that stigma can become a secondary trauma and distort care (Health Canada). Meanwhile, health systems remain optimized for acute problems and short visits, producing thin snapshots: a single 0–10 rating plus a rushed verbal summary of weeks of symptoms.

This is where tracking matters. Longitudinal, structured data can bridge the gap between lived reality and clinical decision-making. When diaries are done well, day-to-day experience can arrive in the clinic in a form another human can interpret and act on.

B. Why diaries and systematic tracking still matter

Clinicians have long used pain diaries and questionnaires to record intensity, location, timing, and response to interventions. Early electronic diaries attempted to reduce recall bias, but implementation barriers persisted—especially time pressure and workflow mismatch (Marceau et al.).

Modern instruments like UW’s PainTracker questionnaire ask patients to report regularly on pain intensity, interference, mood, sleep, and other domains and provide clinicians visual trajectories to support decisions (University of Washington, “PainTracker”; CoMotion). Educational material aimed at patients echoes the same logic: consistent logging can help identify triggers and improve management by correlating symptoms with activities, medication, and context (“Using a Pain Diary”).

Three points are difficult to dispute:

Pain is variable; a single rating cannot capture it.
Tracking can be empowering when it reveals actionable patterns.
Clinicians can make better decisions when they can see structured trends.

So the question is not whether to track, but how to architect tracking tools that do not reproduce surveillance, coercion, and trauma.

C. Where paper and first-generation digital tools hit their limits

Paper diaries are easy to lose and hard to analyze. Early electronic tools were often bolted onto clinic workflows in ways that clinicians experienced as clumsy or time-consuming (Marceau et al.). Smartphones looked like the fix. In practice, many first-wave pain apps reproduced old problems and added new ones: bright glare, dense layouts, forced sign-up before value, long intake forms, tiny tap targets, multi-step flows that assumed stable attention (CrisisCore Systems, “Building a Pain Tracker”). During a flare—when pain, fatigue, and cognitive load spike—these are not inconveniences; they are hard stops.

Once diaries moved into the general app economy, another risk became unavoidable: intimate logs now lived on remote servers controlled by entities with incentives users have no reason to trust. A pain diary is not a step counter. It captures what someone did, what they took, how they slept, what they felt, and sometimes whether they wanted to live. Handing that over to someone else’s infrastructure is not a neutral act.

III. What mainstream digital pain apps normalize

A. Surveillance as default architecture (even in “trusted” app ecosystems)

Most pain apps live inside commercial ecosystems where sustainability is not primarily user payment but data-driven product loops. Analytics dashboards, third-party SDKs, centralized databases, and background telemetry follow naturally when users are treated as behavioral data streams. Huckvale et al.’s audit is especially damning because it examined apps in an accredited library context—meaning these failures are not limited to fringe apps; they can persist even under formal approval regimes (Huckvale et al.).

Pain data are especially sensitive. They intersect with disability claims, mental health, opioid prescribing, employment, and trauma histories. In hostile hands, such logs can be used to deny benefits, question credibility, or surveil behavior. Yet in typical architectures, large-scale centralization and long-term retention are treated as non-negotiable.

B. Why people distrust these tools

Public distrust is rational. A survey reported that 64% of U.S. adults were concerned about the privacy of their health information on an app (Teale). For people living with chronic pain, disability, or trauma, the distrust can be sharper: logs can be used against them—by employers, insurers, agencies, or even clinicians. When privacy policies are vague or missing and audits show undisclosed transmission, fear is not paranoia; it is pattern recognition (Huckvale et al.).

C. Trauma-uninformed UX as design harm

Even if privacy were perfect, many pain apps fail at the UX level. Chronic pain brings fatigue, cognitive fog, and unstable attention. Trauma layers in hypervigilance, shame, avoidance, and sudden drops in capacity. Tools that demand long sequences of micro-decisions or sustained focus do not match this reality.

Trauma-informed design emphasizes choice, transparency, emotional safety, and non-coercion (Danquah and Addae). Many apps violate these principles through streaks, gamified reminders that frame lapses as failure, mandatory long forms before value, and intrusive prompts that demand logging on the app’s schedule rather than the user’s.

D. Clinician tools and institutional blind spots

Institutional tools like UW’s PainTracker operate inside EHR-linked regimes and generally have stronger governance than consumer apps (University of Washington, “PainTracker”; CoMotion). But their architectures still center institutional needs: centralized dashboards, billing codes, and quality metrics. Patients often become data providers for the system, with limited control over retention, export, or downstream use.

PainTracker.ca answers a different design question: How do we build something that primarily serves the person using it—and only secondarily, and on their terms, anyone else?

IV. PainTracker.ca as countermodel: architecture-as-argument

Table 1. Mainstream defaults vs PainTracker.ca (countermodel)

Design axis	Mainstream pain apps (typical)	PainTracker.ca (countermodel)	Real-world impact on vulnerable users
Data location	Centralized backend by default	Local-only by default (on-device)	Centralization amplifies breach, misuse, and secondary harm risk; local-first reduces blast radius
Connectivity	Online-first; degraded offline	Offline-first; identical offline	Crisis days and unstable housing often mean unstable connectivity; offline-first preserves access
Identity	Accounts/login as gate	No account required	Credential friction can block use during flares; no-login lowers abandonment
Data flow	Telemetry/analytics SDKs common	Optional anonymous usage analytics (deploy-configured)	Reduces “quiet extraction” when disabled; requires clear defaults and user control when enabled
Consent	Broad, ongoing, hard to revoke	Explicit, user-triggered export/share	Shifts control to user, but requires coercion-resilient workflows in clinical contexts
Crisis usability	Dense forms, streaks, nudges	Low-cognitive-load flows; crisis-aware simplification	Respects capacity collapse; reduces shame cycles and drop-off
Trust model	“Trust the vendor”	Inspectable open-source code + minimal exposure	Verifiability substitutes for trust; supports accountable adoption

A. Origin and non-negotiable constraints

PainTracker.ca began with frustration and a simple threat to myself: if no existing app is livable, build one that is. Under the CrisisCore-Systems umbrella, I set hard constraints:

The app must function fully offline.
Network calls should be optional and user-controlled; avoid transmitting sensitive content by default.
The interface must be usable under low-capacity conditions.
The code must be open so claims are inspectable.

These constraints are documented in the build logs and essays (“Building a Healthcare PWA”; “Building a Pain Tracker”; “Trauma-Informed Design”).

B. Architectural choices: offline-first, local-only, no default telemetry

The central move is straightforward: treat the device as the system. A service worker caches the app shell; local storage (eg, IndexedDB) holds user data; behavior is identical online or offline. The repository includes optional analytics and other network-capable features that can be enabled/disabled; the privacy goal is to keep sensitive content local by default and make any sharing or telemetry explicit and minimal.

This design removes entire risk classes:

no centralized database to breach or misconfigure
no vendor unilateral policy shift that repurposes user logs
no bulk dataset to monetize

The trade-offs are real: no automatic multi-device sync, no easy EHR integration, and no vendor-managed backups. PainTracker.ca chooses explicit user-controlled export as the ethical default.

C. Trauma-informed and crisis-aware UX (local adaptation without spying)

Architecture is the skeleton; UX is the nervous system. The interface is designed for the possibility that the user is not okay:

reduced glare and visual overload
large tap targets
shallow navigation
short flows where only essential questions show by default

PainTracker.ca also experiments with a local rules engine meant to detect “strain” without surveillance. It uses only local signals (eg, spikes in pain scores and skipped entries) and adapts the interface locally. A simple illustrative rule might be: multiple days of skipped entries combined with high recent pain scores triggers a “simplify mode” that reduces fields and shortens flows. Crucially: no external notifications, no clinician alerts, no emergency contact triggers, and no data leaving the device.

This is what “local math, not cloud AI” looks like as a trauma-informed pattern: supportive adaptation without extraction (CrisisCore Systems, “Trauma-Informed Design”; Danquah and Addae).

D. Open source as ethical infrastructure (inspectability, accountability, reuse)

Open source is not a branding choice; it is ethical infrastructure. In an ecosystem where privacy policies often fail to describe actual data flows (Huckvale et al.), inspectability is part of safety. The PainTracker.ca repository is MIT-licensed (CrisisCore-Systems / pain-tracker), enabling audit, reuse, and adaptation without licensing friction.

E. A misfit position and governance advantage

PainTracker.ca is not a platform, does not monetize data, and resists default cloud patterns. It behaves like a local utility that anyone can run. This “misfit” has a governance advantage: independence from surveillance-driven funding keeps the roadmap user-first rather than investor-first. If sustainability requires support, it should be acknowledged transparently rather than hidden behind extraction.

V. Strengths, limitations, and the missing vulnerability: coercion

A. What the countermodel gets right

The primary strength is structural: there is no centralized hoard of pain data waiting to leak. The usual horror scenarios for health apps—misconfigured cloud storage, undisclosed sharing, sudden policy shifts—do not apply in the same way. The local-only model also changes the emotional climate of logging: honesty becomes safer when the system cannot silently export it. Offline-first behavior remains essential in low-connectivity conditions.

B. Known limitations (integration, backups, research aggregation)

The same choices that protect users make integration harder. Clinicians cannot “just log in.” Sharing requires deliberate action: screen-sharing, printing, or export. Device loss can mean data loss; encrypted user-triggered backups become necessary. For researchers, the absence of passive aggregation constrains conventional big-data analytics; consented exports become the ethical gateway.

C. The epistemic gap: what RCTs measure vs what trauma-informed tools must prevent

Earlier drafts risked implying—without stating—that standard RCT frameworks are the problem. The claim here is narrower and more defensible: RCTs can be useful for certain clinical endpoints (eg, symptom trajectories), but trauma-informed tools require evaluation regimes that also measure capacity collapse, psychological safety, and coercion risk. A tool can “improve adherence” while increasing fear-driven compliance or suppressing honest reporting. If those harms are not measured, they can be mistaken for success.

D. The implementation science gap that becomes a power problem

Earlier versions acknowledged that patient-controlled sharing requires deliberate action from clinicians. The deeper vulnerability is not just friction. It is power asymmetry.

Even if a tool requires an explicit export action, the social conditions of care can make sharing effectively mandatory. If a clinician implies that care, medication continuation, or credibility depends on producing a diary, the patient’s “choice” becomes constrained by dependency and fear. In that scenario, the architecture protects against corporate surveillance but may not protect against institutional coercion.

A trauma-informed system cannot define consent solely as a UI action. Consent is a social relation embedded in power structures. If the tool is to be ethically coherent, it must be designed not only against corporate extraction but against coercive contexts of use.

VI. Why this architecture should be the default standard—and what the standard must include

A. Turning bioethics into engineering constraints

Autonomy means the option to keep data on-device, to decide if and when to share, and to revoke sharing without pleading with a vendor. A local-only, export-based architecture supports that.

Beneficence and non-maleficence mean reducing new harms introduced by digital implementation: breaches, misuse, re-traumatization, and coercive logging demands (Huckvale et al.; Danquah and Addae).

Justice means recognizing that chronic pain and surveillance both weigh heaviest on marginalized groups. Safer-by-default architectures matter most for those who have the least margin for secondary harm. Open source also advances justice by enabling adoption and adaptation without per-seat licensing.

B. Baseline requirements for ethical digital health tools

The baseline expectation should be:

Local-first by default, with opt-in, scoped, revocable remote storage only when necessary.
No default telemetry; data minimization as a default behavior, not a toggle.
Trauma-informed UX evaluated for emotional safety, transparency, non-coercion (Danquah and Addae).
Inspectability of data flows and critical logic (open source or equivalent independent audit).
Coercion-resilient consent: design and workflow requirements that preserve autonomy under pressure.

These map naturally onto data minimization and purpose limitation principles referenced across privacy regimes (including Canadian frameworks such as PIPEDA and provincial health information laws), and they reduce breach and third-party risk surfaces in ways institutions can operationally value (PIPEDA; PHIPA).

C. Consent is not a button: coercion-resilient sharing principles

Patient-controlled export is necessary but insufficient. A coercion-resilient system should implement:

Minimum-necessary summaries by default
Default export should be a one-page clinician summary optimized for time-pressured care, not raw diaries.
Layered disclosure and redaction controls
Sharing should be granular: time ranges, domains (sleep, mood, meds), and free-text notes should be independently shareable. Patients should be able to generate a “clinical-safe” export excluding sensitive narrative content.
Refusal-safe workflows and non-retaliation norms
Patients must be able to decline sharing without punishment or implied denial of care. When documentation is requested, privacy-preserving alternatives must exist.
Time-bounded access and patient-held control
Prefer screen-sharing, printed summaries, or time-bounded access mechanisms that reduce permanent institutional retention when feasible.
Implementation kits designed for clinic reality
Tools should ship with clinic-adapted workflows: pre-visit export steps, standard summary formats, staff instructions, and scripts that normalize autonomy.

These principles do not claim to make coercion impossible; they aim to make it harder, reduce its blast radius, and create refusal-safe pathways.

D. Why institutions would choose to limit themselves: a theory of adoption under constraint

Coercion-aware architecture is necessary but not sufficient. The unresolved question is why institutions—clinics, health systems, insurers, regulators—would adopt models that reduce informational control. The answer is incentive alignment.

First, local-first, no-telemetry architectures function as institutional risk controls. By eliminating centralized data hoards and third-party analytics dependencies, they reduce breach surface area, vendor exposure, and secondary data-sharing pathways. In operational terms, data minimization reduces incident likelihood and magnitude, lowers response burden, and limits downstream harms from misconfiguration.

Second, coercion-resilient sharing reduces clinical conflict. In time-pressured care, clinicians may default to “give me everything” because negotiation takes time. Summary-first exports and layered disclosure replace an all-or-nothing dynamic with structured necessity, which can be faster than raw-log review and less adversarial than “hand it over.”

Third, patient-controlled models can be implemented without adding appointment friction if workflow design is treated as part of the intervention, not an afterthought. A practical default is a pre-visit summary export that takes under 60 seconds, supported by standardized formats and clinic scripts that normalize patient autonomy. Where a patient declines, refusal-safe alternatives prevent punitive denial-of-care dynamics.

Finally, adoption accelerates when procurement and funding frameworks reward privacy-preserving defaults. When purchasers require auditable minimization and refusal-safe sharing options, institutions and vendors adapt. In this view, the question is not whether institutions surrender power out of goodwill, but whether the ecosystem makes privacy-first, coercion-resilient practice the path of least resistance.

E. A time-pressured visit workflow: how this works in practice

A common objection is that patient-controlled sharing cannot survive short appointments. This is only true if “sharing” means exporting raw diaries. A coercion-resilient workflow is summary-first:

Before the visit, the patient generates a one-page summary (last 14–30 days) with trends, key triggers, medication response, and a short “what I need today” section.
In the visit, the clinician reviews the summary (30–90 seconds), asks targeted questions, and requests additional domains only if clinically necessary.
If the patient declines further sharing, the clinician uses refusal-safe alternatives (brief structured questionnaires or functional prompts) without punitive signaling.
Documentation focuses on minimum-necessary clinical content rather than raw logs, reducing long-term institutional retention of sensitive narrative data.

This workflow treats the diary as primarily for the patient; clinical sharing is a secondary, harm-reduced interface.

F. The opioid prescribing and disability claims “hard case”

In high-stakes contexts (eg, opioid prescribing regimes, disability adjudication), coercion can be structural rather than interpersonal. If documentation is treated as a condition of care, “voluntary sharing” becomes constrained disclosure. In these cases, privacy-first tools cannot fully prevent coercion; they can only reduce its blast radius through minimum-necessary summaries, granular domain sharing, and refusal-safe alternatives. Where policies mandate surveillance beyond clinical necessity, the ethical problem is not a missing UX feature but a governance failure that requires policy-level correction.

VII. What needs to be studied next (including coercion as an endpoint)

If privacy-first, coercion-resilient architectures are to move from GitHub into mainstream practice, research must evaluate both clinical outcomes and power-context harms.

Head-to-head studies (mixed-methods): Compare local-only tools with typical cloud-based apps on adherence, data completeness, trust, privacy anxiety, and clinical outcomes—paired with qualitative interviews focused on perceived safety and honesty under use (Health Canada; “Using a Pain Diary”; University of Washington, “PainTracker”).
Operationalizing trauma-informed UX: Develop measures of perceived safety, shame activation, re-traumatization, and cognitive load during app use, and test how specific patterns affect these measures (Danquah and Addae).
Coercion and consent-under-asymmetry as endpoints: Measure perceived pressure to share, fear of care denial, conditionality experiences, and downstream avoidance of care due to privacy concerns. Evaluate whether layered disclosure and refusal-safe workflows reduce these harms.
Implementation science in real clinics: Test clinic workflows (pre-visit summary generation, standard formats, staff scripts) and evaluate feasibility, clinician burden, fidelity, and sustainability under time constraints (Marceau et al.).
Participatory studies with high-risk cohorts: Include housing-insecure, disability-claim-exposed, and trauma-surviving participants—groups whose capacity gaps and coercion risks are often excluded from “general user” samples.
Privacy-preserving interoperability: Experiment with user-triggered encrypted exports and privacy-preserving aggregation approaches that do not recreate centralized surveillance.

Contribution statement: This paper contributes (1) a design-based critique of surveillance-centered pain apps, (2) an implemented countermodel demonstrating feasibility of offline, local-only, trauma-informed architecture, (3) a coercion-resilient consent framework for clinical deployment, and (4) a research and implementation agenda that treats coercion risk and psychological safety as measurable outcomes.

VIII. Conclusion

Chronic pain shapes millions of lives, and there is solid evidence that structured tracking can improve management and strengthen patient–provider communication (Health Canada; “Using a Pain Diary”; University of Washington, “PainTracker”). Digital tools should be the obvious way to scale that.

Instead, the current landscape is dominated by surveillance-aligned architectures and trauma-uninformed UX. Audits show that even accredited health apps can transmit data in ways users cannot meaningfully evaluate (Huckvale et al.). Public polling reveals widespread distrust (Teale). People living with pain are repeatedly asked to trade away privacy and autonomy for tools that often fail them when they need help most (CrisisCore Systems, “Building a Pain Tracker”; “Trauma-Informed Design”).

PainTracker.ca is a working proof that it is technically straightforward to build a useful health tool that does not spy: local-only encrypted storage, offline-first behavior, crisis-aware UX, and open-source inspectability. But a final hard truth remains: architecture alone cannot guarantee autonomy if clinical power can turn sharing into compliance. A default standard worthy of the name must pair privacy-first technical design with coercion-resilient workflows—minimum-necessary summaries, granular sharing, refusal-safe alternatives, and clinic-realistic implementation supports.

The stakes reach far beyond chronic pain. The same logic applies to mental health, reproductive health, HIV adherence, and any domain where logs intersect with stigma and power. The real question is no longer whether privacy-first, trauma-informed, open-source tools are possible. The question is whether funders, regulators, and institutions are willing to choose them—and willing to protect patients not only from corporate surveillance, but from institutional leverage.

Works Cited

CareClinic. Pain Tracker – CareClinic – Apps on Google Play. Google Play Store,
https://play.google.com/store/apps/details?hl=en_CA&id=com.careclinicsoftware.careclinic&listing=chronic-pain-tracker-app. Accessed 1 Dec. 2025.

CrisisCore Systems. “Building a Healthcare PWA That Actually Works When It Matters.” DEV Community, posted 27 Nov. 2025,
https://dev.to/crisiscoresystems/building-a-healthcare-pwa-that-actually-works-when-it-matters-md4. Accessed 1 Dec. 2025.

—. “Building a Pain Tracker That Actually Gets It — No Market Research Required.” DEV Community, posted 30 Nov. 2025,
https://dev.to/crisiscoresystems/building-a-pain-tracker-that-actually-gets-it-no-market-research-required-4511. Accessed 1 Dec. 2025.

—. “Trauma-Informed Design Left Everyone Asking: ‘How Does It Actually Know I’m Struggling without Spying?’” DEV Community, posted 29 Nov. 2025; edited 14 Dec. 2025,
https://dev.to/crisiscoresystems/trauma-informed-design-left-everyone-asking-how-does-it-actually-know-im-struggling-without-26a0. Accessed 1 Dec. 2025.

Danquah, Shaun, and Paul Addae. “Why Trauma-Informed Digital Design Is Relevant in 2022.” Centric, 1 Aug. 2022,
https://centric.org.uk/blog/why-trauma-informed-digital-design-is-relevant-in-2022. Accessed 1 Dec. 2025.

Health Canada. Canadian Pain Task Force Report: March 2021. Government of Canada,
https://www.canada.ca/en/health-canada/corporate/about-health-canada/public-engagement/external-advisory-bodies/canadian-pain-task-force/report-2021.html. Accessed 1 Dec. 2025.

Marceau, L. Diane, et al. “In-Clinic Use of Electronic Pain Diaries: Barriers of Implementation among Pain Physicians.” Journal of Pain and Symptom Management, vol. 40, no. 3, 2010, pp. 391–404. doi:10.1016/j.jpainsymman.2009.12.021.
PubMed: https://pubmed.ncbi.nlm.nih.gov/20580526/. PubMed Central: https://pmc.ncbi.nlm.nih.gov/articles/PMC2934898/. Accessed 1 Dec. 2025.

Huckvale, K., et al. “Unaddressed Privacy Risks in Accredited Health and Wellness Apps: A Cross-Sectional Systematic Assessment.” BMC Medicine, vol. 13, 2015, article 214,
https://bmcmedicine.biomedcentral.com/articles/10.1186/s12916-015-0444-y. Accessed 1 Dec. 2025.

“Using a Pain Diary.” News-Medical Life Sciences, 2019,
https://www.news-medical.net/health/Using-a-Pain-Diary.aspx. Accessed 1 Dec. 2025.

University of Washington. “PainTracker Patient Questionnaire.” UW Medicine Center for Pain Relief,
https://paintracker.uwmedicine.org. Accessed 1 Dec. 2025.

—. “PainTracker.” CoMotion at the University of Washington,
https://els2.comotion.uw.edu/product/paintracker. Accessed 1 Dec. 2025.

Teale, Chris. “A Major Obstacle to Tech Companies Developing Health Apps: About 2 in 3 Adults Worry About Their Privacy.” Morning Consult Pro, 1 Oct. 2021,
https://pro.morningconsult.com/articles/health-tech-tracking-apps-data-privacy-poll. Accessed 1 Dec. 2025.

Personal Information Protection and Electronic Documents Act (PIPEDA). Justice Laws Website (Government of Canada),
https://laws-lois.justice.gc.ca/eng/acts/p-8.6/. Accessed 1 Dec. 2025.

Personal Health Information Protection Act, 2004 (PHIPA). CanLII,
https://www.canlii.org/en/on/laws/stat/so-2004-c-3-sch-a/latest/so-2004-c-3-sch-a.html. Accessed 1 Dec. 2025.

PainTracker.ca. CrisisCore Systems, https://paintracker.ca/. Accessed 1 Dec. 2025.

CrisisCore-Systems / pain-tracker. GitHub, https://github.com/CrisisCore-Systems/pain-tracker. Accessed 1 Dec. 2025.

Support this work

Sponsor the project (primary): https://github.com/sponsors/CrisisCore-Systems
Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker

The Protective Legitimacy Score: How to Tell Whether a Trust Claim Is Structural

CrisisCore-Systems — Fri, 08 May 2026 20:07:40 +0000

Support structural verification work: PainTracker pricing and upgrades

If a product says it is privacy first, offline first, trauma informed, or resilient, the hard question is not whether the copy sounds good.

The hard question is whether the system earns the claim.

That is what the Protective Legitimacy Score is for.

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

PLS is not a badge, not a certification, and not a compliance shortcut. It is a structural scoring method for checking whether a system's trust language is supported by architecture, defaults, failure behavior, and recovery paths.

The short version:

claims do not generate score
structure generates score
defaults matter more than marketing
graceful failure matters more than polished happy paths

If you want the doctrine underneath the score, start with the Protective Computing canon, then the live Protective Computing library.

Why this score exists

Modern software is full of protective language that collapses on inspection.

You see apps described as:

encrypted
offline first
privacy first
local first
trauma informed
secure by design

Sometimes the individual feature behind the phrase is real.

But the system still fails the user where it matters most.

Startup still requires a network call.

Backup export silently drops the metadata needed for restore.

Sensitive state still goes to third-party analytics.

Destructive actions remain ambiguous under stress.

Recovery paths assume the user is calm, rested, online, and thinking clearly.

That gap between rhetoric and structure is exactly what PLS is meant to expose.

What PLS measures

PLS comes out of Protective Computing, which treats vulnerable-state software as a systems problem rather than a branding problem.

A protective system must preserve five things:

Local authority
Exposure minimization
Reversibility
Degraded functionality resilience
Coercion resistance

PLS asks whether those properties are materially supported.

Not in the abstract.

In the actual product.

That means checking questions like:

Does the core task still work when the internet disappears?
Can the user recover from a mistake locally?
Does export preserve meaning, not just raw bytes?
Does optional subsystem failure collapse the main workflow?
Does the interface reduce or increase pressure under stress?
Is the trust claim backed by a reproducible verification path?

The score is useful because it forces maintainers to answer those questions at the architecture layer.

What PLS is not

This matters because scoring systems are easy to misuse.

PLS is not:

a product certification
a substitute for threat modeling
a legal or compliance determination
a guarantee of safety
a way to claim perfect protection

It is also not meant to reward theater.

If a team adds a consent modal, a privacy badge, or a polished security page without changing the underlying system behavior, that should not meaningfully improve legitimacy.

PLS only becomes useful if it stays hostile to hollow improvements.

That is why the score is paired with explicit caution about Goodhart's Law: once a metric becomes a target, people start optimizing the appearance of the number instead of the thing the number was supposed to measure.

The easiest way to spot a low-legitimacy system

You usually do not need the full rubric to detect the problem class.

Start with these red flags:

core workflow depends on cloud services that are described as optional
export or backup paths are underdocumented and untested
destructive actions are faster than recovery actions
analytics or telemetry are broader than the product copy suggests
lock states or trust boundaries are ambiguous
docs use strong protection language without concrete artifacts
a failure in an auxiliary feature breaks the main job of the product

If several of those show up together, the trust claim is probably rhetorical before you ever compute a formal score.

What a higher-legitimacy system tends to look like

A stronger score does not come from sounding careful. It comes from structuring the system to survive instability.

That usually means:

local writes before remote sync
explicit export and restore paths
bounded optional integrations
reviewable destructive actions
truthful documentation about scope and non-guarantees
evidence tied to real tests, release gates, or artifact receipts

That is why PLS is best used alongside a proof path rather than a marketing page.

The number alone is not enough. The verification surface matters.

A concrete reference point

PainTracker is useful here because it gives the doctrine a live reference implementation instead of leaving it at the manifesto layer.

The public proof path is here:

That does not make the system perfect.

It does make the trust story inspectable.

That is the point.

Protective legitimacy is structural, not rhetorical.

If someone cannot inspect what you checked, what you excluded, and what still remains risky, then the trust claim is incomplete no matter how polished the copy sounds.

How to use PLS without turning it into theater

Use it as a forcing function:

Score the system honestly.
Record why the score is what it is.
Link the claim to artifacts, tests, or boundary documents.
Re-score after structural changes, not after copy changes.

If your score improves because the product became more local, more reversible, less extractive, or more truthful under failure, good.

If it improves because the landing page sounds more serious, you are using it wrong.

The deeper point

PLS exists because software teams are very good at describing their intentions and much worse at proving their behavior.

Protective Computing tries to close that gap.

The score is one part of that.

Not the destination. The forcing function.

Links

If you want the doctrinal entry point before the score, read Architecting for Vulnerability: Introducing Protective Computing Core v1.0.

Support this work

Sponsor the project (primary): https://paintracker.ca/sponsor
Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker

Service Worker Failure Modes in Offline-First PWAs

CrisisCore-Systems — Tue, 05 May 2026 16:00:00 +0000

Test offline update behavior: download the free pain tracker

If you want the failure-mode and testing path through the catalog, start here.

Recommended route:

Service Worker Failure Modes in Offline-First PWAs
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 privacy-first, offline health tech to exist without surveillance funding it: sponsor the build → https://paintracker.ca/sponsor

If you want the privacy boundary underneath those failures, add:
Trust Boundaries in Client-Side Health Apps

Service workers look elegant on paper.

They make offline apps feel solid. They cache the shell, keep the
interface alive, and let the app keep moving when the network starts
falling apart. In diagrams, they look like resilience.

In real life, they can behave more like a trapdoor.

Because once an offline-first app starts updating in the wild, you are
no longer dealing with a clean release path. You are dealing with
timing. Old tabs. Partial installs. Stale assets. Broken migrations.
Users who are still living inside a version you no longer control.

That is the ugly sibling of deterministic caching.

Not the clean version from the whiteboard.

The version that actually has to survive contact with the world.

The real problem is not caching

Most people think the main danger is whether the cache is stale.

That is only the beginning.

The deeper problem is mismatch.

Mismatch between the HTML shell and the JavaScript bundle.
Mismatch between old local data and new migration logic.
Mismatch between a tab that has been open for three days and a deploy
that happened ten minutes ago.
Mismatch between what the service worker thinks is installed and what
the page thinks it can safely execute.

That is when the app starts behaving like it is possessed.

A user refreshes and half the UI is on the new version while the other
half is still running old assumptions. Buttons appear, but their
handlers no longer match. Assets load, but the code paths they point to
have changed. Cached data gets read by newer logic that expects a shape
it has never seen before.

The app does not always crash loudly.

Sometimes it just becomes subtly wrong.

And subtle wrongness is often worse, because it looks like success while
quietly breaking trust.

Update races are the first crack

Service workers do not update in one clean instant.

They register.
They install.
They wait.
They activate.
They take control.

That sounds neat until you remember the current page may still be
running the old version while the new worker is already half installed
and waiting for the moment it can take over.

Now imagine that happening while the user is online, then offline, then
back online, then navigating without a full reload.

What you get is not one clean version of the app.

You get multiple versions of the app trying to exist in the same
session.

That is an update race.

The browser may have a new worker ready, but the open tab still has old
code in memory. The new worker may be serving different cached assets
than the page expects. The user may be interacting with forms or state
that were created before the update but submitted after it.

If your deployment assumes the update is atomic, your deployment is
lying.

Stale assets are not just annoying

People talk about stale assets like they are a minor inconvenience.

They are not.

A stale asset can break the app at the structural level.

A page shell cached from version 12 can try to load bundle chunks that
no longer exist in version 13.
A JavaScript file can reference a CSS class that was renamed.
An icon can disappear because the manifest changed.
A route can still exist in the client shell even though the server no
longer serves the same logic behind it.

At that point, the cache is not preserving stability.

It is preserving confusion.

This gets especially dangerous in apps that split code aggressively or
lean on lazy loaded routes. The service worker may hand out a shell that
looks valid, but underneath it there are dead paths and broken
assumptions.

So the interface loads.

And then it decays.

That is the kind of failure people do not always catch in testing,
because it does not always look like a failure at first.

Broken migrations are the silent disaster

This is the failure mode that actually hurts people.

Not the refresh.
Not the spinner.
Not the stale icon.

The migration.

Offline apps live and die on local data shape. IndexedDB, local files,
cached blobs, serialized forms, background sync queues, drafts,
attachments, settings, metadata. All of it has to survive version
changes.

If a deploy changes the schema and the migration logic is wrong,
incomplete, or too eager, the app can corrupt its own memory.

A good migration does not just transform data.

It preserves intent.

A bad migration does one of the following:

assumes data is always present when it is not,
assumes old records were shaped exactly the way the new code expects,
rewrites records destructively without a rollback path,
silently drops fields the old version still needed,
upgrades part of the data but not the related references.

That is how offline apps lose trust.

Not because the user did anything wrong.

Because the app forgot how to carry its own history forward.

The hardest case is the user who never closed the tab

This is the one that gets underestimated over and over again.

You deploy a fix.

It works in dev.

It works in staging.

It even works for fresh users.

Then a real user comes back to a tab they opened two days ago, before
the deploy, with old state still alive in memory and old UI assumptions
still attached to it.

Now that user clicks into a screen you redesigned.

Maybe they were offline for half of yesterday.
Maybe they had pending actions in a queue.
Maybe the app was backgrounded and resumed later.
Maybe the service worker updated quietly in the background but the page
never reloaded.

That user is not on the same timeline as your deployment.

And that matters.

The system has to survive overlap. Old code and new code may both be
real for a while. If the app cannot handle that, then it is not really
offline-first.

It is just online-first with better branding.

Bad deploy recovery is part of the architecture

This is the part teams hate planning for, because it means failure is
not some rare edge case. It is part of the job.

Any real deployment system needs a rollback story.

Not a hope.

A story.

What happens when the new worker is bad?
What happens when a migration corrupts local state?
What happens when the new bundle is missing a critical asset?
What happens when only some users update before the rollback?
What happens when the old and new versions are both in the wild at the
same time?

If you do not have answers, you do not have release engineering.

You have confident gambling.

Recovery needs to exist at several levels

A mature offline-first system should think in layers.

If the new bundle is broken, the user should still be able to load a
safe fallback shell or at least recover into a known good version.

If a migration breaks local state, there should be a backup or
restoration path for critical data.

If the user was in the middle of something when the update hit, the app
should preserve the pending task or queue.

If a service worker update is corrupt, the system should be able to stop
activating it, revert to the prior worker, or degrade safely.

If the app cannot safely continue, it should tell the user plainly what
happened and what was preserved.

Not a blank screen.

Not a mysterious refresh loop.

Not a smug "something went wrong" message.

Actual information.

Because the user does not need elegance at that point.

They need clarity.

The update process itself needs guardrails

A service worker update should not be treated like an invisible
background event.

It is a potentially disruptive change to the app's behavior, cache, and
state model.

That means the update flow should ask:

Is the new version compatible with the current stored data?
Can the old version still interpret the new records?
Can the new version safely read old records?
Is there a staged handoff or is everything switching at once?
What happens if the page is open during the update?
What happens if the user is offline during the update?
Can the user continue safely if the new worker fails?

If you cannot answer those questions, then the update path is not
deterministic enough to trust.

And if it is not deterministic enough to trust, it should not be
pretending to be seamless.

The user should not have to think about deployment state

This part matters.

The user is not your release manager.

They should not need to understand service worker lifecycle state, cache
busting, manifest invalidation, or bundle compatibility matrices just to
use the app.

They only need a few truths:

This version is safe.
This version is syncing.
This version needs a refresh.
This change could not be applied safely.
Your data is intact.
Here is what happened.

That is it.

The machinery can be complex.

The experience cannot be.

What a protective approach looks like

A protective offline app does not pretend updates are harmless.

It treats them as controlled risk.

That means:

versioned caches, not mysterious blobs;
schema-aware migrations, not blind rewrites;
explicit compatibility checks;
safe activation timing;
rollback paths;
visible recovery states;
and a hard refusal to silently corrupt user data just to keep the
interface looking smooth.

The goal is not to make updates invisible.

The goal is to make them honest.

The deepest rule

An offline-first app is not just a website with a cache.

It is a living system that has to survive its own updates.

That is the test.

Not whether it looks polished when everything is fresh.
Not whether the first load is fast.
Not whether the demo is clean.

Whether it can update in the wild without lying to the user, breaking
their session, or destroying the data they trusted it to hold.

That is the field guide version.

Pretty architecture is easy in calm weather.

The real work is what holds when the storm hits.

Next in the failure-mode path:
Rollback Patterns in Offline-First PWAs

Support this work

Sponsor the project (primary): https://paintracker.ca/sponsor
Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker

Coercion-Resistant UX: Designing Interfaces That Don't Pressure Users Under Stress

CrisisCore-Systems — Tue, 28 Apr 2026 16:00:00 +0000

Low-friction summary format: pain journal for appointments

Good UX is not just about clarity.

It is about pressure.

Because a lot of interfaces are not neutral. They push. They rush. They corner. They bury the exit. They make one path feel obvious and the other one feel like a mistake.

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

That might look efficient on a dashboard.

It is not efficient in real life.

Especially not when the person using the system is tired, overwhelmed, grieving, under financial stress, dealing with pain, or trying to make a decision while their nervous system is already overloaded.

That is where coercion resistant UX matters.

Not as a soft preference.

As a standard.

The interface is part of the environment

When people talk about UX, they often act like it exists in a vacuum.

It does not.

An interface is part of the pressure around the user. It can reduce stress, or it can amplify it. It can make choice easier, or it can make compliance easier.

Those are not the same thing.

A coercive interface usually does a few familiar things:

It makes one path look obviously correct and the other one look risky or stupid.
It hides consequences behind soft language.
It uses timers, interruptions, and guilt to force a decision.
It makes the safe option feel like the wrong one.
It removes recovery after the user has already made a mistake.

That is not good design.

That is manipulation with rounded corners.

Stress changes how people decide

This is the part designers love to ignore.

Under stress, people do not process information the same way. Attention narrows. Memory gets worse. Reading gets shallower. People miss details. They click the first thing that seems available, especially when the interface is impatient.

So if your system assumes calm, focused, fully resourced users all the time, it is already failing the moment reality enters the room.

A trauma informed interface does not just look friendly.

It expects compromised cognition.

It assumes people may be tired, confused, dysregulated, distracted, or scared. That means the interface should slow down where it matters and stop demanding perfect conditions from imperfect humans.

Defaults are policy

Defaults are one of the most powerful coercion tools in product design.

People like to pretend defaults are just convenience. They are not. They are policy disguised as convenience.

A good default reduces load.

A bad default steers behavior.

That difference matters.

A real example is account setup screens that preselect marketing consent,
data sharing, or "personalized experience" options by default. The user
is tired, trying to get in, and the safest choice is not visually
privileged. The product is not helping the user decide. It is helping
itself collect permission.

A coercion resistant system should ask:

Who benefits from this default?
Can the user understand the consequence before accepting it?
Can they change it later without punishment?
Is the default reversible?
Is it serving the user's goal, or the system's agenda?

If the answer is unclear, the default is doing too much hidden work.

Nudging can become manipulation fast

Nudging sounds innocent until you inspect the machinery.

A nudge is only ethical when the user can see it, understand it, and move around it without penalty.

The second the nudge becomes opaque, hard to escape, or intentionally loaded, it stops being guidance and starts being coercion.

You see this everywhere.

A subscription flow where canceling takes ten more steps than buying.
A checkout where the "recommended" shipping option is preselected because it is better for the company, not the customer.
A banking app that places "defer payment" in bright color while the safer option is buried.
A consent dialog that makes refusal look like a mistake.

This is where good design becomes moral design.

Because an interface always reveals what it respects.

If it respects autonomy, it stays legible, reversible, and calm.

If it respects conversion above all else, it becomes loud, sticky, and suspiciously hard to leave.

Recovery is part of dignity

People make bad decisions.

They mis tap.

They rush.

They misunderstand the screen.

They panic.

They are human.

So a coercion resistant system does not just prevent mistakes. It assumes mistakes will happen and makes them survivable.

That means:

Undo should exist where possible.
Destructive actions should have clear recovery windows.
Dismissed states should not vanish forever without warning.
Deleted content should have a restoration path if the cost of loss is high.
Critical flows should let the user pause and return without punishment.

A good example is a message app that lets you undo send for a few seconds. That is not a gimmick. That is a recognition that human judgment is not always clean in the moment of action.

Recovery is not a bonus feature.

It is a respect feature.

If the interface only works when the user is calm and perfect, then it is not built for humans. It is built for idealized compliance.

Calm beats urgency

Urgency is one of the easiest ways to coerce someone.

Countdowns.
Flash warnings.
Deadline banners.
"One time only" language.
"Act now" pressure.
Visual noise that makes hesitation feel dangerous.

Sometimes urgency is real.

Most of the time it is manufactured.

The design question is simple: is the urgency there because reality requires it, or because the system wants the user to move without thinking?

A protective interface should never fake emergency energy to force behavior.

If something is truly time sensitive, say it plainly. Give the reason. Give the consequence. Give the next step. Then get out of the way.

No panic theater.

No fake red alarms.

No emotional blackmail disguised as product design.

Honest language matters

A lot of coercive UX is just dishonest language wearing a suit.

"Optimize your experience" often means "let us collect more data."
"Recommended for you" often means "profitable for us."
"Continue" often means "accept the thing we hid earlier."
"By using this feature, you agree" often means "we buried the terms in a wall of text and made the button larger than the exit."

If the language is vague, the system is usually trying to smuggle in consent.

That is exactly what protective UX should reject.

Say what the action does.
Say what gets stored.
Say what changes.
Say what can be undone.
Say what cannot.

People do not need more persuasion. They need less ambiguity.

Good friction is not bad UX

This is where a lot of teams get lazy.

They think all friction is bad.

No.

Some friction is protective.

Friction is good when it slows irreversible actions, creates room for reflection, or stops accidental harm.

Friction is bad when it blocks legitimate use, punishes tired users, or makes safe choices harder than unsafe ones.

The difference is intent.

A protective system inserts friction to preserve autonomy.

A coercive system removes friction from the action it wants and adds friction to the action it does not.

That is the pattern.

Once you see it, you see it everywhere.

Design for the worst day

Most interfaces are designed for the happy path.

That is why they fail when life gets ugly.

Real people use software while overloaded. Underfunded. Sleep deprived. Angry. Scared. Grieving. Sick. Distracted. Disoriented.

If your interface only works when someone is at full capacity, it is not robust. It is decorative.

A better standard is this:

Would this interface still feel fair if the user is exhausted?
Would it still feel legible if they are panicking?
Would it still feel humane if they are making the decision at 2 a.m. on a bad phone screen with a bad battery and a bad week behind them?

That is the test.

Not whether the design looks clean in a demo.

Not whether the funnel converts in the lab.

Whether it still protects the user when they are least able to protect themselves.

What coercion resistant UX looks like

It is not flashy.

It is not a conversion machine.

It is calm, clear, reversible, and honest.

It offers sensible defaults without hiding the cost.
It makes the safe path visible.
It lets the user back out without shame.
It avoids dark patterns, guilt cues, and fake urgency.
It preserves agency even when the user is under strain.

That is the protective computing version of UX.

Not just usable.

Not just polished.

Protective.

Because interfaces are not innocent.

They either make room for human dignity or they compress it for efficiency.

And once you understand that, the question changes.

Not how do we get users to comply faster.

Not how do we keep them from hesitating.

Not how do we make the preferred path feel inevitable.

The real question is this:

Does this interface stay respectful when the person using it is tired,
stressed, and easiest to pressure?

Support this work

Sponsor the project (primary): https://paintracker.ca/sponsor
Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker
Read the full series from the start: (link)

Sync Conflict Handling in Offline-First PWAs: How to Merge Without Lying to the User

CrisisCore-Systems — Tue, 21 Apr 2026 16:00:00 +0000

See the production app behavior: download a private pain tracker

Offline-first apps make a promise that sounds simple until you actually have to keep it:

keep working even when the network dies.

That is the beautiful part.

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

The brutal part is what happens when the network comes back and the world has changed underneath you.

Because once you let people create, edit, delete, and move things while offline, you are no longer dealing with one clean version of reality. You are dealing with fragments. Multiple devices. Delayed writes. Cached intent. Competing truths.

And that is where sync conflict handling stops being a technical detail and starts becoming a trust issue.

The real question is not, "How do I merge data?"

It is, "How do I merge data without lying to the person who made it?"

The myth of one true version

A lot of sync systems quietly act like the server is the sacred source of truth and the client is just a temporary mirror.

That story falls apart the second someone goes offline.

Now the phone is making decisions. The laptop is making decisions. The tablet is making decisions. The user is still living their life, still creating value, still expecting the app to remember what they meant.

So the system has to stop pretending there is always one correct answer sitting somewhere in the cloud.

Sometimes there are two valid versions.

Sometimes there are three.

Sometimes the app has to admit it does not know which one is "right" without context.

That honesty matters more than looking smooth.

The kinds of conflicts you actually need to deal with

Not every conflict deserves the same treatment. That is where a lot of sync logic gets lazy and starts smashing everything through the same pipe.

That is how you lose trust.

Field-level conflicts

This is the easy one.

One device changes the task title. Another changes the due date. One edits the bio. Another updates the avatar. These are separate wounds. They can usually heal separately.

If your data model is good, these can be merged cleanly without drama.

Same-field conflicts

This is where things start to get real.

Two devices edit the same value in two different ways. One user renames a note on their phone from "Vendor follow-up" to "Urgent invoice." Another renames it on the laptop to "Tax stuff." Now the system has to choose, blend, or ask.

This is where "last write wins" starts pretending it has wisdom.

It usually does not.

Structural conflicts

These are nastier.

One device deletes a task while another keeps editing it. One device moves a card into a board that another device already archived. One user removes a section while another adds items into that section.

Now you are not just merging values. You are reconciling reality.

Ordering conflicts

These matter when sequence has meaning.

Lists. Boards. Timelines. Playlists. Drag-and-drop layouts.

If two devices reorder the same list differently while offline, a timestamp alone will not save you. The problem is not just when something happened. It is where it belongs.

Semantic conflicts

This is the quiet killer.

Two changes are both technically valid, but together they make no sense.

One device switches shipping to express. Another changes the address to a region that express shipping cannot reach. One edits a work order to "complete" while another adds a missing part that makes completion impossible.

Nothing looks broken at the field level, but the final state is nonsense.

That is the kind of bug that passes validation and still fails reality.

Why last-write-wins keeps disappointing people

Last-write-wins is popular because it is cheap.

It gives you a rule, a timestamp, and the comforting illusion that the machine has resolved the problem.

But timestamps are not truth. They are just timing.

A later write does not automatically mean a better one. It might just mean:

one device synced later,
one clock was wrong,
one client replayed an old action,
one update was delayed in transit,
one user changed a different field and got punished for it.

A user updates their address on one device and then changes their display name on another. If your sync logic is coarse enough, the second update can overwrite the first even though the edits had nothing to do with each other.

The app may call that "resolved."

The user will call it missing data.

Better ways to merge

There is no magic merge rule that works for every kind of data. The data type decides the strategy. The meaning decides the rules.

Merge at the field level when the fields are independent

This is the cleanest approach for profile data, preferences, metadata, and other objects where each piece can survive on its own.

If one field changed and the other did not, do not drag the whole object into the blast radius.

Sync operations, not just final states

This is often the better mental model.

Instead of saying, "here is the whole object now," say, "here is what the user did."

Rename note.
Add tag.
Move card.
Increase quantity.
Delete item.

Operations carry intent. Snapshots often lose it.

That matters because intent is what users care about. They do not remember the exact payload shape. They remember the action they took.

Use revisions so stale writes can be detected

Every record needs a version marker of some kind.

That way, when a client tries to update revision 12 and the server is already on revision 14, the system knows there is a conflict instead of blindly accepting whatever arrived last.

That tiny bit of structure prevents a lot of silent corruption.

Use CRDTs or OT where the surface is collaborative

For shared text, live editing, shared cursors, or highly concurrent content, basic timestamp logic is not enough.

Sometimes you need conflict-free replicated data types. Sometimes you need operational transform.

These are not fancy extras. They are the tools that let multiple writers converge without shredding each other's work.

Treat deletes carefully

A delete is not just absence.

It is a decision.

If another device still has stale references, you need tombstones or equivalent logic so the deleted object does not crawl back from the dead during sync.

That ghost data is exactly how apps start feeling unreliable.

The UI has to tell the truth too

The user should never feel like the app secretly rewrote their reality behind a curtain.

If sync is happening, say so.

If there is a conflict, say so.

If the app kept one version and discarded another, say so.

If the user needs to choose, show them the choice.

If the system merged safely, show what happened.

What breaks trust is not conflict itself.

What breaks trust is silence.

Good behavior

Show "syncing."
Show "conflict detected."
Show which version was kept.
Show what was merged automatically.
Show what can still be recovered.

Bad behavior

Hide failures.
Pretend everything saved cleanly.
Replace data without explanation.
Use a spinner to cover up uncertainty.
Call a destructive overwrite "success."

That is not good UX. That is institutional gaslighting with a pretty interface.

What truth actually means in offline-first systems

In a disconnected system, truth is not one static object.

Truth is the current state of a negotiation.

A truthful app keeps track of three things at once:

the latest confirmed server state,
the user's local pending intent,
the history that explains how the conflict was resolved.

That third part is huge.

Because people do not just want the outcome. They want to know why the outcome exists.

If a user edits something offline and the server later rejects or reshapes it, the app should not just snap the UI back like nothing happened. That feels fake.

It should explain the sequence.

This was saved locally.
Another device had a different version.
These values conflicted.
This is what was kept.
This is what can be restored.

That is honesty. That is how you keep trust alive.

A real conflict policy needs categories

A good offline-first app should not improvise every conflict.

It should already know how different data behaves.

Safe to auto-merge

Use this when fields are independent, changes are additive, and nothing important gets lost by combining them.

A name change and an avatar change can usually coexist.

Soft conflict

Use this when the system can merge, but the result should still be visible to the user for review.

Example: two people edit the same note title. The system can preserve both versions, but it should not pretend it picked the "right" one without telling anyone.

Hard conflict

Use this when guessing would be dangerous, destructive, or irreversible.

That includes deletions, permission changes, financial data, and anything where the wrong answer causes real damage.

If a user's invoice amount, access level, or saved payment details are involved, the app should not get creative.

Build the model for conflict from the start

Conflict handling is not something you bolt on at the end.

It starts in the schema.

A sync-friendly system usually needs:

stable IDs,
revision tracking,
timestamps,
operation logs,
mutation queues,
conflict metadata,
undo paths,
and endpoints that can survive replay.

If the backend cannot handle delayed, repeated, or reordered writes, offline-first behavior will eventually bend it into something untrustworthy.

The architecture has to be built for friction.

The rule that matters most

Do not optimize for "no conflicts."

Optimize for "no silent loss."

Conflict is not failure.

Conflict is evidence that the system respected reality enough to notice it was split.

That is the job.

Not to erase disagreement.

Not to fake certainty.

Not to make the interface look smooth while the user's work disappears in the background.

The job is to preserve intent, expose uncertainty, and keep the user oriented when the world forks.

A good offline-first app should be able to say:

This was saved.
This was merged.
This was overwritten.
This was rejected.
This is what happened.
This is what you can still recover.

That is what truth looks like when devices disagree.

Support this work

Sponsor the project (primary): https://paintracker.ca/sponsor
Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker
Read the full series from the start: (link)

OpenClaw and the Boundary Problem

CrisisCore-Systems — Fri, 17 Apr 2026 00:25:31 +0000

Use this practical checklist: what to include in a pain journal

This is a submission for the OpenClaw Writing Challenge.

Personal AI is usually sold as convenience.

That is the wrong frame.

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

The real question is not how much an assistant can do. It is what
boundary a person is being asked to trust when they let it do those
things.

That is why OpenClaw is interesting.

Not because it is another chatbot with better branding. Because it
makes the boundary visible.

The docs describe a self hosted gateway you run on your own machine or
server, wired into the chat apps you already use, with sessions,
memory, browser automation, exec, cron, skills, plugins, and support
for local models when you want data to stay on device. That is not
just a product surface. It is an architectural decision about where
authority lives.

OpenClaw also says the quiet part out loud.

Its security model is a personal assistant model, not a hostile multi
tenant one. One gateway is one trusted operator boundary. If you want
mixed trust use, the docs tell you to split gateways or at least split
OS users and hosts. That matters, because a lot of personal AI talk
collapses the moment one runtime starts mixing personal identity,
company identity, shared chat surfaces, and tool access. At that
point the assistant is not personal. It is just convenient.

This is the boundary problem.

A personal AI system owes the person using it a few things.

It owes them local first behavior wherever possible. OpenClaw runs on
your hardware, and its memory is stored in plain files in the
workspace. The docs are explicit: there is no hidden memory state
beyond what gets written to disk. If a system is going to remember
things about me, I should be able to inspect where that memory lives.

It owes them explicit consent. OpenClaw pairing is an owner approval
step for new DM senders and for device nodes. Unknown senders do not
just get to start steering the assistant. Good. A personal AI should
not silently widen its social surface.

It owes them restraint.

This is where most products start lying.

The FTC’s Alexa case was about keeping voice and geolocation data for
years while undermining deletion requests. The BetterHelp case was
about disclosing sensitive mental health data for advertising after
promising privacy. Personal AI does not get a moral exemption just
because the interface feels helpful.

It also owes them protection against exfiltration and tool abuse.

OpenClaw’s own trust docs are useful here because they do not pretend
the risk is theoretical. The agent can execute shell commands, send
messages, read and write files, fetch URLs, and access connected
services. The public threat model names prompt injection, indirect
injection, credential theft, transcript exfiltration, malicious
skills, and unauthorized commands.

That means the system has to be designed on the assumption that the model can be manipulated.

That is the part people keep getting wrong.

They think the fix is a better prompt.

It is not.

OpenClaw’s own security docs say access control before intelligence.
Decide who can talk to the bot. Decide where it can act. Decide what
it can touch. Then assume the model can still be manipulated and keep
the blast radius small. That is the right order. Personal AI fails
when teams reverse it and try to get trust out of model behavior
instead of system boundaries.

And this is where release discipline stops being a side concern.

If a personal AI product claims local first privacy, visible state,
reversible exports, or safe supply chain behavior, those claims should
survive shipping. Docs are not proof. The artifact has to match the
story.

That means deterministic packaging where possible, published digests,
signed artifacts, provenance, and release gates that stop
unverifiable builds. OpenClaw’s ClawHub skill flow already points in
that direction with deterministic ZIP packaging and SHA 256 hashing,
and the broader supply chain ecosystem has already spelled out the
rest through SLSA and Sigstore.

If the product says trust matters, the pipeline should treat verification as a gate, not a garnish.

That is the real lesson.

Personal AI is not defined by whether it can send an email, check a
calendar, or browse a page. It is defined by whether the person using
it can answer a few unforgiving questions.

Where does it run?

Who can reach it?

What can it touch?

What leaves the device?

What gets remembered?

How do I inspect it?

How do I revoke it?

How do I verify that the thing you shipped is still the thing you promised?

OpenClaw matters because it pulls those questions back into the
architecture instead of burying them under product copy. And that is
what personal AI owes the person using it: not intimacy, not vibes,
not a polished privacy page, but a boundary that can be seen,
checked, and enforced.

If it cannot prove the boundary, it is not discipline. It is marketing with root access.

Go deeper

If this piece resonates, the broader work lives at CrisisCore Systems — focused on trust boundaries, privacy risk, and structural product failure in sensitive software.

Main site: CrisisCore Systems
Framework: Protective Computing
Reference implementation: PainTracker
Support the work: Sponsor CrisisCore-Systems

Support this work
Sponsor the project (primary): https://paintracker.ca/sponsor
Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker

The Stability Assumption: The Hidden Defect Source

CrisisCore-Systems — Tue, 07 Apr 2026 15:30:00 +0000

Fallback when conditions degrade: free pain journal templates

If you have already read
Architecting for Vulnerability: Introducing Protective Computing Core v1.0
and
Protective Computing Is Not Privacy Theater,
read this next.

This is the closing argument in that doctrine path. It names the hidden defect
source underneath the rest of the work: the assumption that the user is
operating under stable conditions when the system most needs to survive
instability.

Most software bugs are not random.

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

A lot of them start much earlier than people think. Not in a broken function.
Not in a missed test. Not in some weird edge case nobody could have seen
coming.

They start in the premise layer.

They start when a product is built around the assumption that the user is operating under normal conditions.

Online. Rested. Safe. Focused. On a working device. With time to think. With
stable access to their accounts. With enough margin to recover cleanly when
something goes wrong.

That assumption is everywhere, which is exactly why it hides so well.

Protective Computing names it directly: the Stability Assumption.

It is the false premise that the user has reliable connectivity, intact
attention, safe surroundings, stable institutions, and enough breathing room to
deal with failure properly. Its companion failure mode is Stability Bias:
treating instability like a weird exception instead of a normal operating
condition.

That may sound abstract until you start tracing real product decisions back to it.

A login flow that assumes immediate access to email is built on it.

A dashboard that becomes useless without a network round-trip is built on it.

A backup import flow that writes to state before preview or validation is built on it.

A sync queue that quietly expands what it can replay over time is built on it.

A so-called privacy-first app that still assumes the user has time, safety, and clarity to understand every failure state is built on it.

That is why this matters.

This is not just a philosophy issue. It is not one more soft conversation about empathy in product design. It is a hidden defect source.

Because when stability drops out, those assumptions do not stay theoretical.
They turn into lockout. Forced disclosure. Fragile recovery. Silent scope
expansion. Irreversible mistakes.

The system starts behaving exactly the way it was designed to behave.

The problem is that it was designed for the wrong human condition.

The Fake Baseline Most Teams Still Build Around

A lot of software is built around a user who is basically fine.

Maybe slightly busy. Maybe a little distracted. But still functional enough to
re-authenticate, read the warning, interpret the prompt, troubleshoot the
failure, and make the right choice in time.

That baseline is fake.

Real users are dealing with pain, fatigue, grief, executive dysfunction, weak
connectivity, low battery, degraded hardware, unsafe environments, unstable
housing, shared devices, legal pressure, interrupted sessions, and broken
institutional support.

Not once in a while.

Regularly.

That changes the question.

You stop asking, "Does this feature work?"

You start asking, "What does this become when the person using it is tired, scared, offline, rushed, watched, or cognitively maxed out?"

That is the question a lot of products quietly avoid.

It is also the question that exposes whether the system is actually trustworthy or just polished under ideal conditions.

Stability Bias Is Convenience Mistaken for Truth

This is where teams get themselves into trouble.

They remove friction because it feels cleaner.

They widen a sync scope because it is easier than maintaining a hard boundary.

They centralize more state because it makes analytics simpler.

They require sign-in because it makes the system feel more unified.

They add telemetry because "we need visibility."

Under stable conditions, all of that can sound reasonable.

That is the trap.

Once the Stability Assumption is baked in, convenience starts masquerading as
correctness. The cleaner path starts looking like the right path. The easier
architecture starts looking like the more mature architecture.

Then real life shows up and exposes what those decisions actually were.

Not harmless optimizations.

Defect multipliers.

That is Stability Bias.

It is what happens when a team optimizes for the user they imagine instead of the user who actually exists.

What This Looks Like In Practice

This gets real fast when you stop talking about principles and start looking at boundaries.

In PainTracker, background sync is not treated like some innocent convenience
layer. It is treated like a place where a small change can quietly turn the
product into something else.

That is why the boundary is strict.

Exact method-and-path allowlisting at enqueue and replay. Same-origin only. No wildcard drift. Disallowed queue items dropped and deleted.

That is not paranoia.

That is what it looks like when you understand that a sync queue is one of the fastest ways a local-first app can slowly become a replay surface.

Same with backup import.

The goal is not "make restore easy no matter what." The goal is controlled recovery under imperfect conditions.

So the flow stays narrow: settings-only backup, strict envelope, explicit
allowlist, hard deny on risky keys, preview before write, typed confirmation
token, bounded size, bounded key count.

That is not decorative friction.

That is the system refusing to pretend the user is always calm, clearheaded, and operating in a safe environment.

The privacy posture follows the same logic.

No account required. Local-first by default. Health data stays local by
default. No health-data analytics sent to a server. Optional network behavior
is bounded and does not quietly turn into broader extraction.

That is what privacy looks like when it is structural.

Not branding. Not vibes. Not theater.

Architecture.

The Hidden Bug Is Not That The App Crashed

The hidden bug is that the software was built for the wrong version of reality.

A system can be fast, polished, encrypted, compliant, and still be fundamentally wrong about the conditions it has to survive.

It can pass QA and still fail the user the moment life stops behaving nicely.

That is the deeper point.

The Stability Assumption sits upstream of whole clusters of downstream failure:

lockout bugs
sync overreach
forced disclosure paths
brittle recovery
irreversible user mistakes
cloud dependence disguised as convenience
core flows that only work when the user has spare attention and time
products that collapse the second the real world gets involved

These are not weird edge cases.

They are what happens when software meets life.

Protective Computing does not treat that as incidental. It treats it as a design condition.

As it should.

A Better Audit Question

The old question is simple:

Does this work under normal conditions?

The better question is harsher:

What assumption about stability is this feature making, and what happens when that assumption fails?

That question should sit over every auth flow, every import path, every sync
mechanism, every destructive action, every dependency, every telemetry
decision, every recovery path.

Because once you start looking for stability assumptions, you see them everywhere.

And once you see them, you start realizing how many "bugs" were never really bugs in the narrow sense.

They were consequences.

The code was doing exactly what the premise told it to do.

Not bad code.

Bad premises.

The Blunt Version

Most software is not broken because engineers are sloppy.

A lot of it is broken because it was designed for a fictional user in a fictional world.

A user with stable internet, stable attention, stable access, stable safety, stable time, and stable systems behind them.

A lot of real users do not have that.

So if your architecture depends on them behaving like they do, the defect was there long before the first ticket got filed.

It was there in the assumption layer.

That is the Stability Assumption.

And teams should start hunting it like the defect source it is.

Closing argument in the Protective Computing doctrine reading path.

Read first: Architecting for Vulnerability: Introducing Protective Computing Core v1.0
and Protective Computing Is Not Privacy Theater.

Support this work

Sponsor the project (primary): https://paintracker.ca/sponsor
Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker

I Ran the Protective Legitimacy Score on MyFitnessPal. It Failed.

CrisisCore-Systems — Sat, 04 Apr 2026 02:34:44 +0000

For a while, I have been writing about Protective Computing as a discipline.

That matters. But doctrine without contact is just theory wearing armor. If a framework cannot survive a collision with a real product, it is still only language.

So I stopped speaking in abstractions and ran the first public walkthrough.

I published PLS Walkthrough 0001: MyFitnessPal Public Surface Audit as a formal report.

The audit was intentionally scoped to publicly observable product surfaces and public documentation only. No packet capture. No authenticated runtime instrumentation. No reverse engineering. Just the visible architecture, the public promises, the exposed controls, and the policies the product asks people to trust.

Final result: 7.50 out of 100.

Hard fail triggered.

That number is bad enough on its own. The harder truth is what it represents.

Why I chose MyFitnessPal

I did not want an obscure target. I did not want a throwaway app nobody depends on. I wanted a mainstream platform that sits close to the body, close to behavior, and close to the quiet pressure people live under every day.

A food and fitness tracker is not neutral software. It collects routines, measurements, habits, and intimate forms of self observation. It enters the part of life where people are tired, ashamed, hopeful, depleted, recovering, spiraling, trying again, or simply trying to hold a pattern together long enough to function.

That is exactly where software should be judged more harshly, not less.

What this audit was actually measuring

The Protective Legitimacy Score is not a vibe check. It is not a trust badge. It is not a branding exercise.

It is a structured way of asking whether a system deserves to be trusted under real human conditions.

Not ideal conditions. Not demo conditions. Not investor deck conditions.

Real conditions.

What happens when the user is cognitively overloaded. What happens when they are in pain. What happens when they are being watched. What happens when they do not have perfect energy, perfect privacy, perfect connectivity, or perfect control over their environment.

A lot of software looks acceptable until you introduce reality.

Then the seams start showing.

What the public surface already reveals

One of the more dangerous habits in software criticism is pretending you need full internal access before you are allowed to make a serious judgment.

Sometimes the system tells on itself immediately.

Sometimes the public surface is already enough.

If the visible product posture depends on tracking, account dependence, unclear recovery, exposure-prone defaults, or missing coercion-aware safety framing, that is not a minor detail. That is the architecture speaking in plain sight.

And that is the point of this walkthrough.

Not to claim omniscience. Not to pretend a public-surface audit is the whole story. But to prove something much simpler and much more uncomfortable:

You can often detect structural failure before touching the internals.

Why the fail matters

This is not about theatrics. It is not about making a number sound dramatic. It is about what it means when a mainstream health-adjacent platform can be evaluated from its own public posture and still land at 7.50 out of 100 with a hard fail already triggered.

That should bother people.

Not because the score is sacred. Not because one report ends the conversation. But because the visible layer of the product is already telling you that the burden is being placed in the wrong place.

On the user.

On the tired person. On the sick person. On the person who is expected to navigate settings, disclosures, permissions, exports, deletion paths, and trust boundaries while also trying to live.

That is the part the industry keeps getting away with.

Software keeps presenting itself as helpful while quietly assuming stable conditions that many people do not have.

Stable attention. Stable privacy. Stable bandwidth. Stable housing. Stable emotional regulation. Stable safety.

Those assumptions are not neutral. They are load-bearing. And when they collapse, the product’s true design philosophy becomes visible.

The larger problem

Too much writing about privacy and trust still collapses into theater.

A company says it cares about privacy. A product adds a settings menu. A policy page grows longer. A dashboard gains one more toggle. Everyone acts like this is maturity.

It is not maturity if the underlying posture is still fragile. It is not care if the user is still carrying the cognitive burden alone. It is not protection if the design only works for people who are already safe.

That is why I care about Protective Computing.

Because I am not interested in whether a system sounds ethical. I am interested in whether it remains defensible when life stops being clean.

Can the system preserve agency under stress.

Can it reduce exposure instead of merely disclosing it.

Can it degrade honestly.

Can it avoid turning confusion, urgency, or dependency into a coercive condition.

Those are engineering questions.

They deserve engineering answers.

Why I published this as a formal report

I did not want this to live as another opinion post floating through the feed. I wanted a real artifact. Something citable. Something stable. Something that can be examined, challenged, reused, and built on.

That is why the first walkthrough exists as a DOI-backed report instead of a loose thread of claims.

If I am going to argue that software should be judged against human vulnerability instead of convenience theater, then I need to be willing to make that judgment in public, under my own name, with a method and a paper trail.

So that is what this is.

The beginning of a series that takes Protective Computing out of the realm of doctrine and puts it under load against real software.

In public. With receipts.

Read the audit

PLS Walkthrough 0001: MyFitnessPal Public Surface Audit

Framework basis: Protective Legitimacy Score (PLS) rubric

Target policy reviewed: MyFitnessPal Privacy Policy

This is the first walkthrough.

It will not be the last.

Because if a framework cannot survive contact with real software, it does not deserve to exist.

And if software cannot withstand evaluation under real human conditions, it does not deserve blind trust.

Why Sovereignty Is Not Enough: The Missing Operational Layer in AI Stewardship

CrisisCore-Systems — Wed, 25 Mar 2026 16:00:00 +0000

A system can run on your machine, keep your data out of somebody else’s cloud, and still fail you at the exact moment trust is supposed to become real.

That is the gap a lot of AI discourse still leaves untouched. We talk about who owns the model, who hosts the stack, who controls updates, and where the data lives, and those questions do matter. They shape leverage, dependence, and exposure. What they do not answer is the harder question: how does the system behave once conditions stop being clean?

That is where sovereignty and stewardship part ways.

Sovereignty is about authority. Stewardship is about what that authority becomes under strain. They belong in the same conversation, but they are not the same achievement, and too much of the current language around local and private systems still treats them as if they were.

Why the weaker frame keeps winning

Sovereignty gets overcredited because it offers a visible answer to a real fear. People have watched platforms tighten terms, widen telemetry, raise prices, and quietly shift power upward while leaving users with fewer meaningful choices. So when a product arrives wrapped in the language of local control, private storage, or self hosted operation, it feels like correction. It feels like somebody finally named the problem.

That reaction makes sense. It also stops too early.

Location is easier to prove than conduct. A builder can point to the machine, the storage boundary, or the deployment model and make a claim that looks morally serious. The system runs here. The data stays here. The user owns the keys. All of that may be true, and none of it tells you whether the product remains legible when a process is interrupted, a retry only half succeeds, or state becomes contested.

That is the seduction of the weaker frame. It lets architecture stand in for responsibility. It lets a system look protective because of where it runs without proving that it behaves protectively when the operator actually needs help.

A remote system can fail you from a distance. A local system can fail you in your own hands and still leave you doing the cleanup. The fact that the blast radius moved closer to the user does not make the failure more ethical.

The real audit surface is degraded use

Most software looks respectable when nothing interrupts the path from intent to completion. Stable connectivity, stable power, full attention, complete context, and enough time to think can make even fragile systems appear trustworthy.

The real audit begins when continuity breaks.

A laptop sleeps halfway through a run. A browser reloads. A session expires at the wrong moment. The network drops just long enough to create uncertainty without creating a clean failure. A retry completes some work but not all of it. The interface returns something that looks settled even though the underlying state is not. The operator comes back tired and has to decide whether touching anything again will repair the situation or make it worse.

That is not edge behavior. That is ordinary life.

If a system only preserves clarity when nothing interferes with its ideal flow, then its public posture is stronger than its operational reality. It may still be elegant. It may still be private. It may still be sovereign. None of that changes the fact that trust begins where ambiguity stops being expensive.

Example one: the local agent that cannot account for itself

Imagine a local agent that processes a folder of documents and writes structured notes into your workspace. There is no remote execution, no third party logging, and no outside dependency in the critical path. On paper, it checks the boxes people increasingly use as shorthand for trustworthiness.

Halfway through the run, the machine sleeps.

When it wakes, the interface reports completion. Only later does the operator discover that one file was never processed, another was partially written, and a retry created duplicates because the write path was not safe to repeat. Timestamps shifted during the second pass, so sequence is now unclear. There is no durable event log, no reconciliation summary, and no clean record of what committed successfully versus what was left in limbo.

The system remained sovereign throughout the entire sequence. That is exactly the point. The failure was not about ownership. It was about the system’s inability to preserve truth once interruption entered the picture. Instead of containing uncertainty, it handed uncertainty to the human and forced them to reconstruct reality from fragments.

That is not a minor implementation flaw. It is a trust failure at the architectural level.

Example two: the sync engine that hides unresolved state

Now take a different product class: a notes tool with optional sync. It advertises local ownership, encrypted storage, and user controlled export. Again, the posture sounds strong.

A common failure path is easy to imagine. The user edits the same project across two devices. One device has been offline longer than expected. The other completed a background retry after a temporary authentication lapse. When connectivity returns, the product announces that everything is up to date.

It is not.

One change was dropped during conflict resolution because the merge strategy preferred recency over meaning. An attachment reference survived in metadata even though the underlying blob never finished uploading. A background retry succeeded on one object and silently failed on another. The export panel still shows success because the export job completed, even though the dataset now contains an unresolved hole.

What makes this dangerous is not simply sync failure. Systems fail. What matters is that the operator is given the appearance of closure instead of an honest account of state. Ownership is still present. Control is still present. What is missing is a system that can surface conflict, preserve causality, and tell the truth about what remains unresolved.

Once a product makes truth expensive to recover, it starts charging the human in time, stress, and risk.

What stewardship has to require

If stewardship is going to mean anything, it cannot remain a mood or a marketing signal. It has to describe a set of behaviors that hold under interruption, fatigue, and uncertainty.

The first requirement is bounded failure. A serious system limits blast radius. It distinguishes between what can pause, what can degrade, what can be retried safely, and what must stop until state is reconciled. Without those boundaries, capability only increases the size of the mess.

The second is real recovery. Not recovery promised in documentation for a calm operator with spare time, but recovery that exists in the product itself through resumable operations, durable checkpoints, preserved history, safe retries, and completion states that can actually be verified. If retrying might duplicate work, deepen corruption, or further obscure what happened, then the system does not really recover. It asks the human to compensate for its uncertainty.

The third is truthful state. This is where polished systems often become untrustworthy. They hide uncertainty because uncertainty looks messy, and they collapse partial failure into optimistic language because composure is easier to ship than honesty. But a protective system should make four things cheap to know: what happened, what is true now, what remains unresolved, and what can be done safely next. If those answers are difficult to obtain, then the system has already pushed operational risk downward onto the operator.

A better standard

When a product claims to be local, private, sovereign, or self hosted, that should open the real evaluation rather than close it. The useful test is not whether control moved closer to the user. It is whether the product can survive interruption without manufacturing confusion, preserve state in a way the operator can verify quickly, resume without turning retries into roulette, degrade without quietly damaging truth, and distinguish between real success and motion that merely reached a stopping point.

Those are not peripheral concerns. They are the conditions under which trust becomes operational instead of rhetorical.

Anyone can produce a clean architecture diagram and call it responsibility. The harder task is building a system that remains legible when context collapses, dependencies wobble, attention thins out, and reality becomes inconvenient. That is where stewardship either proves itself or disappears.

The verdict

Sovereignty matters. We need more systems that reduce dependence, narrow outside leverage, and return authority to the operator.

But sovereignty is not the verdict. It is the opening requirement.

A product does not become trustworthy because computation moved closer to the user. It does not become protective because the data stayed on the right machine. It does not become responsible because its language learned how to speak in the register of control.

The real question is harsher than that. When the run is interrupted, when state turns uncertain, when sync becomes contested, when completion is partial, and when the operator is too tired to play forensic analyst, does the system preserve orientation or does it preserve appearances?

That is the line that matters. Not where the system runs, but whether under degraded conditions it still lets the operator know what is true and what can be done safely next.

DEV Community: CrisisCore-Systems

Testing IndexedDB Schema Migrations in Offline-First PWAs

The real risk is not schema change

Fresh databases prove almost nothing

Test the shape and the meaning

Partial failure is where real migrations are judged

Long-delayed clients are not edge cases

Test against bad data on purpose

Rollback safety belongs in migration testing too

A good migration test suite usually covers five things

1. Fresh install

2. Upgrade from every supported historical version

3. Partial failure and interruption

4. Compatibility of related state

5. Recovery behavior

The user never sees the migration directly

The deeper rule

Support this work

Subpoena-Proofing by Design: Why Real Zero-Knowledge Has No Back Door

Boundary notes, because truth matters

Most subpoenas are custody problems before they are cryptography problems

Zero-knowledge is a custody architecture, not a badge

The forgot-password flow is usually the confession

Local derivation changes what the operator can disclose

Subpoena resistance starts with non-possession

Exports are where zero-knowledge can be quietly undone

If the boundary cannot be audited, it is not real

What this does not protect you from

The tradeoff is the proof

The protective test

Read next

Support this work

Rollback Patterns in Offline-First PWAs

Rollback stops being simple the moment data moves locally

The real danger is mixed-version reality

The first rule: not every migration is reversible

Good rollback plans start before the deploy

Compatibility windows matter more than clever rollbacks

Queue safety is part of rollback safety

Backup is not optional if the migration risk is real

Rollback UI should tell the truth

Service workers need rollback discipline too

What migration guardrails actually look like

The standard is not "Can we revert the deploy?"

The deeper rule

Support this work

Privacy-first, offline-capable, trauma-informed, open-source health tools should be the default

Privacy-first, offline-capable, trauma-informed, open-source health tools should be the default

Positionality and method

Abstract (250–300 words)

Keywords

I. Introduction

II. Chronic pain and why tracking still matters

A. Chronic pain as structural public health crisis

B. Why diaries and systematic tracking still matter

C. Where paper and first-generation digital tools hit their limits

III. What mainstream digital pain apps normalize

A. Surveillance as default architecture (even in “trusted” app ecosystems)

B. Why people distrust these tools

C. Trauma-uninformed UX as design harm

D. Clinician tools and institutional blind spots

IV. PainTracker.ca as countermodel: architecture-as-argument

Table 1. Mainstream defaults vs PainTracker.ca (countermodel)

A. Origin and non-negotiable constraints

B. Architectural choices: offline-first, local-only, no default telemetry

C. Trauma-informed and crisis-aware UX (local adaptation without spying)

D. Open source as ethical infrastructure (inspectability, accountability, reuse)

E. A misfit position and governance advantage

V. Strengths, limitations, and the missing vulnerability: coercion

A. What the countermodel gets right

B. Known limitations (integration, backups, research aggregation)

C. The epistemic gap: what RCTs measure vs what trauma-informed tools must prevent

D. The implementation science gap that becomes a power problem

VI. Why this architecture should be the default standard—and what the standard must include

A. Turning bioethics into engineering constraints

B. Baseline requirements for ethical digital health tools

C. Consent is not a button: coercion-resilient sharing principles

D. Why institutions would choose to limit themselves: a theory of adoption under constraint

E. A time-pressured visit workflow: how this works in practice

F. The opioid prescribing and disability claims “hard case”