Writing
Founder-facing problem posts, essays, and doctrine behind the service work on this site: trust boundaries, privacy architecture, minimization-first systems, and degraded-condition design.
This section now does two jobs: plain-English demand capture for founders with an immediate problem, and deeper doctrine for buyers who want to inspect the reasoning. Most visitors should still start with the commercial case study or Proof.
Start with the cluster that matches the pressure you are under now: launch, buyer review, health workflow trust, minimization, or deeper method inspection.
Launch and Buyer Review
Founder-facing checks for launch pressure, buyer scrutiny, procurement review, and the first trust questions that surface before a sensitive-data product ships.
The trust, privacy, and boundary failures founders often miss before launching a sensitive-data product.
A practical launch checklist for sensitive-data products covering collection, consent, recovery, export, retention, and public trust claims.
A founder-facing checklist for the product, privacy, and trust questions buyers ask when a sensitive-data app is close to procurement or partner review.
A founder-facing checklist for the product trust, privacy, and boundary questions that surface during procurement review for sensitive-data apps.
A practical guide to the artifacts, claims, and product-boundary explanations that help buyers evaluate a sensitive-data product during procurement.
Health and Wellness Reviews
Health, wellness, and mental-health-focused review paths for teams trying to narrow trust boundaries before launch or wider exposure.
A founder-facing guide to the collection, consent, storage, export, recovery, and claim checks worth doing before a health app launches.
A practical review guide for mental health apps handling emotionally sensitive workflows, low-attention use, and high-consequence trust boundaries.
A practical pre-launch privacy review checklist for health and wellness apps with risky defaults, hidden collection, or weak trust boundaries.
Why reducing collection by default is a product boundary, not a preference.
Building a chronic pain journal that reduces collection by default without breaking the product
Minimization and Product Boundaries
Plain-English posts on over-collection, retention, export, and the product-boundary decisions that create trust debt when nobody narrows them early.
A plain-English guide for founders whose product is collecting more user data than it needs.
A founder-friendly data minimization checklist for sensitive apps before launch.
A launch-focused guide to reviewing prompts, outputs, logging, retention, and claim boundaries for AI health products handling sensitive user data.
Method and Doctrine
The deeper explanatory layer: trust cases, Protective Computing, Overton, DOI-backed canon, and the inspection vocabulary behind the service work.
A reproducible trust case for an offline-first encrypted evidence app, with a deliberately bounded guarantee surface tied to an exact hosted-green release.
Why degraded first architecture is the only viable path for high threat environments
A method for modeling legal, operational, and digital threat surfaces
Protective Computing, now pinned to a stable canonical reference.
Everything else
Supporting posts that do not need a top-level cluster but still extend the proof and writing surface.
Protective Computing Canon (Zenodo)
A layered discipline for systems built under instability: theory → operations → measurement.
- •If you are evaluating the service, start with Proof before going deep here.
- •If you are close to launch or buyer review, start with the first writing cluster.
- •Read the canon if you want the method and vocabulary behind the work.
- •Use Projects for dossiers and implementation-facing evidence.
- •If the thinking matches your product risk, go to Services or Contact.