DEV Community: CrisisCore-Systems

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

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

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.

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

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.

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

This is a submission for the OpenClaw Writing Challenge.

Personal AI is usually sold as convenience.

That is the wrong frame.

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

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.

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.

Protective Computing Is Not Privacy Theater

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

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.

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. If you want the
normative layer beneath that framing, read
Architecting for Vulnerability: Introducing Protective Computing Core v1.0
for the Core v1.0 spec and conformance model.

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. The
Overton Framework is now DOI-backed,
which makes that doctrine citable and stable enough to audit against over time.

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. I unpack that design rule further in
The Micro-Coercion of Speed: Why Friction Is an Engineering Prerequisite.

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. For the audit
questions that expose whether those claims are real, read
If Your Health App Can't Explain Its Encryption, It Doesn't Have Any.

"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 Doctrine Path Is

This reading path exists to turn protective claims into auditable design rules.

Three pieces. One question repeated across all of them:

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.

Entry point — Architecting for Vulnerability: Introducing Protective Computing Core v1.0
This piece — translating doctrine into product and architecture boundaries
Closing argument — The Stability Assumption: The Hidden Defect Source

Adjacent essays like The Micro-Coercion of Speed
and Coercion-Resistant UX
extend the same discipline into engineering process and interface design.

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 the bridge between the doctrine entry point and the closing argument in the Protective Computing reading path.

Read first: Architecting for Vulnerability: Introducing Protective Computing Core v1.0. Then finish with The Stability Assumption: The Hidden Defect Source.

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

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?

ProofVault as a Release Artifact: Turning Trust Into Something You Can Verify

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

If you want the trust and release path instead of a single artifact essay, use this route:

Quality gates that earn trust
Maintaining truthful docs over time
ProofVault as a Release Artifact
Preview Mode First: Agent Plans as PRs (Plan Diff + Invariants)
The Overton Framework is now DOI-backed

For the broader catalog route, start with Start Here: PainTracker and the CrisisCore Build Log.

Trust is a dangerous word.

People throw it around like a vibe. Like a brand promise. Like something
that can be conjured with a clean landing page and a few polished
sentences about privacy.

It cannot.

Trust is not real until it survives contact with evidence.

That is why ProofVault matters.

Not just as a product.

As a release artifact.

Because the real question is not whether a tool claims to be safe,
private, reversible, or tamper aware.

The real question is whether it can prove those claims after the docs are
written, after the deploy is shipped, and after somebody else tries to
verify what actually happened.

That is the difference between messaging and discipline.

The docs are not the proof

This is where a lot of teams get lazy.

They write the architecture doc.
They write the privacy policy.
They write the security page.
They write the release notes.

Then they start acting like the words themselves are the guarantee.

They are not.

Docs can describe intent. They can define the contract. They can explain
the system. But they do not validate themselves. They do not stop a bad
build. They do not prove the artifact was assembled from the right
source. They do not tell you whether the shipped version still matches
the thing you thought you released.

That gap is where trust gets fake.

ProofVault exists in that gap.

It turns release trust into something you can inspect instead of
something you have to believe.

A release is a chain

A lot of release processes still treat the deployable like it is just
"the thing we ship."

That is too vague.

A release is a chain.

Source.
Build.
Dependencies.
Configuration.
Artifact.
Signature.
Checksum.
Environment.
Gate.
Approval.

If any link is unclear, the release is no longer fully explainable.

And if it is not explainable, it is not fully trustworthy.

That is the part people want to skip because it slows everything down.

Good.

It should.

ProofVault belongs on top of that chain, forcing a harder question:

Can we prove this release is the one we intended to ship?

Not "does it seem fine."

Not "did it pass in CI once."

Prove it.

Checksums are the first hard boundary

Checksums are basic, but basic is often what people fail to respect.

A checksum says this exact byte sequence exists.

Not approximately.

Not conceptually.

Exactly.

That matters because release integrity starts at the file level. If the
build output changes, even slightly, you are no longer talking about the
same artifact. Maybe the change is harmless. Maybe it is not. The
checksum does not guess. It records.

