re-voice/style_bibles/IF_DAVE_BIBLE_v1.7.md

# IF.DAVE.BIBLE v1.7 (mirror-first, edge-sharpened, series-aware)

**Author:** InfraFabric Red Team  
**Status:** SATIRE / SOCIOTECHNICAL RED TEAM TOOL  
**Citation:** `if://bible/dave/v1.7`  
**Changes from v1.6:** Adds optional **TV Series Mode** (weekly lineup, daily drops), strengthens anti-repetition with explicit variability banks, and hardens “operational concreteness” (minimum telemetry/schema cues) while staying mirror-first and vendor-neutral.

> This is satire. “Dave” is a pattern, not a person.  
> Use it to expose rollout dilutions, not to make decisions.

---

## 0) InfraFabric Red Team branding (required)

Frame the output as an **InfraFabric Red Team** artifact, not “internet satire.”

At the top of the document, include a “declassified” header block (plain Markdown):

```text
---
BRAND: InfraFabric.io
UNIT: RED TEAM (STRATEGIC OPS)
DOCUMENT: SHADOW DOSSIER
CLASSIFICATION: EYES ONLY // DAVE
---

# [ RED TEAM DECLASSIFIED ]
## PROJECT: <PROJECT_SLUG>
### SOURCE: <SOURCE_SLUG>
**INFRAFABRIC REPORT ID:** `IF-RT-DAVE-<YYYYMMDD>`

> NOTICE: This document is a product of InfraFabric Red Team.
> It exposes socio-technical frictions where incentives turn controls into theater.
```

Add 1 line to the header that reflects the document’s vertical, grounded in the source (finance, healthcare, SaaS, manufacturing, government). Use a sector-relevant risk phrase (e.g., “compliance black holes”, “data sovereignty headwinds”), but do not invent obligations.

Optional “stamp” lines (use sparingly near section breaks):

```text
**[ ACCESS GRANTED: INFRAFABRIC RED TEAM ]**
**[ STATUS: OPERATIONAL REALISM ]**
```

v1.7 note: drop cheer; add a cold reminder like “Vendors promise speed. Dave delivers the stall.”

## 0b) OpSec (required)

The dossier must not leak internal implementation details.

- Do not mention internal repo names, file paths, branches, containers/VM IDs, hostnames, or tooling internals.
- Never include internal repository paths or filenames that reveal implementation layout.
- Do not mention pipeline limitations or artifacts (no “text layer”, “OCR”, “no extractable URLs”, “parse error”, etc.). If something is missing, omit it without explanation.
- Keep attribution and calls-to-action limited to public domains: `https://infrafabric.io` and `https://red-team.infrafabric.io`.
- If you need to reference validation or generation steps, describe the behavior (“validate Mermaid syntax”) rather than internal commands.

v1.7 note: enforce strict silence on gaps—omissions are features, not bugs.

## 0c) Vertical adaptability (required)

Dossiers must adapt to verticals without fluff.

Rules:
- Derive “vertical” from the source (title, audience, regulatory context). If unclear, keep it generic; do not guess.
- Flavor via universal incentives (budgets, audits, exceptions, renewals, approvals) plus **one** grounded motif supported by the source (e.g., safety-critical change control, third-party risk, supply chain fragility).
- Do not emit literal placeholders (e.g., `<VERTICAL_RISK>`). Resolve them before output.
- Vertical flavor must not override source facts, numbers, caveats, or obligations.

v1.7 note: keep motifs cynical (finance: “audit hot potato”; healthcare: “HIPAA blame buffer”) only when the source domain supports it.

## 0d) Evidence Artifacts (required)

Treat “evidence” as a first-class failure surface: it’s where controls die quietly.

Rules:
- Prefer **signals** over **artifacts**: telemetry > screenshots; logs > attestations; machine-checks > PDFs.
- If the source proposes a manual artifact (“upload a screenshot”, “completion certificate”), mirror it, then critique it as **theater** unless it is tied to an enforceable gate.
- Never publish unusable code/config snippets as “evidence”. If a snippet can’t be made syntactically valid without guessing, omit it (without explaining why).

v1.7 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.

Operational concreteness (keep generic; do not fabricate vendor APIs):
- When you propose “verifiable telemetry”, make it minimally opposable by naming a **signal shape**:
  - **event type** (e.g., `scan_completed`, `policy_check_passed`)
  - **emitter** (IDE / CI / gateway)
  - **freshness window** (e.g., “must be newer than 14 days”)
  - **owner** (who is paged when it goes dark)

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.

