From 204df0f2ad6ec159aa61120315607ec40db57b1b Mon Sep 17 00:00:00 2001 From: Paul Hitt Date: Mon, 28 Sep 2026 14:52:13 -0400 Subject: [PATCH] README: plainer wording Co-Authored-By: Claude Opus 5.5 --- README.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 0c6e4b1..9eb93d3 100644 --- a/README.md +++ b/README.md @@ -5,8 +5,7 @@ resource class, including the billing that tends to outlive it. ## What it does and why -Deleting is the easy half. The hard half is proving nothing remains, and the -two failures that matter are both invisible to the delete path itself. +Deleting is straightforward. Proving that nothing remains is harder, and the two failures that matter are both invisible to the delete path itself. ### Billing outliving compute @@ -21,8 +20,7 @@ so KillSwitch reports it as a separate critical finding and prints it first. A `DELETE` that returns 200 means the API accepted the request. It does not mean the resource is gone. A teardown whose only evidence is its own success response has verified nothing, so an `absent` state backed only by -`delete-response` is reported as not assessed. That is the difference -between terminated and verifiably terminated. +`delete-response` is reported as not assessed. KillSwitch never deletes anything. It takes an inventory you enumerated and decides whether the removal can be evidenced. There is no network access and