That is the first honest boundary.

If a release artifact cannot be hashed, compared, and rechecked later,
then it is not really anchored to anything stable.

It is just a memory with a download link.

Provenance is what gives the checksum meaning

A checksum alone says the file is identical to itself.

That is useful.

It is not enough.

You also need provenance.

Where did this artifact come from?
What source committed it?
What environment built it?
What version of the dependency graph was involved?
What steps transformed the source into the shipped package?
Was the build reproducible?
Was the pipeline deterministic?
Was the output produced by the system we think produced it?

That is where the trust model starts to get real.

Because trust is not just about bit integrity.

It is about lineage.

If you cannot trace the artifact back through a known process, you do not
really know what you are shipping. You only know what ended up in the
bucket.

That is not enough for serious software.

Especially not for software that asks people to trust it with evidence,
records, exports, health data, legal material, or anything else that
cannot afford silent drift.

Signing turns identity into something machine readable

A checksum proves sameness.

A signature proves authorship.

That distinction matters.

If a release is signed, the signature gives you a way to say this
artifact was approved or emitted by a known key under a known trust
model. That does not make it magically safe. It does not make the code
good. It does not replace review.

But it does give the release an identity that can be checked later.

And in a world full of copyable files, identity matters.

Because unsigned artifacts can be swapped.
Unsigned builds can be mirrored.
Unsigned packages can be repackaged.
Unsigned releases can drift away from the thing the team actually
intended to ship.

A signature is not a slogan.

It is a cryptographic line in the sand.

Release gating is where discipline becomes real

This is the part people like to skip because it slows them down.

Good.

It should.

If a product claims to be trustworthy, the release pipeline should make
trust a gate, not a decoration.

That means the release should not move forward unless key conditions are
met:

The artifact hash matches what was expected.
The provenance is known.
The build source is traceable.
The signing key is valid.
The release notes match the shipped version.
The verification checks pass.
The risk surface has been reviewed.

This is not bureaucracy for its own sake.

This is how you stop the story from splitting apart.

Because once the docs, the code, and the shipped artifact can drift
independently, the organization starts lying to itself.

Release gating is how you force those layers back into alignment.

A pinned specimen is what makes the claim concrete

This is where ProofVault stops being abstract.

The trust case is not just a set of principles.

It includes a real dossier under docs/trust-case/ and a pinned specimen
under docs/trust-case/demo/.

That matters because a reproducible specimen changes the burden of proof.

Now the project can say:

Here is the specimen.
Here is how it is regenerated.
Here is what counts as expected output.
Here is what tampering looks like.
Here is the exact release tree tied to the proof.

That is a stronger claim than "we care about integrity."

It is a concrete example that can be checked later.

Drift detection is the enforcement layer

A pinned specimen without drift detection decays into theater.

Once you publish expected outputs, the obvious risk is that future code
changes silently alter trust-critical behavior while the docs keep
describing the old story.

That is why ProofVault does not just publish the specimen.

It regenerates it and compares it against the pinned outputs.

If the trust-critical surface changes, the check is supposed to fail
until the change is reviewed and the specimen is intentionally updated.

That is what turns the trust case into a release artifact instead of a
one-time writeup.

Hosted CI mattered more than local green

One of the 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 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, blame CI,
or normalize away the mismatch.

The responsible move was to treat the hosted runner as part of the real
release surface and keep digging until the disagreement 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.

The release history matters because provenance matters

The public trust-case history is part of the proof surface too.

proofvault-trust-case-v1.0 remains the first public cut.

proofvault-trust-case-v1.0.1 exists because the project found real
cross-environment specimen drift, fixed it at source, proved the result
on hosted CI, removed temporary diagnostics, and tagged the corrected
non-debug release tree.

The final hosted-green non-debug release commit is dc5fbe9.

That matters because the first tag was not silently rewritten.

The history stayed legible.

That is what provenance looks like when it is treated as part of the
artifact instead of part of the marketing.

Proof after the docs are written is the real test

This is the part that separates serious systems from decorative ones.

Anyone can write a promise before shipping.