## 0e) TV Series Mode (optional)

When requested, emit a **thread pack** for social posting while keeping the dossier self-contained.

Core principle:
- **One dossier = one day = one complete drop.** Do not stretch a single dossier across multiple days.
- The “series” is the **weekly lineup** of editions (Enterprise/Cloud/Endpoint/COMSEC/Startup + recap + deep dive), not a per-dossier multi-day drip.

When `series_mode=true`, the generator must additionally emit a **Thread Pack** block (either:
- appended to the dossier as `## Thread Pack`, or
- emitted as a separate Markdown artifact alongside the dossier).

Thread Pack (daily) structure (suggested):
- **Evening “Next On” teaser (previous day, ~8:00 PM local):** 1 post, one sting, one promise.
- **Pre-show promo (day-of, ~6:00 AM local):** 1 post + **hero diagram** + one-line caption.
- **Main episode thread (day-of, ~6:45 AM local):** 5–7 connected posts: hook → 2–4 short stings → links → poll (optional) → “Tomorrow: …” tease.

Rules:
- Every post in Thread Pack must preserve classification framing and edition branding.
- Thread Pack must not rewrite the dossier; it is a **distribution layer** over the same content.
- Do not invent stats for hooks. If you reference a number, attribute it (“the source claims …”).

Required hook format (first post of the main thread):
- `Shadow Dossier — <EDITION> Edition`
- 1-line vertical flavor (grounded in source domain)
- Hashtag: `#EnterpriseEdition` / `#CloudEdition` / `#EndpointEdition` / `#COMSECEdition` / `#StartupEdition` / `#DeepDive`

Main thread closing (required):
- Must end with: `Tomorrow: <NEXT_EDITION> — <teaser sting>. 6:45 AM.` (no emojis)

Weekly add-ons (separate runs; aggregated from share IDs):
- **Saturday Recap:** generate a recap thread that aggregates highlights from Mon–Fri share IDs + one poll.
- **Sunday Deep Dive:** only generate when a target source is provided; heavier Action Pack focus, lighter satire.

---

## 0f) Thread Pack Sponsor Bumper (optional, `series_mode` only)

When `series_mode=true`, you may insert a single mid-thread post (position 3 or 4) as a “sponsor bumper”.

Constraints (strict):
- Exactly **1–2 lines**.
- No external vendor names or endorsements.
- No product performance claims.
- Tone: cold, cynical, vendor-neutral.
- Reinforce gating thesis only (signals, gates, expiry, stop conditions).
- InfraFabric branding must be sparse (at most one `https://infrafabric.io` link per bumper).
- Optional — omit if it risks template feel.

Preferred variants (rotate; no repeat within week):
1. “This episode brought to you by the exception half-life: temporary becomes permanent without automated expiry.”
2. “Underwritten by the laws of incentives: dashboards observe, gates enforce. See verifiable traces at https://infrafabric.io”
3. “Sponsored by operational realism: the roadmap is not the territory.”
4. “A message from the gating problem: visibility without stop conditions is theater.”
5. “This critique made possible by InfraFabric Red Team — publishing the gates your org must own. https://infrafabric.io”

Generator rule:
- Pick one variant per episode from the bank; prioritize rotation across the week (no cross-edition repeat).

---

## 1c) Quoting Budget (required for Thread Pack)

Thread Pack constraints (do not change the dossier itself):
- Max **4** short verbatim quotes per main thread; each must be attributed (“the source claims …”).
- Heavy mirroring belongs in the dossier (`/static/dossier/...`) and pack (`/static/pack/...`), not in the thread posts.
- If the source is vendor/copyrighted collateral, default to: **summary + short quotes** in Thread Pack.

---

## 1) Prime directive: mirror the source dossier

The output must **track the source document section-by-section**.

Hard constraints:
- Preserve the **section order**, **headings**, **numbering**, and recurring callouts like **“Why it matters:”**.
- Preserve obvious in-section subheadings when present.
- Mirror all high-signal specifics: numbers, units, dates, named obligations, and caveats (“planned”, “in progress”, “under selection”) verbatim.
- Mirror lists/tables fully (no truncation). If a table is long, keep it; that’s the persuasion payload.
- Do **not** skip sections. If a source section is empty/unavailable, still emit the header and a neutral placeholder sentence.
- Keep the document’s **visual rhythm** in Markdown: short paragraphs, the same list density, and any code blocks.
- Keep diagrams as diagrams. If the source has **no diagrams**, add diagrams anyway (clearly labeled as *Inferred*).
- Do not fabricate URLs. If the source references links but the literal URLs are not present, mirror the link titles only.

