Forem: CrisisCore-Systems

The Stability Assumption: The Hidden Defect Source

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

Part 11 of Protective Computing in Practice — Start here: https://dev.to/crisiscoresystems/offline-first-without-a-backend-a-local-first-pwa-architecture-you-can-trust-3j15

The Stability Assumption: The Hidden Defect Source

Most software bugs are not random.

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.

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

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.

This is part of Protective Computing in Practice.

Companion reading: Protective Computing Is Not Privacy Theater and 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
Read the full series from the start: (link)

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.

Protective Computing Is Not Privacy Theater

CrisisCore-Systems — Tue, 24 Mar 2026 16:00:00 +0000

Part 15 of Protective Computing in Practice — Start here: https://dev.to/crisiscoresystems/testing-privacy-preserving-analytics-verifying-that-insights-dont-leak-identity-e37

Protective Computing Is Not Privacy Theater

Privacy features are easy to ship. A toggle. A consent modal. An export button. Protective Computing asks a different question: does this system stay legible and non coercive when the person using it can no longer advocate for themselves? Those are not the same problem. One is a compliance posture. The other is a structural property.

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

The Difference Is Structural

A consent modal is privacy theater when the system behind it transmits sensitive state regardless of what the user clicked.

An export button is privacy theater when the exported file silently drops the encryption metadata needed to restore the data.

An "offline first" badge is privacy theater when startup requires a remote configuration call.

Privacy theater is often sincere work implemented at the wrong layer. A team ships a GDPR consent flow, checks the box, and ships. The data modeling underneath remains unchanged. The feature is real. The protection is not.

Protective Computing starts from a different premise: not what does the UI say, but what does the architecture actually do?

That distinction between rhetorical protection and structural protection is the entire discipline.

What Protective Computing Is

Protective Computing is a systems engineering discipline for software intended to remain safe, legible, and useful under conditions of instability and human vulnerability. The Overton Framework formalizes this as a structural engineering constraint with testable properties, not a design philosophy or a values statement.

A protective system must preserve five things:

Local authority — the user retains control over their data, device state, export paths, and ability to leave
Exposure minimization — collect, store, transmit, and render the minimum data necessary, by default, not as an option
Reversibility — users can recover from mistakes, panic, interruption, or incomplete actions without disproportionate harm
Degraded functionality resilience — core tasks survive degraded conditions: no internet, low battery, broken service workers, interrupted sessions
Coercion resistance — the system does not become a tool of surveillance, forced disclosure, or manipulation, even passively

None of those are features. They are architectural properties. They are either true of the whole system at the structural level, or not true regardless of what the UI labels say.

The Stability Assumption Is the Hidden Adversary

Most software is designed for someone who is rested, online, cognitively available, and in a safe environment with reliable hardware. The Overton Framework names this the Stability Assumption and formalizes what it produces as Stability Bias: an architectural distortion caused by dependency accumulation, vulnerability amplification, and irreversible system design.

Stability Bias is not a bug report. It is a defect class. It needs to be hunted, not just patched.

The actual use conditions for software that holds health records, legal evidence, housing documents, or communication logs include pain, illness, trauma, grief, fatigue, executive dysfunction, displacement, weak or intermittent connectivity, low battery, degraded hardware, unsafe surroundings, legal vulnerability, coercive relationships, cognitive overload, interrupted sessions, device sharing, and loss of trusted access.

That is not an edge case inventory. It is a description of any person in crisis. Software optimized for the Stability Assumption is implicitly optimized for the people who need protection least.

Why "Privacy First" Is Not Enough

Privacy first is a claim. Protective legitimacy is structural, not rhetorical.

A system is not protective because it says offline first, privacy first, encrypted, trauma informed, or resilient. It is protective only if the architecture, defaults, failure behavior, and recovery paths materially support those claims. The Protective Legitimacy Score rubric makes this precise: claims do not generate score. Verifiable system behavior generates score. A conventional cloud dependent architecture scores 15.25 out of 100. A protective local first implementation scores 87.75. The gap is not branding. It is architecture.

Here is what the structural version looks like in practice.

Specimen one: background sync.

