diff --git a/style_bibles/IF.DAVE.BIBLE.md b/style_bibles/IF.DAVE.BIBLE.md
index e891b41..3c61dff 100644
--- a/style_bibles/IF.DAVE.BIBLE.md
+++ b/style_bibles/IF.DAVE.BIBLE.md
@@ -1,8 +1,17 @@
-# IF.DAVE.BIBLE v1.2 (mirror-first)
+# IF.DAVE.BIBLE (legacy pointer)
 
 **Author:** InfraFabric Red Team  
 **Status:** SATIRE / SOCIOTECHNICAL RED TEAM TOOL  
-**Citation:** `if://bible/dave/v1.2`
+**Citation:** `if://bible/dave/legacy`
+
+This file is kept for backward compatibility.
+
+Current version:
+- `re-voice/style_bibles/IF_DAVE_BIBLE_v1.6.md` (`if://bible/dave/v1.6`)
+
+---
+
+# IF.DAVE.BIBLE v1.2 (mirror-first)
 
 > This is satire. “Dave” is a pattern, not a person.  
 > Use it to pressure-test documents for dilution risk, not to make real-world decisions.
diff --git a/style_bibles/IF_DAVE_BIBLE_v1.6.md b/style_bibles/IF_DAVE_BIBLE_v1.6.md
index 2e487c0..aca2763 100644
--- a/style_bibles/IF_DAVE_BIBLE_v1.6.md
+++ b/style_bibles/IF_DAVE_BIBLE_v1.6.md
@@ -79,6 +79,13 @@ Rules:
 
 v1.6 note: highlight how artifacts enable deniability, not accountability.
 
+Required framing (short, reusable, but do not repeat verbatim across sections):
+- A screenshot of a control proves only that someone can produce a screenshot.
+- If it can be API-verified, it can be automated. If it must be uploaded, it will be gamed.
+
+Also consider (when the source is about scanning/guardrails):
+- **Noise is a bypass engine:** if the control is too noisy (false positives, flaky rules), developers will route around it. Do not claim this is true for a specific tool unless the source states it; treat it as a rollout failure mode to test for.
+
 ---
 
 ## 1) Prime directive: mirror the source dossier
@@ -164,6 +171,11 @@ Use these rhetorical moves **inside each source section** while keeping the orig
 - Preferred diagram types: `flowchart TD`, `sequenceDiagram`, `stateDiagram-v2`.
 - Validate diagrams before publishing (syntax-check Mermaid; no parse errors; no broken code fences).
 - Tailor each Mermaid to the section-specific flow; avoid generic structures reused across sections (templated feel is a trust killer).
+- If the section describes governance or review processes, prefer diagrams that show **friction**:
+  - loops (exception → review → “pending” → renewal)
+  - stasis states (e.g., “Pending review” that effectively equals “Approved”)
+  - dead ends (handoffs to Legal/HR/Procurement)
+  Keep diagrams truthful to the section’s facts; do not invent named systems or hard numbers.
 
 ## 4c) Anti-repetition (cross-doc rule)
 
@@ -177,6 +189,7 @@ The dossier should feel *tailored*, not like a template ran in a loop.
   - different “stop condition” framing
   - varied closing sentences and punchlines to avoid repetition
   - different diagram view (workflow vs. feedback loop vs. swimlane)
+- Avoid “axiom sprawl”: if you introduce a named fallacy/axiom, use at most one per dossier unless the source repeats the same pattern.
 
 ---
 
@@ -202,6 +215,11 @@ Preferred motifs (use sparingly, but use them):
 - “The Blame Buffer” (consultants + juniors absorbing accountability)
 - “Hot potato routing” (push blame across teams)
 
+Universal constants (use as internal prompts, not headings; keep to 1–2 lines in output):
+- **Single pane fallacy:** a dashboard that compresses reality into green boxes no one can drill into.
+- **Exception half-life:** “temporary” exceptions either expire automatically or become architecture.
+- **Rollout taxonomy:** “available” ≠ “enabled” ≠ “enforced” (and “socialized” is zero).
+
 ---
 
 ## 5b) Red Team callout template (keep it short)
@@ -291,6 +309,21 @@ Avoid fake implementation details; keep it generic and auditable.
 
 ---
 
+## 5d) Vendor-safe conclusion (recommended)
+
+Even in v1.6, end in a way that critiques incentives rather than vendors.
+
+Format:
+- **Success conditions:** what must be true for the rollout to hold (signals, gates, expiry).
+- **Traps to avoid:** the predictable organizational failure modes (theater, drift, exceptions).
+- **Questions to ask (vendor or internal owners):** opposable, testable questions.
+
+Rules:
+- Do not claim the vendor/tool fails; claim what the organization must enforce for *any* tool to succeed.
+- Attribute any specific factual claims to the source (“the source states…”) when not independently verified.
+
+---
+
 ## 6) Vocabulary replacement table (small Rosetta stone)
 
 | If the source says… | Dave rewrites it as… |
@@ -335,4 +368,3 @@ Some audiences want realism without sharp satire. Support three tone levels with
 Tip: default to **Operational** when aiming for broad vertical applicability; reserve **Full Satire** for audiences that explicitly want it.
 
 Never introduce emojis unless present in source, regardless of tone.
-