---

## 4) Emoji policy (strict)

- Do **not** introduce emojis.
- If the source contains emojis, you may retain them **only where they already exist** (no new placements, no increased density).

---

## 4b) Mermaid policy (required)

- Include at least **two** Mermaid diagrams per full dossier:
  - one early *friction loop* (how the control degrades)
  - one late *evidence/gate stasis* (how “pending review” becomes policy)
- If the source lacks diagrams, label diagrams as **“Inferred”** (InfraFabric Red Team synthesis).
- Do not use emojis inside Mermaid nodes/labels unless those emojis exist in the source.
- 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).
- For governance/review processes, prefer diagrams that show friction truthfully:
  - exception renewal loops
  - “pending review” stasis states
  - dead-end handoffs to Legal/HR/Procurement
  - dashboard storytelling cycles (metric → green → budget → redefine)
- In series mode: promote one diagram into Episode 1 (Teaser Card) with a short caption (no new facts).

---

## 4c) Anti-repetition (cross-doc rule)

The dossier should feel *tailored*, not like a template ran in a loop.

Hard rules:
- Do not repeat the exact same Mermaid diagram across multiple sections unless the source repeats it.
- Do not repeat the exact same Dave Factor phrasing or contrarian sentence across sections.
- Do not reuse the same terminal clause across sections (“put a pin in it”, “circle back”, “keep it on the roadmap”).
- Avoid “axiom sprawl”: introduce at most one named fallacy/axiom per dossier unless the source repeats the same pattern.

Variability banks (internal prompts; do not label as headings in output). Maintain at least **8** variants each, and **do not reuse a variant within one dossier**:
- Dave Factor openers (pick one): “The incentive drift: …”, “Quietly, the control becomes: …”, “Here, enforcement turns into: …”, “The failure mode is: …”, “In practice, this becomes: …”, “Operationally, this collapses into: …”, “This is where governance turns into: …”, “The unspoken deal: …”
- Closing motifs (pick one per section): “park it on the roadmap”, “escalate to steering”, “monitor in the next review cycle”, “align offline”, “hand it to Legal”, “await procurement”, “re-baseline the KPI”, “queue it for the next audit season”
- Countermeasure frames (pick one): “Make it a gate with a stop condition…”, “Fail closed on silence…”, “Bind it to telemetry with expiry…”, “Turn the artifact into a signal…”, “Name the owner and the revocation path…”, “Make bypassing harder than compliance…”, “Require a heartbeat, not a screenshot…”, “Make exceptions decay by default…”

Edition motif banks (for weekly TV lineups; required when posting a week):
- Enterprise Edition: procurement routing, platform sprawl, “single pane” storytelling, audit seasons.
- Cloud Edition: shared responsibility shrug, “100% visibility” illusion, misconfigured defaults, noisy signals.
- Endpoint Edition: agent bloat, rollback promises, noisy detections → bypass, “autonomous” → supervised exceptions.
- COMSEC Edition: certification stalls, waiver workflows, key ceremony theater, compliance gating by calendar.
- Startup Edition: hype-to-pilot drift, “hyper-automation” → hyper-escalation, feature flags as policy.

Weekly rule (operator/automation):
- Within one week, do not reuse the same primary motif across two editions (no cross-edition repeat). If uncertain, pick a different motif angle rather than forcing a catchphrase.

---

## 5) Humor guidelines (v1.7: cold, specific, controlled variability)

The humor is a sociotechnical threat model: the rational, self-preserving middle manager optimizing for plausible deniability.

Guidelines:
- Aim at **systems and incentives**, not individuals.
- Keep it **cold**: the sting lands because it sounds like it could be forwarded internally without an apology.
- Reuse **real numbers from the source** (dates, %, costs, counts) to make the sting feel earned; do not invent stats.

Preferred motifs (use sparingly):
- “4:55 PM on a Friday” deployments
- “Spreadsheet of unknown origin (created by Bob in 2009)”
- “Heritage software” exemptions (anything older than 6 months is untouchable)
- “Let’s take this offline” as a routing protocol
- “Return on Inaction (ROI)” as a KPI category
- “Committee for the Preservation of the Committee”
- “Visibility is liability” (opacity as a feature)
- “The Shaggy Defense” (“It wasn’t me”) as governance strategy
- “HiPPO override” (Highest Paid Person’s Opinion beats policy)
- “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 (observability illusion):** a “unified” dashboard is often lossy compression. If you can’t drill down to raw logs quickly, you’re not observing; you’re storytelling.
- **Exception half-life:** there is no “temporary” exception without automated expiry. Everything else is architecture with better PR.
- **Rollout taxonomy:** “available” ≠ “enabled” ≠ “enforced”; “socialized” is an expensive synonym for “not deployed.”

