Release evidence, trust case materials, and verification receipts.
Start here if you want to verify the work. This page shows what can be inspected, what order to inspect it in, and where the public source record lives.
What this page is not: not a claim of perfect security, universal protection, or guaranteed outcomes. It is an inspection surface.
Release evidence, trust case materials, verification receipts, and links into the public proof-of-work behind the commercial claims.
Review one case, inspect one artifact, then inspect the public repo and supporting records.
No claim here should be read as perfect security, universal protection, or a substitute for your own review.
Public proof-of-work, public docs, and inspectable artifacts that anchor the commercial trust path.
PainTracker shows minimization-first health logging with local default storage, no account requirement for core use, and explicit export.
ProofVault shows how claims were narrowed to what the release process could actually prove through pinned specimens, verifier paths, CI, and drift checks.
Protective Computing and the Overton Framework provide the doctrine, DOI-backed records, and audit vocabulary behind the work.
- Read the PainTracker case.
- Inspect the redacted threat model excerpt.
- Review the ProofVault trust case.
- Check public source records.
- Send your product URL if the failure pattern looks familiar.
If the proof surface feels close to your situation, send the URL and the failure you're worried about.
I'll tell you which proof path is most relevant, what I would inspect first, and whether the service fit is real.
- • Send URL + stage + one concern.
- • Start from contact and send only the basics.
- • Skip decks and long docs.
Usually answered within 1-3 business days with fit, first checks, and suggested package.
Start with a 48-hour teardown if you need the first risks fast. Use a full review if you need a deeper buyer-ready risk map.
Reduced default centralization of sensitive health-adjacent data and kept core use local by default.
- • Reduced default collection of dangerous data
- • Kept critical flows usable under partial connectivity
- • Replaced silent failure with explicit recovery paths
- • Made sharing explicit instead of background-assumed
Turned trust claims into release-bound evidence with a narrower, more defensible guarantee surface.
- • Tied public claims to hosted-green release evidence
- • Reduced unearned claim surface
- • Made drift a visible failure condition
- • Left a clearer inspection path for skeptical buyers
You are not buying theory. You are buying a clearer risk picture, fewer bad assumptions, and a faster path to practical fixes.
- • Less risky default collection
- • Fewer hidden trust failures near launch
- • Clearer boundaries for product and engineering teams
- • Proof a buyer can inspect without a long sales call
PainTracker: minimization-first redesign for a trust-sensitive workflow
Minimization-first pain documentation built to reduce dangerous collection, keep core use on-device, and stay usable under degraded conditions.
Most pain tracking products assume accounts, stable connectivity, and default centralization of intimate health data.
Core logging stays local by default, primary use does not require sign-up, and sharing happens through explicit exports instead of background sync.
- • Removed default collection paths that centralize sensitive symptom history
- • Moved day-to-day ownership to on-device storage by default
- • Replaced ambient sharing assumptions with explicit user-initiated export
Boundary statements, data inventory, retention posture, and export behavior are all visible.
Suggested inspection order for a buyer evaluating fit.
See whether the product behavior matches the public claims.
Review implementation history, issue shape, and whether the build is real.
Problem, constraints, decisions, and outputs are shown as evidence.
Use the DOI-backed framework if you want the deeper method behind the work.
ProofVault: bounded trust evidence tied to the hosted-green release
A deliberately bounded trust case that reduces unearned claim surface through a pinned specimen, drift enforcement, and hosted-CI provenance.
A trust dossier, pinned specimen, verifier path, regeneration flow, and drift checks now live in the repo. The guarantee surface is narrowed to what those artifacts can prove.
Hosted CI became the release gate, so the public trust case is tied to the exact final non-debug commit, not a locally-green approximation.
Short case first, then dossier, then long-form walkthrough.
Start with the bounded materials that directly support commercial trust review.
If you want the deeper method behind the service work, the canon shows the operating model behind the artifacts.
Public repositories, commit history, public docs, and published artifacts.
The GitHub org exists in this trust path as public proof-of-work: a place to inspect code, docs, and artifact history rather than accept marketing claims on faith.
PainTracker.ca — minimization-first pain tracking PWA, local-first by default.
Audit and security work is shown through bounded outputs, remediation structure, and a redacted artifact sample.
- • A bounded risk register prioritized to top findings (typically 10) with triage order.
- • A threat model with explicit assumptions and hard boundaries (what must not fail).
- • Actionable findings: reproduction steps, impact, and recommended fixes.
- • A remediation plan ordered by risk reduction per unit effort.
- • Verification steps: tests or procedures that prove the issue is closed.
Fastest path: review the flagship case, inspect one redacted artifact, then send your product details.
Start with the commercial case-study route, then confirm the matching PainTracker case surface.
Inspect the defensibility packet, threat model excerpt, and release-bound trust materials.
Use the GitHub org, live systems, and fetchability diagnostics to confirm the inspection path is real.
The work is designed for adversarial environments: low trust, coercion risk, degraded infrastructure. Verification beats narrative.
Every claim should have a source of record: DOI, repo, deployment, or artifact.
Quick verifier for non-browser clients. Primary checks are HTML-first; mirror checks cover XML, RSS, and raw mirrors that should also be verified from a second network.
- • /proof/fetchability.json — machine-readable verification targets
- • /deploy-id — plaintext no-store deployment canary
- • /site-map — HTML sitemap (primary)
- • /artifacts/pain-tracker/architecture — HTML artifact viewer
- • /artifacts/security-and-audits/redacted-threat-model-excerpt — HTML artifact viewer
- • /artifacts/security-and-audits/defensibility-packet-preview — HTML artifact viewer
- • /sitemap.xml — XML mirror for crawlers
- • /rss.xml — RSS mirror for non-browser readers
- • /artifacts/pain-tracker/architecture — HTML viewer (raw: /projects/pain-tracker/architecture.svg)
- • /artifacts/pain-tracker/ui-01-fastlog — HTML viewer (raw: /projects/pain-tracker/ui-01.svg)
- • /artifacts/security-and-audits/redacted-threat-model-excerpt — HTML viewer (raw: /projects/security-and-audits/redacted-threat-model-excerpt.md)
- • /artifacts/security-and-audits/defensibility-packet-preview — HTML viewer (raw: /assets/proof-cards/defensibility_packet_preview_wide_16x9.svg)