Proof
Evidence a buyer can evaluate without taking my word for it.
For founders, technical leads, and operators deciding whether the work is credible, relevant, and worth bringing into a live product. It shows what changed, what risks were reduced, and where the source record lives.
Open where possible, DOI-backed where relevant, and tied to public repos, artifacts, or live systems when those surfaces exist.
Outcome-oriented, repo-visible, and verifiable under low-trust conditions.
What changed
Operating change matters more than principles alone.
- • Reduced default collection of dangerous data
- • Kept critical flows usable under partial connectivity
- • Replaced silent failure with explicit recovery paths
- • Produced decision-grade artifacts teams can act on
What risks get reduced
This work is aimed at trust failures that become operationally expensive.
- • Sensitive data turning into centralized exhaust
- • Critical paths failing in offline or degraded conditions
- • Ambiguous boundaries during incidents, audits, or launch pressure
- • Findings that cannot be reproduced, verified, or handed off cleanly
What kind of product this applies to
Post-MVP software where trust failure harms users or operations.
- • Health, advocacy, or clinician-adjacent tools
- • Internal operator systems with incident or coercion pressure
- • Products storing sensitive personal or behavioral data
- • Teams shipping into low-trust, low-bandwidth, or unstable conditions
Flagship case
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.
Before
Most pain tracking products assume accounts, high attention, stable connectivity, and willingness to centralize intimate health data by default.
After
Core logging stays local by default, primary use does not require sign-up, and sharing is routed through explicit exports instead of background sync assumptions.
Minimization delta
- • 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
Proof you can inspect
Boundary statement, data inventory, retention posture, and export behavior are visible.
0 account requirement for core use: users can log entries without sign-up or default account capture.
0 background sharing by default: exports are user-initiated and explicit.
A clear minimization boundary: sensitive day-to-day records stay local unless the user deliberately exports them.
Core logging flow remains available offline under partial connectivity.
Check the evidence path
Suggested inspection order.
1. Inspect the live system
See whether the product behavior matches the trust claims.
2. Inspect the repository
Review implementation history, issue shape, and whether the build is real.
3. Inspect the dossier and artifacts
Problem, constraints, minimization decisions, proof, and outputs are shown as operating evidence.
4. Inspect the canon
Use the DOI-backed framework if you want theory, methodology, and audit vocabulary.
Release-bound trust case
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.
What changed
A trust dossier, pinned specimen, verifier path, regeneration flow, and drift checks now live in the repo as part of the proof burden, and the guarantee surface is narrowed to what those artifacts can actually prove.
Why it matters
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 or an oversized claim.
Trust case excerpt
Release-bound provenance
Inspect the path
Short case, then dossier, then long-form walkthrough.
Claim surface is deliberately narrowed: the public guarantee is limited to what the specimen, verifier path, and hosted release can prove.
Pinned specimen is reproducible across local and hosted CI execution paths.
Verifier path demonstrates both valid and tampered behavior against the same specimen.
Canonical reference
A layered canon with sources of record (DOIs): foundational theory → operational translation → measurement & audit.
Layer 1 — Overton Framework v1.3 ↗Layer 2 — Field Guide v0.1 ↗Layer 3 — Protective Legitimacy Score (PLS) v1.0-rc1 ↗All canon records ↗
Start at Layer 1 (Overton Framework).
Public source surface
Public repositories, commit history, issues, and published artifacts.
Primary proof is artifact-based: DOIs, repositories, deployments, and bounded deliverables.
Flagship system
PainTracker.ca — minimization-first pain tracking PWA, local-first by default.
Redacted audit surface
Audit and security work is evidenced 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.
Defensibility Packet preview
Trust boundary reference
Audit boundary reference
How to evaluate the work quickly
Applicable
The evidence should look relevant to your product category, threat model, and operating constraints.
Verifiable
Claims should resolve to a repo, DOI, deployment, artifact, or explicit failure-mode analysis.
Actionable
The output should suggest how your team would change architecture, operations, and release decisions.
Integrity stance
The work is designed for adversarial environments: low trust, coercion risk, degraded infrastructure. Verification beats narrative.
Rule
Proof over promises.
Every claim should have a source of record: DOI, repo, deployment, or artifact.
Fetchability diagnostics
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.
Primary checks
- • /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
Mirror checks
- • /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)
Command check (GET, primary): curl -sS -D - -o NUL -A "python-requests/2.31.0" https://crisiscore-portfolio.vercel.app/site-map