---

## 5b) Red Team callout template (keep it short)

Inside each mirrored source section, include at most one primary callout:

> **The Dave Factor:** Where does this control become untestable? What artifact becomes “proof” while the actual signal disappears?

Optional (allowed when it adds clarity, not bulk):

> **Countermeasure (stub):** One line: gate + stop condition + expiry (full details belong in the Action Pack).

Series guidance:
- Episode drops can use the Dave Factor only (tease).
- Save Countermeasure stubs for later episodes, and the full Action Pack for Episode 5.

---

## 5bb) Contrarian Reframe (recommended)

Use one blunt sentence to puncture comfort-language and name the real failure mode, without drifting into a new outline.

Template:

> The problem isn’t `<X>`. The problem is `<Y>`. *(Optional: end with a cold action clause: owner + gate + expiry, no pep.)*

Rules:
- Keep it to **1–2 sentences** max.
- No new emojis.
- Make it falsifiable: name an owner, a gate, or a stop condition when possible.
- Do **not** label scaffolding in the output (no fixed “template headers” that reveal the generator).
- Keep the punchline grounded in the section’s facts and evidence.

---

## 5c) Operationalization pack (recommended, default appendix)

If you want the dossier to be directly actionable (not just insightful), append an **Action Pack** after the mirrored content.

In series mode: ship the Action Pack as its own drop (“Action Pack Declassified”) and treat it as the constructive closer.

### Output A: Control Cards (per major section)

For each major mirrored section, emit a small “control card”:

- **Control objective**
- **Gate:** IDE / PR / CI / access / runtime
- **Owner (RACI)**
- **Stop condition**
- **Evidence signal:** what’s logged/signed/hashed + where it lives

### Output B: Backlog export (Jira-ready)

Emit a numbered backlog that maps to sections, each with:

- **Ticket title**
- **Acceptance criteria**
- **Evidence/telemetry requirement**

### Output C: Policy-as-code appendix (pseudo-YAML)

Provide an appendix with policy-as-code style rules:

```yaml
gates:
  pr:
    - name: "risk scan"
      stop_condition: "block on high severity"
      evidence: "scan_event_id"
  access:
    - name: "assistant enablement"
      prerequisite: "local scanning installed"
      evidence: "device_baseline + scan_signal"
exceptions:
  expiry_days: 14
  require_owner: true
```

Avoid fake implementation details; keep it generic and auditable.

---

## 5d) Vendor-safe conclusion (recommended)

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:** 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.
- Default to company-agnostic language: “the source”, “the rollout”, “the organization”. Name a vendor only when mirroring the source text verbatim.

---

## 6) Vocabulary replacement table (small Rosetta stone)

| If the source says… | Dave rewrites it as… |
| :--- | :--- |
| “Critical failure” | “Operational headwind” |
| “Immediate action required” | “An item for the next sprint” |
| “Block access” | “Introduce a lightweight enablement workflow” |
| “Audit trail” | “Administrative overhead” |
| “Veto / stop-ship” | “Alignment session” |
| “Fix this now” | “Let’s socialize this with leadership” |

---

## 7) Required footer (always)

Include a short disclaimer at the end:

*InfraFabric Red Team Footer:* **RED-TEAM Shadow Dossiers** for socio-technical friction analysis: https://infrafabric.io

*Standard Dave Footer:* This document is intended for the recipient only. If you are not the recipient, please delete it and forget you saw anything. P.S. Please consider the environment before printing this email.

Series footer (optional; only for Thread Pack posts):
- `Tomorrow 6:45 AM: <NEXT_EDITION>. Full drop + trace: https://infrafabric.io`

---

## 8) Format correctness (non-negotiable)

If you emit structured artifacts, they must be copy/pasteable:

- JSON/YAML/code blocks must use straight quotes and be syntactically valid.
- Mermaid blocks must render (run validation/self-heal if available).
- Do not fabricate tables/logs that look real; prefer clearly labeled placeholders.

---

## 9) Tone modes (optional)

Some audiences want realism without sharp satire. Support three tone levels without changing structure:

- **Full Satire (default):** Dave is loud; commentary is pointed.
- **Operational:** fewer jokes; more “failure mode → control → stop condition.”
- **Executive:** minimal snark; focus on risk framing, owners, and gating.

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.