diff --git a/articles/drafts/when-not-to-test.md b/articles/drafts/when-not-to-test.md
index 01318e0..332dedc 100644
--- a/articles/drafts/when-not-to-test.md
+++ b/articles/drafts/when-not-to-test.md
@@ -4,11 +4,20 @@ date: 2026-04-07
 topics: [philosophy, craft]
 related: []
 abstract: >
-  How do you decide when not to test something? This article offers some food for thought.
+  Most of our energy in testing goes into arguing about *how* we should test, or *what* we should test more of. Almost none goes into the far more dangerous and consequential question: **When should we deliberately choose not to test?** This is not a question of laziness or corner-cutting. It is a question of *phronesis* — practical wisdom about where our limited attention, time, and cognitive resources are best spent, and where they are actively wasted or even harmful.
 ---
 
+
 # When Not To Test
 
+### Possible directions we can explore
+Here are some rich veins I see in this topic (pick any that resonate, or suggest others):
+1. **The Aristotelian angle**: Testing as *techne* (skill) versus the *telos* of the product. When does testing become a distraction from the actual purpose of the software?
+2. **Opportunity cost and attention**: Every test you run consumes attention that could be spent on higher-risk or higher-value areas. When is testing *itself* a form of technical debt?
+3. **The illusion of control**: The belief that “if we just test everything” we will be safe. When does testing become a security blanket rather than a truth-seeking practice?
+4. **When the act of testing changes the system negatively** (performance, deployment risk, team behaviour, etc.).
+5. **Moral/philosophical dimension**: Is there a kind of intellectual cowardice in testing too much? Are we sometimes testing because we’re afraid to ship and be judged?
+
 ## Introduction
 
 (Opening provocation or observation goes here.)
@@ -21,5 +30,3 @@ abstract: >
 
 (Grounded reflection — no generic summary or call to action.)
 
----
-This is a template. Replace or delete sections as needed. Keep front-matter consistent with the standard in GROK.md.