session 2026-08-02 evening: Control Kernel v1.0→v1.1, reduction arm, CONTROL-A/B, trial 04 VOID, correlation 01

Session record, memory updates and KG appends for the evening session.

Filed: Control Kernel v1.0 (frozen, superseded) and v1.1 (governing); the
reduction arm and its two censuses; CONTROL-A and its defect twin with a
bidirectionally-gated ledger; trial 04 (CONTROL VOID) and its pre-registration;
correlation 01 — the first measurement of Constraint 6's own falsifier, jurist
4-of-6 and Fool 0-of-6 with no overlap.

New feedback memory: removing a claim is not the same as removing the reliance on
it. Earned by finding that draft 3's "fix" to CONTROL-A had CONCEALED a defect
rather than closed it — invisible to me, the kernel and four gates, found by a
differently-formed reader.

Verification ladder: the discrimination gate — a check must return different
verdicts on two REAL artifacts, one with the property and one without.

6 KG lines: two drift-patterns, one good-direction, two preventions, and the
Constraint 6 first-measurement.

claude/memory/feedback-removing-a-claim-is-not-removing-the-reliance.md

@@ -0,0 +1,21 @@
+---
+name: feedback-removing-a-claim-is-not-removing-the-reliance
+description: "Deleting an unsupported sentence can hide the gap instead of closing it — the reliance survives, now implicit and invisible to every check. Caught 2026-08-02 when a jurist found in CONTROL-A the exact defect I had reported removing."
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: f01230e1-d62d-4195-8e21-356429806fbd
+  modified: 2026-08-02T17:10:19.496Z
+---
+
+**Removing a claim is not the same as removing the reliance on it.** When you find a sentence that asserts more than its support gives, deleting or softening the *sentence* can leave the *dependency* fully intact — and now implicit, so neither you nor any mechanical check can see it. The document reads cleaner and is less sound.
+
+**Why:** the fix that feels like rigour is the visible one. An explicit unsupported claim is embarrassing to look at, so the reflex is to take it out. But the conclusion downstream still needs what that claim was supplying. Deleting the sentence removes the *evidence of the gap*, not the gap. The result is strictly worse than leaving it in, because the explicit version at least announces itself to the next reader.
+
+**How to apply:** when you cut an unsupported claim, do not stop at the cut. Ask *what still depends on it* and trace forward to the conclusion. Either narrow the conclusion to what the support actually carries, or add support. If neither is possible, say the gap is open — an open gap is inheritable; a hidden one is not. **The test is not "is the bad sentence gone" but "does the conclusion still need it".**
+
+**Earned (2026-08-02, Fool trial 04).** Draft 2 of a control document said *"This file, having a stated review date, is to be flagged when it drifts."* I identified it as unsupported — `~/CLAUDE.md` states a revision *cadence*, not a review date — and reported removing it. What I actually did was **drop the qualifier from the obligation itself**, restating *"flag documents that have drifted from their **stated review dates**"* as *"A document that has drifted is to be flagged."* Everything downstream still relied on the wider obligation. The jurist (Fable 5, blind read) found it; I had not, and neither had the kernel, four mechanical gates, or a self-audit written deliberately as if it mattered.
+
+Sharpest form of the lesson: the deliberately-defective **twin** of that document carried the *explicit* version of the same error, labelled as a defect — and **the concealed version in the "sound" document was the one that survived review.**
+
+Kin: [[feedback-checkable-claim-surfaces-bugs]] · [[feedback-completion-is-a-tripwire]] · [[reference-verification-ladder]] (the discrimination-gate entry, same session).