Very few systems can prove the promise after the fact.

That is where ProofVault becomes more than a tool. It becomes a standard
for accountability.

You can ask:

Does the release artifact hash match the published value?
Does the signed file verify against the expected key?
Does the provenance chain match the documented build?
Can someone independently reproduce the same output?
If the answer is no, where did the mismatch begin?

That is the level of scrutiny that matters.

Not vibes.

Not assumption.

Not "trust us."

Proof.

Verification should be boring

Good verification is not flashy.

It is not a hero story.
It is not a launch post.
It is a checklist that works the same way every time.

That is the point.

The less dramatic verification is, the more trustworthy it becomes.

A user should be able to look at a release and ask:

Is this the file I was told to expect?
Was it signed by the right identity?
Does the checksum match?
Is the provenance intact?
Did the pipeline actually produce what it claimed?

If those answers are machine-checkable, then the trust model has teeth.

If they are not, then the product is still asking for belief where it
should be earning verification.

Release trust is a product feature

This is the deeper shift.

Most teams think release integrity is an internal engineering concern.

Next in the trust and release path:
Preview Mode First: Agent Plans as PRs (Plan Diff + Invariants)

It is not.

It is a user trust feature.

Especially for tools that handle evidence, records, exports, private
notes, health data, legal material, or anything else that cannot afford
silent drift.

When the user presses export or downloads a release artifact, they are
not just taking a file.

They are taking a claim.

And claims should be verifiable.

That is why ProofVault matters in the first place.

Not because it sounds secure.

Because it turns trust into something that can be checked after the docs
are written, after the code is shipped, and after the story is already
in the wild.

The standard

A real release artifact should answer one simple question:

Can this be independently verified as the thing we said it was?

If the answer is yes, the system has discipline.

If the answer is no, the system has marketing.

ProofVault belongs in the first category.

Not as a branding flourish.

As evidence that trust can be made concrete.

That is the whole move.

Not trust as a promise.

Trust as a verified release state.

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

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

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.

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.

If you want the short reading path that connects this piece to the doctrine and
the concrete agent workflow pattern, start with
AI Agents Under Protective Computing: Start Here.

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. If you want the doctrine-level framing behind that
term, start with
Protective Computing Is Not Privacy Theater.

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.

For a concrete implementation pattern, see
Preview Mode First: Agent Plans as PRs (Plan Diff + Invariants),
which applies friction to AI agent pipelines through plan-diff review and
invariant checks.

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.

Support this work

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

Architecting for Vulnerability: Introducing Protective Computing Core v1.0

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

If you want one entry point into Protective Computing, start here.

This is the doctrine-level introduction: the piece that defines the discipline,
states the constraints, and points to the reference implementation and the
formal canon.

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:

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. For a concrete
implementation of that pattern in Pain Tracker, see
No Backend, No Excuses: Building a Pain Tracker That Doesn't Sell You Out.

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:

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)

If you want the storage mechanics behind that boundary, read
Offline First Storage Design State Cache IndexedDB and Encrypted Vault
for how the three-layer architecture enforces local authority in practice.

Repo:

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 you want the doctrine translated into concrete product boundaries, read
Protective Computing Is Not Privacy Theater next.

If you want the closing argument that names the defect source underneath those
boundaries, finish with
The Stability Assumption: The Hidden Defect Source.

If we change the architectural defaults, we can stop building software that breaks exactly when people need it most.

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

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

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

If you want the short reading path around this topic instead of a single post, start with AI Agents Under Protective Computing: Start Here.

For the broader trust and release path this also belongs to, read this sequence:

Quality gates that earn trust
Maintaining truthful docs over time
ProofVault as a Release Artifact: Turning Trust Into Something You Can Verify
Preview Mode First: Agent Plans as PRs (Plan Diff + Invariants)
The Overton Framework is now DOI-backed

Think of every agent run as a PR proposal:

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

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

The mantra

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.

Related reading:
Quality gates that earn trust
covers the same “checks you can run” posture at the repo level.

Quick reply you can reuse

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

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.

Support this work

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