DEV Community

CrisisCore-Systems
CrisisCore-Systems

Posted on • Edited on • Originally published at github.com

Protective Computing Canon v1.0 is now DOI-backed

#privacy #a11y #security #opensource

If you want the trust and release path instead of a single announcement, read this sequence:

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

If you want the doctrine route that this canon supports, start with Architecting for Vulnerability: Introducing Protective Computing Core v1.0.

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

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

That means a stable, versioned citation you can use in papers, docs, and reviews—without link rot or “which PDF did you mean?” ambiguity.

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

Protective Computing Community.

DOI: 10.5281/zenodo.18887610

Canonical citation (use this exact line)

Overton, K. (2026). Protective Computing Canon v1.0: A Structural Map of the
Discipline. Protective Computing Community.
https://doi.org/10.5281/zenodo.18887610

What the framework is

Most software quietly assumes users have:

  • stable connectivity
  • stable cognition
  • stable safety
  • stable institutional trust

The framework names that as the Stability Assumption and treats it as a design hazard.

Protective Computing is a systems orientation for building software that
stays safe and usable when those assumptions fail: during medical crisis,
coercion, environmental disruption, and socioeconomic precarity.

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’s inside the canon (high level)

The canon is intentionally written to be checkable, not inspirational:

  • A definition of Stability Bias and how it shows up in real systems
  • A Vulnerability State Machine (how user conditions shift, and what systems must do as they shift)
  • Five normative design principles written in RFC-style requirement language (MUST / SHOULD)
  • A provisional composite metric (PLS) with explicit caution about Goodhart’s Law

Where to read it

If you prefer reading in-repo text first:

Reference implementation (so it isn’t just theory)

Frameworks don’t matter unless they survive contact with a live codebase.

Pain Tracker is an open-source, local-first pain documentation system that’s
used as a reference implementation target for many Protective Computing
constraints (local-first defaults, careful trust boundaries, trauma-informed
UX, exports treated as a security boundary).

Important nuance: some integrations exist (for example correlation services and
clinic/payment workflows), but they require explicit configuration/enabling and
should be treated as separate trust boundaries.

What feedback I’m asking for

If you build systems that touch high-vulnerability contexts (health, crisis
response, legal aid, shelters, disability tooling, harm reduction), the most
useful feedback is specific:

  • Where the principles are too vague to be operational
  • Where the requirements are too strict to be buildable
  • What would make “protective” more testable without turning it into a gameable score

Links

Top comments (0)