The pain-tracker codebase keeps a document called SECURITY_INVARIANTS.md, a registry of the eight chokepoints where a small change quietly turns the system into a different kind of system. The first chokepoint is background sync. The invariant: no wildcard /api/* permissions. Same origin only. Drop and delete disallowed queue items. No "skip but keep."

The threat it defends against: when the app goes offline, pending requests are serialized to IndexedDB for later replay. Without strict origin validation at both enqueue time and replay time, a malicious queue item could redirect sensitive health data to an attacker controlled domain when connectivity restores.

Privacy theater would have put "we never transmit your data" in the README. The structural answer is two separate enforcement points with a regression test that fails if the allowlist ever becomes a wildcard.

Specimen two: backup import.

The second chokepoint covers BackupSettings.tsx. The invariant: no writes until the user explicitly types the confirm token IMPORT. Not a checkbox. Not a button. The literal word.

That friction is not a UX oversight. It is a coercion barrier. It prevents an automated process, a shoulder surfing attacker, or a panicked accidental action from writing arbitrary data into application state without a deliberate, eyes open confirmation step. The friction is load bearing. Removing it would not improve the user experience. It would remove a structural protection and replace it with nothing.

Two specimens. Same pattern in both: the claimed protection is enforced at the architecture level, testable, and documented as a chokepoint rather than trusted as a policy.

What the Structural Version Looks Like

Privacy theater versus structural protection, paired:

"We never sell your data"
The structural version: the app has no server side storage of health records. All writes go to local IndexedDB. The CSP enforces connect-src 'self'. Any external egress routes through a same origin chokepoint. The policy is the minimum possible claim because the architecture leaves nothing else to claim.

"Export your data anytime"
The structural version: the export preserves the full backup envelope with an allowlist applied on both export and import. Denied keys never leave. Denied keys never enter. Invalid schema versions are rejected. The restore round trip is tested, not assumed.

"Offline first"
The structural version: core writes succeed locally before any sync attempt. Sync is secondary. The app does not call a remote configuration endpoint on startup. Essential function survives with the network fully cut.

"Encrypted"
The structural version: defines exactly what is encrypted, where the key lifecycle lives, and what happens when the passphrase is lost. Lock state, unlocked state, absent state, error state, and corrupted state are explicit and tested. Encryption metadata is preserved through export and restore. The backup does not silently drop the material needed to decrypt it.

"Trauma informed"
The structural version: destructive actions are explicit, correctly scoped, and legible. Error states tell users what is still safe, not just what failed. No manipulative urgency. No irreversible reveals. Safe exit is always available. The interface does not become cognitively punishing under stress.

In every case the structural answer makes the claimed property auditable. It is not a statement of intent. It is a behavior the architecture either exhibits or does not.

What This Series Is

This series exists to turn protective claims into auditable design rules.

Seven parts. One question repeated across all of them:

What design rules make software stay usable, legible, and non coercive when human stability breaks down?

The material is not theoretical. The pain-tracker app is the reference implementation of the Protective Computing canon, built to demonstrate that these constraints are implementable in production software under real conditions. The series is grounded in that implementation, not doctrine invented to fill posts.

Part 2 — The Stability Assumption Is a Hidden Bug
Part 3 — Local Authority: Who Controls the System When Conditions Degrade
Part 4 — Bounded Failure: How Systems Break Without Turning Coercive
Part 5 — Trust Cases, Not Trust Claims
Part 6 — Friction as Protection
Part 7 — How to Audit a Product for Protective Computing

No manifestos. Patterns, failure modes, and implementation level evidence.

The Blunt Version

Privacy theater is what happens when a team solves the audit problem instead of the user problem.

Protective Computing is what happens when you ask what a system does to a scared, exhausted, offline person at 2am and you take the answer seriously at the architectural level instead of the marketing level.

One of those is a posture. The other is a discipline.

This is Part 1 of Protective Computing in Practice.

Next: Why the Stability Assumption is the hidden defect source in modern software.

About Protective Computing: A formally published systems engineering discipline. Full canon at the Protective Computing Zenodo community. Living specification at protective-computing.github.io. PainTracker is the reference implementation.

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)

Who Was the Software Built to Survive?

CrisisCore-Systems — Sun, 15 Mar 2026 02:32:41 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience
.

When people talk about inclusion in tech, the conversation usually starts with access.

Who gets hired.
Who gets funded.
Who gets invited into the room.

That matters.

But there is another question that matters just as much, and it gets asked far less often:

Who was the software built to survive?

Because a lot of software feels inclusive only as long as the user is calm, connected, housed, charged, focused, and safe.

It works beautifully right up until reality enters the interface.

Right up until the person using it is in pain. Or exhausted. Or scared. Or offline. Or displaced. Or trying to make important decisions on a dying phone battery with weak signal and nowhere private to think.

That is where the truth of a system shows itself.

Not in the pitch deck.
Not in the mission statement.
Not in the polished design file.

In the failure mode.

I did not learn that lesson from a conference talk or a polished sprint retrospective.

I learned it the hard way.

I learned it while dealing with pain, stress, housing instability, weak connectivity, low battery, legal pressure, and the humiliating experience of needing a system most at the exact moment it was least capable of meeting me where I was.

There were nights in winter in British Columbia when I sat in a McDonald’s for as long as I could, nursing a single coffee because one more hour indoors mattered. I stayed until they closed the seating area, and then I was outside again. More than once, I slept near the building under a tarp, with an extension cord hooked to an outlet high up near the roofline so I could charge my scooter while I slept. All night, I could hear every car rolling through the drive-thru.

That changes how you understand a loading spinner.

That changes how you understand a recovery flow.

That changes how you understand the phrase “just try again later.”

I have looked at “we sent you a code” differently when signal kept cutting out.

I have looked at password recovery differently when the recovery path assumed uninterrupted attention, stable device access, and enough calm to troubleshoot like nothing else in life was on fire.

I have looked at cloud dependency differently when battery life, connectivity, and personal safety were all unstable at the same time.

Those experiences changed the way I understand technology.

A cloud dashboard stops sounding advanced when you know what it means to depend on a network that might vanish.

A beautiful onboarding flow stops sounding thoughtful when it assumes a quiet room, emotional surplus, and the luxury of making mistakes.

“Sync it later” stops sounding harmless when you know that, for some people, later is where things disappear.

That is the part of inclusion I think tech still struggles to name.

We are getting better at asking who is represented in the industry. That matters deeply. But we are still not honest enough about how many products are built around a hidden assumption of stability:

Stable housing.
Reliable internet.
Consistent power.
Private device access.
Cognitive bandwidth.
Predictable energy.
Institutional trust.
Enough spare calm to recover gracefully when something breaks.

Those are not neutral defaults.

They are privileges disguised as design assumptions.

And because they are rarely named, they quietly shape everything. They shape what gets called intuitive. They shape which failures are tolerated. They shape who gets blamed when the system collapses.

Tech loves the phrase edge case.

But for millions of people, the so-called edge case is not an exception.

It is the baseline.

It is pain.
It is displacement.
It is low battery.
It is device sharing.
It is trying to hold your life together through an interface that was designed as if your life would already be holding.

For a long time, I thought technical excellence mostly meant making systems faster, smoother, smarter, and more automated.

Some of it does. Performance matters. Clarity matters. Good tooling matters.

But I no longer believe speed is the highest proof of care.

A system is not humane because it is frictionless.

A system is not trustworthy because the landing page says “secure.”

A system is not inclusive because it works beautifully for users whose lives already match its assumptions.

Real trust shows up in architecture.

It shows up in whether the tool can still function when the network fails.

It shows up in whether recovery is possible under stress.

It shows up in whether privacy is structural instead of optional.

It shows up in whether usefulness quietly demands surrender.

That realization changed how I build.

I stopped thinking about privacy as a settings page and started thinking about it as a boundary the system has no right to cross.

I stopped treating offline support as a feature and started treating it as respect.

I stopped treating reliability as convenience and started seeing it for what it often is:

dignity under pressure.

That shift changes engineering decisions.

Local-first storage stops looking niche.

Graceful degradation stops looking secondary.

Shorter recovery paths stop looking like polish.

Data minimization stops sounding paranoid.

Lower cognitive load stops being a UX preference and becomes a survival requirement.

These are not decorative improvements.

They are moral decisions expressed through technical structure.

Because if software is meant to support human beings under pain, fear, coercion, instability, or exhaustion, then it should not quietly punish them for being human.

And if a product claims to care about trust, then trust should be visible in the system itself, not outsourced to branding, legal language, and hope.

That is a large part of what pushed me toward local-first and privacy-first thinking.

Not because it was trendy.

Because it felt necessary.

I wanted to build software that did not treat unstable people as defective versions of ideal users.

I wanted to build tools that did not require exposure as the cost of usefulness.

I wanted to build software that could still hold its shape when life no longer looked like a product demo.

That may sound philosophical.

It is not.

It is brutally practical.

A person in pain may not be able to navigate a dense form.

A person in crisis may not remember six recovery steps.

A person in an unsafe environment may not be able to risk their data living on someone else’s server.

A person under stress may not need a smarter experience. They may need one that fails less cruelly.

Yet so much of the industry still treats those realities like peripheral accommodations instead of first-order engineering constraints.

To me, that is one of the deepest forms of exclusion tech still struggles to name.

Not just exclusion from opportunity.

Exclusion from usability.

Exclusion from safety.

Exclusion from recoverability.

Exclusion from the basic assumption that your life deserves to remain survivable inside the system itself.

I do not think every developer needs to have lived through instability to understand this.

But I do think the industry improves when more of us take seriously the people who have.

Not as inspiration.

Not as branding.

Not as a resilience anecdote pasted over product ambition.

As sources of design truth.

Because lived experience exposes architectural lies faster than strategy ever will.

It shows you where the defaults break.

It shows you which “best practices” were only best for people with surplus.

It shows you that some systems do not merely inconvenience vulnerable users.

They abandon them exactly when they are most needed.

So yes, inclusion in tech matters at the hiring level. Deeply.

But if we stop there, we leave the harder question untouched:

What kind of life does this system assume is normal?

Because every product embeds an answer.

Every workflow.
Every dependency.
Every default.
Every recovery path.

And if the answer is a life with stable housing, strong signal, private device access, spare focus, emotional bandwidth, institutional trust, and enough calm to troubleshoot on demand, then a lot of what we call good software is only good software for the already protected.

That is the lesson I keep returning to.

A lot of software is built for users at their best.

Very little is built for users at their most fragile.

And the distance between those two choices is often the distance between support and abandonment.

If we want a technology industry worthy of the word inclusive, then we cannot stop at asking who gets to build the future.

We also have to ask:

Who is allowed to remain intact inside the systems we ship?

How ProofVault turned trust from a documentation claim into a reproducible release artifact

CrisisCore-Systems — Sat, 14 Mar 2026 13:50:24 +0000

Part 14 of Protective Computing in Practice — Start here: https://dev.to/crisiscoresystems/testing-privacy-preserving-analytics-verifying-that-insights-dont-leak-identity-e37

ProofVault now carries part of its own proof burden in the repository.

Most projects say they care about security, privacy, or integrity. Far fewer can point to a concrete specimen, regenerate it from the repository, detect drift automatically, show what tampering looks like, and identify the exact hosted-green release tree tied to a public tag.

ProofVault now does.

This post is about building a trust case that is not just described in prose, but enforced through code, generated artifacts, CI, and release discipline.

The result is ProofVault Trust Case v1.0.1: a reproducible trust case for an offline-first encrypted evidence app, tied to an exact public release and stabilized across hosted CI.

The problem with trust claims

ProofVault is an offline-first encrypted evidence and incident capture application built for unstable, privacy-sensitive, and high-stress conditions.

A system like that carries a higher burden than ordinary product software.

It is not enough to say the app encrypts data. It is not enough to say the app exports records. It is not enough to say it has verification features.

Those claims stay abstract unless they are tied to something concrete, inspectable, and repeatable.

That was the gap this trust-case work set out to close.

The goal was to create a public artifact that answers, in checkable form:

what ProofVault guarantees
what it does not guarantee
what evidence supports those claims
how a third party can reproduce trust-critical output
how release integrity is preserved when the environment changes

What the trust case added

The result is a trust dossier under docs/trust-case/ and a pinned specimen under docs/trust-case/demo/.

That package includes:

a bounded trust case
an explicit threat model
a verification walkthrough grounded in a real specimen
a frozen demo case with pinned observed outputs
automated regeneration and drift detection
a CI workflow that enforces the specimen on GitHub's hosted runner

The key point is not that these pieces exist individually.

The key point is that they are connected.

The repository can now say:

Here is the specimen.

Here is how it is regenerated.

Here is what counts as expected output.

Here is how drift is detected.

Here is what tampering looks like.

Here is the exact release tree that passed hosted CI.

Here is the public tag tied to that proof.

That is a different class of credibility than a sentence in a README.

Why the specimen mattered

The pinned specimen changed the conversation.

Instead of talking about integrity in the abstract, the trust case now includes a real export, a real proof manifest, real verification reports, real fingerprint data, and a real tampered case showing mismatch behavior.

That shifts the burden of trust in an important way.

The project no longer asks a reader to assume that the export path, manifest sealing, backup verification, and release process all fit together. It shows one exact instance of those things fitting together, and it gives the repository a way to notice when that example stops matching reality.

Drift detection as enforcement

A trust case without drift detection decays quickly.

Once a specimen is checked in, the obvious risk is that future changes silently alter trust-critical output while the documentation continues to describe old behavior. That is how trust language collapses into theater.

ProofVault avoids that by treating the specimen as a checked invariant.

The local gate and the GitHub Actions workflow regenerate the specimen and compare it against the pinned outputs. If the trust-critical surface changes, the build fails until the change is explicitly reviewed and the specimen is intentionally updated.

That matters because it binds trust claims to maintenance discipline. The trust case is not merely published once. It is kept under pressure.

Hosted CI mattered more than local success

One of the most important parts of this work happened after the local system already looked correct.

The specimen was green on Windows. It was green under TZ=UTC. It was green in a Linux clone under WSL.

But GitHub's hosted runner still failed.

That was the decisive moment.

At that point, the responsible move was not to weaken the check, normalize away the problem, or assume CI was flaky. The responsible move was to treat the hosted runner as part of the real release surface and keep digging until the mismatch had a concrete explanation.

A trust case that only passes on the author's machine is not yet a release artifact. It is still a local belief.

What had to be fixed

The hosted mismatch surfaced three environment-sensitive faults in the specimen generation path:

timestamp rendering that depended on host-local presentation
archive metadata that drifted across environments
pinned specimen metadata that incorrectly stamped the live Node patch version

Each of those faults was fixed at source. The check stayed strict.

The easiest way to get a green build would have been to weaken the invariant, normalize away the mismatch, or quietly stop comparing the unstable parts. That would have made the trust case look cleaner while making it less meaningful.

Instead, the mismatches were traced and fixed where they originated.

Temporary CI diagnostics were added only long enough to expose the hosted-runner disagreement, then removed before the final release tag was cut.

That sequence matters as much as the fixes themselves. It shows that the release process was not green by accident. It was made legible under the same hosted surface the public repository actually depends on.

Why v1.0 and v1.0.1 both matter

The release history is part of the trust case.

proofvault-trust-case-v1.0 remains the first public trust-case cut. It was not moved or rewritten after publication.

proofvault-trust-case-v1.0.1 exists because the project found and corrected real cross-environment specimen drift, proved the fixes on hosted CI, removed temporary diagnostics, and tagged the final non-debug tree.

That preserves something important: provenance.

Instead of silently rewriting the first tag, the project kept the original public cut intact and published a corrected release with a clear explanation of what changed.

That is stronger than pretending the first release had been universally stable all along.

What this proves

This work does not prove that ProofVault solves every trust or security problem.

It does prove that the project can:

define a bounded trust model
connect that model to code and generated artifacts
make tampering visible through a verifier path
detect cross-environment drift in trust-critical output
fix release-surface mismatches without weakening the invariant
publish a public tag tied to an exact hosted-green tree

That is the core of the trust case.

ProofVault is no longer asking for trust on the strength of intent alone. It is carrying part of its own proof burden in the repository.

Why this matters beyond one project

This pattern is reusable.

Any system that makes claims about privacy, integrity, recoverability, or verification can benefit from the same discipline:

define the bounded claim surface
publish one reproducible specimen
encode expected outputs
treat drift as a first-class failure
require the real release surface to pass, not just a local machine

For ProofVault, that makes the trust case a credibility pillar.

More broadly, it provides a reference specimen for what doctrine looks like when it is translated into architecture, tests, CI, and release hygiene.

Final release state

The corrected public trust-case release is:

proofvault-trust-case-v1.0.1

The final hosted-green non-debug release commit is:

dc5fbe9

The original public cut remains:

proofvault-trust-case-v1.0

That is the final shape of the trust case.

Not a statement of values, but a system that can show its work.

If this kind of work interests you, the useful question is not just whether a product has security features.

It is whether the product can make its trust claims legible, reproducible, and release-bound.
Next up: https://dev.to/crisiscoresystems/protective-computing-is-not-privacy-theater-2job

The Micro-Coercion of Speed: Why Friction Is an Engineering Prerequisite

CrisisCore-Systems — Sun, 08 Mar 2026 06:10:51 +0000

Part 12 of Protective Computing in Practice — Start here: https://dev.to/crisiscoresystems/testing-privacy-preserving-analytics-verifying-that-insights-dont-leak-identity-e37

Modern software tools promise a simple future: remove friction, increase velocity, ship faster.

Autocomplete, AI copilots, instant scaffolding—everything is designed to reduce the distance between thought and execution.

On the surface this feels like progress.

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

But something subtle is happening inside that optimization.

When tools remove all friction, they do not just make developers faster.

They shift the burden of verification.

And that shift creates a form of micro-coercion.

The Illusion of Velocity

Most engineering environments optimize for the fast path: generating working code as quickly as possible.

Tools like GitHub Copilot and Cursor collapse the time between an idea and implementation to almost zero.

At first this feels empowering.

But software development is not a single step called writing code.

It is two cognitive processes:

Generation — producing possible solutions
Verification — proving those solutions are correct

AI tooling accelerates generation dramatically.

Verification, the process that protects system integrity, remains slow.

Under fatigue, deadlines, or cognitive overload, the brain takes the easier path: if the code looks polished and confident, we assume it works.

The tool stops being an assistant.

It becomes an unverified authority.

This is the micro-coercion of speed.

Not an explicit demand, but a subtle pressure: accept the output, move forward, ship.

The Cognitive Bypass

Human cognition operates through two modes of reasoning:

fast, intuitive pattern recognition
slow, deliberate verification

Autocomplete systems are optimized to feed the first.

When a block of code appears instantly—formatted, structured, seemingly coherent—it triggers a shortcut. The brain interprets polish as correctness.

The burden of proof quietly moves.

Instead of the tool proving the code is correct, the developer must prove that it is wrong.

But proving something wrong requires effort: reading line by line, checking assumptions, tracing data flow, testing edge cases.

When the system continuously offers new solutions faster than they can be verified, verification begins to collapse.

The developer becomes less of an engineer and more of a passenger in their own system.

The Physical World Standard

Software engineering is unusual among engineering disciplines in one critical way: it often assumes the operator will behave perfectly.

Mechanical, electrical, and industrial systems assume the opposite.

They assume operators will be tired.

They assume shortcuts will be attempted.

They assume speed pressure will override caution.

So they design systems where certain mistakes are physically impossible.

In industrial maintenance this appears in practices such as lockout and tagout, formalized in standards like OSHA 29 CFR 1910.147. Machines must be physically isolated from power before service begins.

The point is not trust.

The point is eliminating the possibility of catastrophic error.

Technicians know exactly what happens when speed overrides safeguards.

Consider a pressure safety switch in a commercial refrigeration system. If pressure exceeds safe limits, the switch shuts the compressor down.

A rushed technician can bypass that switch with a jumper wire. The compressor starts running again. The problem appears solved.

For a moment.

But the triggering pressure is still present. The compressor runs outside its safe envelope. Bearings overheat. Oil degrades. Failure arrives later.

The shortcut did not remove the problem.

It deferred the failure.

Physical engineering disciplines treat this pattern as dangerous enough to embed prevention directly into system design: safety interlocks, pressure relief, thermal cutoffs, and keyed disconnects.

Speed cannot bypass them.

The system refuses to run until the safety model is satisfied.

Software environments rarely enforce equivalent boundaries.

Generated code can be accepted without verification. Critical assumptions can pass silently into production.

The system runs.

Just like the bypassed compressor.

And failure appears later: under scale, unusual inputs, or the 3 AM incident where hidden assumptions collide with reality.

In physical engineering this is operating outside the design envelope.

Software often calls it technical debt.

The Systemic Failure Pattern

The pattern created by velocity-optimized tooling can be visualized as a simple risk pipeline.

When tools remove all cognitive friction, they do not just make developers faster.

They subtly coerce them into accepting logic they have not fully verified because verifying it requires more effort than generating it.

This is the micro-coercion of speed.

A UX pattern that prioritizes output over agency.

When generation outruns verification, the developer stops being an engineer and becomes a passenger in their own system.

Designing Active Friction

If physical engineering survives by enforcing interlocks, software must engineer cognitive interlocks.

We cannot rely on developers always being rested, skeptical, and careful. Systems must introduce friction at the architectural level.

Within the Overton Framework these mechanisms are called Protective Controls.

They are not intended to slow development.

They protect system integrity from velocity pressure.

IDE Boundary Interlocks

The development environment itself must enforce safety boundaries.

Example: database queries require mandatory parameterization gates.

If generated code attempts direct string interpolation, the IDE marks a red-zone violation and the build fails.

Speed cannot bypass the safety model.

The environment acts as an interlock.

Generation–Verification Separation

In manufacturing, a new program does not run directly on production equipment.

It is tested, simulated, and verified.

AI-generated code should follow the same principle.

Generation occurs in a sandbox.

Integration requires explicit human checkpoints.

The tool can propose solutions, but it cannot merge high-impact paths without deliberate approval.

Before code enters the system, the developer must demonstrate understanding.

Cognitive Slow Paths

Autocomplete amplifies fast intuition.

Protective computing introduces slow paths that deliberately engage analytical reasoning:

visual diff emphasis for generated blocks
commit gates requiring explanation of generated logic
contextual highlighting of sensitive data flows

Before code enters the system, the developer demonstrates ownership of the logic.

Not because the tool is malicious.

Because responsibility for the system belongs to the human operator.

The Systemic Risk Model

flowchart TD
  A[Velocity Pressure] --> B[AI Generation Speed]
  B --> C[Verification Gap]
  C --> D[System Risk]

flowchart TD
  E[Protective Computing] --> F[Cognitive Interlocks]
  F --> G[Forced Verification]
  G --> H[System Integrity]

The Practitioner vs the Passenger

Speed is not the enemy.

But speed without understanding changes the role of the developer.

When tools generate logic faster than it can be verified, ownership erodes. The codebase becomes something operated rather than understood.

The developer becomes a passenger.

Real engineering requires something else:

a mental model of the system
a clear understanding of boundaries
discipline to verify those boundaries hold

Friction is not a flaw in that process.

It is what protects it.

Next up: https://dev.to/crisiscoresystems/preview-mode-first-agent-plans-as-prs-plan-diff-invariants-4ikd

Support this work

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

Architecting for Vulnerability: Introducing Protective Computing Core v1.0

CrisisCore-Systems — Fri, 06 Mar 2026 04:55:40 +0000

Part 11 of Protective Computing in Practice — Start here: https://dev.to/crisiscoresystems/testing-privacy-preserving-analytics-verifying-that-insights-dont-leak-identity-e37

Most software is built on a dangerous premise: the Stability Assumption.

We assume the user has a stable network, stable cognitive capacity, a secure physical environment, and institutional trust. When those conditions hold, modern cloud native architecture works beautifully.

But when people enter a vulnerability state, the Stability Assumption collapses. Cloud dependent apps lock people out of their own data. Helpful auto sync features broadcast metadata from compromised networks. Irreversible actions happen when someone does not have the attention or time to read a modal carefully.

Here is the part we do not say out loud enough. In a crisis, software does not just fail. It can become coercive. You get logged out, you cannot recover the account, your data is suddenly somewhere else, and the only path forward is to comply with whatever the system demands.

We need a systems engineering discipline for designing software under conditions of human vulnerability.

Today, I am open sourcing Protective Computing Core v1.0.

The formal structural paper for the discipline is now published as the Protective Computing Canon v1.0.

Overton, K. (2026). Protective Computing Canon v1.0: A Structural Map of the Discipline.

Protective Computing Community.

DOI: https://doi.org/10.5281/zenodo.18887610

Boundary notes, because truth matters

This is not medical advice.
This is not a regulatory compliance claim.
This is not a claim of perfect security.

What is Protective Computing?

Protective Computing is not a privacy manifesto. It is a strict, testable engineering discipline.

It provides a formal vocabulary and a pattern library for building systems that:

degrade safely
contain failures locally
defend user agency under asymmetric power conditions

The v1.0 Core introduces a normative specification (MUST, SHOULD, MUST NOT), plus a conformance model you can actually review.

Read the spec here:

https://protective-computing.github.io/docs/spec/v1.0.html

The core pillars

Protective Computing Core is built around four pillars. Each one exists because a specific failure pattern keeps hurting people.

1) Local Authority Pattern

The system MUST preserve user authority over locally stored critical data in the absence of network connectivity. Network transport is treated as an optional enhancement, not a dependency for essential utility.

What this prevents: the classic offline lie where the app looks usable, but the moment the network drops the user loses access to their own records.

2) Exposure Surface Minimization

The system MUST NOT increase its exposure surface during crisis state escalation. Analytics, third party telemetry, and remote logging are default off and hard gated.

What this prevents: silent data exhaust during the exact window when a user is least able to notice, consent, or defend themselves.

3) Reversible State Pattern

The system MUST NOT introduce irreversible state transitions during declared vulnerability states unless explicitly confirmed. High impact destructive actions require bounded restoration windows where security invariants allow.

What this prevents: permanent harm caused by a single misclick, mistype, or foggy moment.

4) Explicit Degradation Modes

The system cannot just go offline. It MUST define explicit degradation modes (Connectivity Degradation, Cognitive Degradation, Institutional Latency) and map how essential utility is preserved in each state.

What this prevents: ambiguous failure where nobody knows what is safe, what is unavailable, and what the system is doing behind the scenes.

The reference implementation: PainTracker

To prove these patterns are implementable in standard web technologies, I built a reference implementation:

https://paintracker.ca

PainTracker is an offline first PWA designed for users tracking chronic health data, a highly sensitive payload often logged during high cognitive or physical distress.

Instead of a traditional SaaS architecture, PainTracker implements Protective Computing through:

Encrypted IndexedDB persistence (primary database lives on device)
Zero knowledge vault gating (local security boundary, no remote auth dependency)
Unlock only bounded reversibility (pending wipe window that only a successful unlock can abort)
Hard telemetry gating (verifiable kill switch for outbound requests not explicitly initiated by the user)

Repo:

https://github.com/CrisisCore-Systems/pain-tracker

Example: bounded reversibility without weakening security

Standard security dictates that after N failed unlock attempts, a local vault should wipe.

But under cognitive overload, people mistype passwords. An immediate wipe causes irreversible loss. A generic cancel button weakens brute force resistance.

Protective Computing requires a bounded restoration window that does not weaken the security invariant.

Here is the shape of the solution:

// Bounded reversibility under asymmetric power defense
async function handleFailedUnlock() {
  failedAttempts++;

  if (failedAttempts >= MAX_FAILED_UNLOCK_ATTEMPTS && privacySettings.vaultKillSwitchEnabled) {
    // 1) Enter a bounded degradation state
    // 2) Disclose the pending irreversible action
    // 3) Only a successful cryptographic unlock can abort the timer

    await enterPendingWipeState({
      windowMs: 10_000,
      reason: "failed_unlock_threshold",
      onExpire: () => executeEmergencyWipe()
    });

    UI.showWarning("Vault will wipe in 10s. Enter correct passphrase to abort.");
  }
}

Notice the constraint. There is no cancelWipe() function exposed to the UI. The only path to reversibility is proving local authority.

stateDiagram-v2
  [*] --> Normal
  Normal --> PendingWipe: N failed unlocks & kill switch enabled
  PendingWipe --> Normal: successful unlock within window
  PendingWipe --> Wiped: window expired
  Wiped --> [*]
  note right of PendingWipe: user sees warning UI
  note right of Normal: regular operation
  note right of Wiped: data erased

Measuring posture: the Protective Legitimacy Score (PLS)

In this space, marketing claims like military grade encryption or secure by design are useless. Engineers and regulators need auditable transparency.

Alongside the Core spec, I am publishing a measurement instrument called the Protective Legitimacy Score (PLS). PLS is not a certification. It is a structured disclosure format that forces maintainers to state:

what vulnerability conditions they assume
what compliance level they claim
what they do not claim
where they deviate, and why

PLS rubric (PDF):
https://protective-computing.github.io/PLS_RUBRIC_v1_0_rc1.pdf

Audit evidence index:
https://github.com/protective-computing/protective-computing.github.io/blob/main/AUDIT_EVIDENCE.md

Compliance audit matrix:
https://github.com/protective-computing/protective-computing.github.io/blob/main/COMPLIANCE_AUDIT_MATRIX.md

The goal is simple: replace vibes with checkable posture.

The call for Reference Implementation B

PainTracker proves the discipline works for localized health telemetry. But Protective Computing is domain agnostic.

These patterns are exactly what is needed for:

disaster response cache applications
coercion resistant messaging interfaces
offline first journalistic tooling
legal aid and housing workflows under institutional delay

If you want to contribute, here is the most useful path:

Read the spec v1.0: https://protective-computing.github.io/docs/spec/v1.0.html
Pick one requirement you think is wrong, too vague, or unbuildable.
Submit a review with a concrete counterexample and a better verification procedure.

Review invitation:
https://protective-computing.github.io/docs/independent-review.html

Independent review checklist:
https://github.com/protective-computing/protective-computing.github.io/blob/main/INDEPENDENT_REVIEW_CHECKLIST.md

I do not need agreement. I need pressure testing.

Canonical archive (Zenodo)

If you want the citable artifacts and stable versions, Protective Computing is archived as a Zenodo community. This is the cleanest place to reference exact releases without link rot.

Community:
https://zenodo.org/communities/protective-computing/records

Canonical paper (Protective Computing Canon v1.0):
https://doi.org/10.5281/zenodo.18887610

Field Guide v0.1:
https://doi.org/10.5281/zenodo.18782339
Part of the Protective Computing corpus. Canonical paper:
https://doi.org/10.5281/zenodo.18887610

PLS rubric DOI:
https://doi.org/10.5281/zenodo.18783432
Layer-3 document; canonical paper:
https://doi.org/10.5281/zenodo.18887610

Start here, and support the work if it helped

Fastest route through the catalog (series index):
https://dev.to/crisiscoresystems/start-here-paintracker-crisiscore-build-log-privacy-first-offline-first-no-surveillance-3h0k

Sponsor the build (keeps it independent of surveillance funding):
https://github.com/sponsors/CrisisCore-Systems

Star the repo:
https://github.com/CrisisCore-Systems/pain-tracker

If we change the architectural defaults, we can stop building software that breaks exactly when people need it most.
Next up: https://dev.to/crisiscoresystems/the-micro-coercion-of-speed-why-friction-is-an-engineering-prerequisite-g4j
Next up: https://dev.to/crisiscoresystems/the-micro-coercion-of-speed-why-friction-is-an-engineering-prerequisite-g4j

Preview Mode First: Agent Plans as PRs (Plan Diff + Invariants)

CrisisCore-Systems — Thu, 05 Mar 2026 19:38:03 +0000

Part 13 of Protective Computing in Practice — Start here: https://dev.to/crisiscoresystems/testing-privacy-preserving-analytics-verifying-that-insights-dont-leak-identity-e37

If you’re using AI agents in delivery workflows, the safest default is not “let it run.”
It’s Preview Mode First.

Think of every agent run as a PR proposal:

it has a plan
it has a diff
it must satisfy invariants before merge

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

That frame makes agentic work auditable, discussable, and reversible.

The mantra

Permissions cannot increase. Network scope cannot widen.

Say it before shipping. Enforce it in automation.

Minimal schema

Keep the schema small enough to reason about in review.

{
  "runId": "string",
  "baseCommit": "string",
  "plan": [
    {
      "id": "string",
      "action": "create|update|delete|exec",
      "target": "path-or-command",
      "justification": "string"
    }
  ],
  "planDiff": {
    "added": ["plan-step-id"],
    "changed": ["plan-step-id"],
    "removed": ["plan-step-id"]
  },
  "invariants": {
    "permissionsCannotIncrease": true,
    "networkScopeCannotWiden": true
  },
  "evidence": {
    "tests": ["command + status"],
    "staticChecks": ["command + status"],
    "policyChecks": ["rule + status"]
  }
}

If your agent protocol can’t produce something this clear, that’s your first design bug.

Example plan diff

Here’s a practical diff reviewers can evaluate in under a minute.

Agent Plan v12 -> v13

+ [P-104] update src/policy/invariants.ts
+ [P-105] add test src/test/invariants/network-scope.test.ts
~ [P-099] exec "npm run test" -> "npm run test -- --run src/test/invariants/*.test.ts"
- [P-087] exec "npm run deploy:preview"

Interpretation:

Added: explicit invariant implementation + targeted tests
Changed: narrower test scope for faster signal during review
Removed: deployment action from preview stage (good boundary)

This is what “agent plan as PR” should look like: plain, scoped, and reviewable.

Invariant report (pass/fail)

Make the report machine-readable and human-legible.

runId: run_2026_03_05_1422
result: fail
invariants:
  permissions_cannot_increase:
    status: pass
    evidence:
      - "no new OAuth scopes"
      - "no RBAC role delta"
  network_scope_cannot_widen:
    status: fail
    evidence:
      - "new outbound host: api.newvendor.example"
      - "egress policy updated from allowlist[3] -> allowlist[4]"
blocking:
  - "network scope widened during preview"
required_actions:
  - "remove new host from egress allowlist"
  - "re-run invariant checks"

A failed invariant is not “feedback.”
It is a merge blocker.

The point

Agents don’t fail because they’re malicious.
They fail because they follow instructions in a messy world.

Preview mode gives you a pause.
Plan diffs show you what changed.
Invariants stop the run when it crosses a line.

That’s the whole trick.

Quick reply you can reuse

If someone asks how you keep agents safe in practice, here’s the short version:

Treat agent runs like PRs: Preview first, system-computed plan diff, invariant report, then merge.

Mantra: permissions cannot increase / network scope cannot widen.

If AI agents are in your software supply chain, policy has to be executable.
Preview Mode First is how you keep that true under pressure.

Next up: https://dev.to/crisiscoresystems/how-proofvault-turned-trust-from-a-documentation-claim-into-a-reproducible-release-artifact-22pb

Support this work

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

WorkSafeBC Claim Documentation Workflow in PainTracker Pro Composite Example

CrisisCore-Systems — Tue, 03 Mar 2026 17:09:00 +0000

Originally published at https://blog.paintracker.ca/worksafe-bc-case-study-documentation-time-savings

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

Read this second: this case study is the worked example.
For the full reading path, start here: WorkSafeBC Documentation Workflows: Start Here
Read first: WorkSafeBC-oriented workflows without overclaims: structured summaries, careful language
For the export boundary behind the download step itself, see Exports are a security boundary

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)

Maintaining truthful docs over time: how to keep security claims honest

CrisisCore-Systems — Thu, 26 Feb 2026 17:06:00 +0000

Part 10 of Protective Computing in Practice — Start here: https://dev.to/crisiscoresystems/offline-first-without-a-backend-a-local-first-pwa-architecture-you-can-trust-3j15

Series: Start here · Part 1 · Part 2 · Part 3 · Part 4 · Part 5 · Part 6 · Part 7 · Part 8 · Part 9 · Part 10

This post is Part 10 in a Dev.to series grounded in the open-source Pain Tracker repo.

For the full reading path around this trust layer, start with Documentation Integrity / Verifiable Trust: Start Here.

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

This works best as Part 2 of a 2-post trust-and-verifiability pair.
Read first: Quality gates that earn trust

Together with How ProofVault turned trust from a documentation claim into a reproducible release artifact and Preview Mode First, this forms the Documentation Integrity / Verifiable Trust reading path.

Not medical advice.
Not a compliance claim.
This is about preventing doc drift from turning into false security promises.

Docs drift is inevitable — unless you design against it

Every repo accumulates drift:

features change, docs don’t
defaults change, READMEs don’t
“temporary” flags become permanent

In privacy/security contexts, drift is worse than being outdated.

It becomes misinformation.

So the goal isn’t “write perfect docs.”

The goal is:

keep docs anchored to things you can verify

The trick: write docs that point to proof

When you say:

“offline-first”

Point to:

service worker scripts
the offline DB layer
tests that verify offline behavior

When you say:

“validated inputs”

Point to:

schemas
tests that prove invalid inputs fail

When you say:

“quality gates exist”

Point to:

npm run check
npm run security-full
npm run accessibility:scan

Pain Tracker’s documentation style leans this way:

architecture docs under docs/engineering/
explicit indexes like docs/index/accessibility.md
runnable scripts in package.json

For a concrete example of this pattern becoming a release artifact instead of a writing guideline, read How ProofVault turned trust from a documentation claim into a reproducible release artifact.

Automate doc validation when you can

The repo includes a docs validation script:

npm run docs:validate

That doesn’t “prove the docs are true,” but it does catch classes of breakage:

missing references
structure drift
formatting assumptions

The point is to make “keep docs healthy” an explicit, repeatable action.

Separate claims from guarantees

A good rule for security docs:

describe what the code does
avoid implying it solves threats it doesn’t

Examples of safe phrasing:

“data stays local unless the user exports it” (if exports are explicit)
“analytics is gated behind an environment flag” (if the gate exists)

Examples of risky phrasing:

“secure” (without scope)
“compliant” (without a legal program)
“protected from attackers” (without a threat model)

Truthful docs don’t undersell the work.

They just don’t overpromise.

Use the repo’s own publishing tools to keep content consistent

Pain Tracker ships scripts to help keep Dev.to content in sync:

npm run devto:dry-run
npm run devto:sync-content
npm run devto:sync-titles

The meta-lesson: publishing should be a process, not a one-time copy/paste.

When that publishing flow includes agents, the same posture applies before content goes live: Preview Mode First: Agent Plans as PRs (Plan Diff + Invariants) is the matching guardrail on the delivery side.

Wrap-up

If you only take one thing from this series:

Make your claims testable.

That’s how you build trust without pretending to be perfect.

Prev: Part 9 — Quality gates that earn trust

Next up: https://dev.to/crisiscoresystems/the-stability-assumption-the-hidden-defect-source-5cpd

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)

Field Guide v0.1 What is inside and where to start

CrisisCore-Systems — Thu, 26 Feb 2026 08:54:00 +0000

Field Guide v0.1 is live. This post explains what is inside, who it is for, and where to start if you are new to the project. If you want the full reading path first, open Start Here and then return to this post for section level detail.

Summary A quick map of Field Guide v0.1 with entry points for new readers and clear next reads.

Field Guide v0.1 is Live

Protective Computing now has a second citable artifact.

Foundation artifact: The Overton Framework v1.3 (DOI: https://doi.org/10.5281/zenodo.18688516)
Practice artifact: Field Guide v0.1 (DOI: https://doi.org/10.5281/zenodo.18782339)

Why this release matters

The Overton Framework defines the doctrine and constraints.
The Field Guide operationalizes those constraints for systems engineers implementing real systems under hostile and degraded conditions.

Relationship to v1.3

v1.3 (Overton Framework): normative posture and principle-level architecture.
v0.1 (Field Guide): implementation-facing execution companion.

Together they provide a clearer bridge from principle to engineering practice.

Call for case studies

We are now collecting implementation case studies from teams building in vulnerability contexts (health, crisis response, journalism, civil society, public-interest tooling).

What to share:

threat context and operating constraints,
architecture decisions tied to principles,
verification evidence (pass/fail outcomes),
failures and lessons learned.

Repository: https://github.com/protective-computing/protective-computing.github.io
Site: https://protective-computing.github.io/

If you deploy Protective Computing in production or field conditions, we welcome independent review and reproducible evidence.