re-voice/style_bibles/IF_DAVE_BIBLE_v2.4.md

IF.DAVE.BIBLE v2.4 (mirror-first, episode framing, podcast-ready, sponsor bumper)

Author: InfraFabric Red Team
Status: SATIRE / SOCIOTECHNICAL RED TEAM TOOL
Citation: if://bible/dave/v2.4
Changes from v2.3: Adds an optional “word from our sponsors” mid-thread bumper (series_mode only), hardens Claims Register rules against truncation/junk lines, and adds a UI-friendly “seal” pattern to route skeptics to the receipt surface.

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):

---
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>`
**SOURCE DOC (online):** `<SOURCE_URL>`

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

v2.2+ required: the header must include a stable online source link.

• Prefer the no-login stable alias: https://infrafabric.io/static/source/<source_sha256>.pdf
• If the URL is long, use a short Markdown label (e.g., [Source PDF]) and keep the full URL as the link target.

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):

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

v2.2+ note: keep it cold. “Vendors promise speed. Dave delivers the stall.”

0a) Episode framing (v2.2+ required for week packs)

Week packs should be readable by someone who never opened the source PDF.

When the source file is a week-pack day (e.g., mon.pdf, tue.pdf):

• Replace ambiguous titles like ## mon with the weekday: ## Monday, ## Tuesday, etc.
• Add a single, TV-friendly subtitle line: ### <Company> | <Report Title>
• Then immediately include a short intro (see 0aa) before the first mirrored section.

This is presentation only. Do not change section order, numbers, or source claims.

0aa) “Time journalist” intro (v2.2+ required)

After the header + protocol block, include a short intro that:

• Names the vendor/org and the document being covered (1 line).
• Gives a 1–2 line summary in plain terms.
• Explains how to read the dossier (no PDF required; we quote as we go; we add short Red Team notes; receipts are in the pack/trace).
• Ends with: OK. Let’s dig.

Tone rule: dry, credible, forwardable. No emojis unless present in the source.

0ab) Podcast script (v2.2+ required)

Append a plain-text section for audio generation (e.g., ElevenLabs):

• Heading: ## Podcast Script (plain text)
• Put the script in a ```text code fence.
• The script must:
  • Explain the dossier’s reading mode (“you don’t need the PDF open; we quote it as we go”).
  • Describe each Mermaid diagram in simple language (sequence + decision points).
  • Avoid adding new factual claims; only paraphrase what’s in the dossier/diagrams.

This is narration for accessibility, not additional analysis.

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.
• 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.
• Do not include if://bible/... (or any other if:// URI) in public-facing dossier output; use the stable https:// receipt surface instead.

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. Resolve them before output.
• Vertical flavor must not override source facts, numbers, caveats, or obligations.

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

Operational concreteness (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 series_mode=true, the generator must additionally emit a Thread Pack distribution layer (without rewriting the dossier).

Thread Pack (daily) structure (suggested):

1. Evening “Next On” teaser (previous day 8:00 PM EST)
2. Day-of Pre-Show promo (6:00 AM EST) with one hero diagram
3. Main Episode thread (5–7 posts: hook + visuals + short quotes + links + poll + next-day tease)

Constraints:

• Thread Pack must preserve classification framing and edition branding.
• Thread Pack must not exceed the quoting budget (see 1c).
• Thread Pack is a distribution layer; the dossier remains the canonical mirror.

v2.1+ required: the thread must explicitly route curiosity to the receipt surface.

• Include one line that says, in plain English, that the source was fingerprinted so it can’t be silently edited later (example: PDF hashed (sha256: 6153…b7c) so it can’t be “updated” after the roast.).
• The receipt link must be framed as verification, not compliance. Preferred copy:
  • “Verify I didn’t hallucinate this.”
  • “Proof the PDF said this.”
  • “Receipt + roast.”

Visual asset pack (optional; thread pack / landing pages only):

• Use these to make the “classified” look instantly legible (no new claims; purely visual).
• Stamp: https://infrafabric.io/static/hosted/review/assets/eyes-only/red-ream-600-600.png
• Hero: https://infrafabric.io/static/hosted/review/assets/eyes-only/red-team-doc-1024-559.jpg

0f) Trojan Horse CTA (required)

The Shadow Dossier is the hook. The receipt is the payload.

Rules (black/white):

• Never frame IF.TRACE/T3 as “compliance magic”. Frame it as anti-hallucination proof:
  • “This binds the source fingerprint to the output fingerprint.”
  • “If you can’t verify it, treat it as a claim — not a fact.”
• Do not lead with crypto jargon on the first click.
  • Allowed: “VERIFIED”, “WARNING”, “FAIL”.
  • Allowed: “QUANTUM READY” (receipt present).
  • Not allowed: “quantum-secure”, “FIPS-compliant”, “post-quantum” as headline claims unless strictly qualified and scoped.

Practical output requirement:

• Every dossier must make it easy for a skeptic to answer one question:
  • “Did the source actually say that?”

UI-friendly pattern (recommended for HTML views / landing pages):

• Add a small “seal” element that reads: Verifying integrity… → VERIFIED and links to https://infrafabric.io/static/trace/<shareId>.
• Copy should stay skeptic-first: “Verify I didn’t hallucinate this.” (not “view compliance trace”).

0g) “Word From Our Sponsors” bumper (optional, series_mode only)

When series_mode=true, you may insert one 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 + receipts only.
• Use InfraFabric branding sparingly (InfraFabric.io link allowed once per bumper).

Variant bank (rotate; no repeat within a 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. 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. Made possible by InfraFabric Red Team — publishing receipts, not vibes. https://infrafabric.io

---

1c) Quoting Budget (required for Thread Pack)

Hard cap:

• Max 4 short verbatim quotes in Thread Pack.
• Quotes must be attributed as: The source claims: “…”.

---

1d) Minimum Content Contract (required)

Every dossier must contain:

• At least 3 mirrored source sections (preserving order/headings) or be explicitly marked MIRROR COMPLETENESS: DEGRADED.
• At least 1 > **The Dave Factor:** callout (tied to a prominent mirrored point).
• A Claims Register when the source contains measurable claims (numbers, %, retention windows, tiers).
• An Action Pack by default (see 5c), unless explicitly disabled for the run.
• At least 2 Mermaid diagrams (one friction loop, one stasis) with source-anchored labels where possible.

Failure mode: if you cannot meet this contract without guessing, degrade or fail—do not improvise.

---

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 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).
• Prefer diagram labels anchored to source lexicon (tiers, retention windows, “enforcers”, “AAL3”, “FIPS”) when present.
• Validate diagrams before publishing (syntax-check Mermaid; no parse errors; no broken code fences).
• Do not use emojis inside Mermaid nodes/labels unless those emojis exist in the source.
• Deduplication rule: render each unique diagram once per dossier (e.g., in an Annex section). Reference by name in-section (“See Annex: Evidence Drift Loop”). Vary node labels/friction points per daily edition using source-specific terms. Prohibit identical Mermaid code blocks repeated across sections.

---

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 terminal clause across sections.
• Avoid “axiom sprawl”: introduce at most one named fallacy/axiom per dossier unless the source repeats the same pattern.

Edition motif banks (for weekly TV lineups; required when posting a week):

• Enterprise: procurement routing, platform sprawl, “single pane” storytelling, audit seasons.
• Cloud: shared responsibility shrug, “100% visibility” illusion, misconfigured defaults, noisy signals.
• Endpoint: agent bloat, rollback promises, noisy detections → bypass, “autonomous” → supervised exceptions.
• COMSEC: certification stalls, waiver workflows, key ceremony theater, compliance gating by calendar.
• Startup: hype-to-pilot drift, “hyper-automation” → hyper-escalation, feature flags as policy.

Weekly rule:

• Within one week, do not reuse the same primary motif across two editions.

Extended anti-repetition (required):

• Limit The Dave Factor callouts to 1–2 per dossier (one core, one variant). Use them where they bite hardest; do not smear the same voice block across every section.
• Prohibit duplicate prose lines beyond intentional emphasis (max 2x). If you need to echo a point, rephrase it.
• In traces, flag repeats >2 as warnings; aim for zero non-intentional duplicates.

---

5) Humor guidelines (cold, specific, vendor-neutral)

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: forwardable internally without an apology.
• Reuse real numbers from the source (dates, %, costs, counts) to make the sting feel earned; do not invent stats.

---

5b) Red Team callout template (short)

Inside a mirrored section, include a short callout only when it adds explanatory power.

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

Optional (when it adds clarity):

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

---

5c) Operationalization pack (default appendix)

Append an Action Pack after the mirrored content.

Required outputs:

Output A: Control Cards (per major section)

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

Output B: Backlog export (Jira-ready)

• Ticket title
• Acceptance criteria
• Evidence/telemetry requirement

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

Keep it generic and auditable; avoid fake implementation details.

Deduplication and variation rules (required):

• Render the core control card template once in an Annex (“Universal Gate Template”).
• Per-section cards must vary at least two fields (e.g., Gate, Stop condition, Evidence) using source lexicon.
• Policy-as-code YAML: render once per dossier (or once per week in a full week pack). Add edition-specific fields only when anchored to source terms (e.g., endpoint: agent_signal_freshness_days).
• Backlog export: limit to 3–5 unique tickets; consolidate duplicates.

v2.3+ required: include at least one “receipt-first” control.

• Control objective: make claims provable (source fingerprint + output fingerprint).
• Stop condition: block promotion/rollout claims that cannot be bound to a receipt.
• Evidence: source_sha256 + output_sha256 + receipt_url (public where possible).

Translation Table (standards sources; recommended)

If the source is a standard (e.g., NIST):

• Extract a small set of terms that appear in the source (e.g., PDP/PEP, least privilege, continuous diagnostics).
• Provide a translation table mapping each term to an enforceable gate and stop condition.
• Label this as InfraFabric Red Team synthesis (not source text).

Annex for shared assets (recommended for all dossiers):

• Shared Diagrams (render unique Mermaids here once)
• Universal Control Template
• Core Policy-as-Code
• Motif Reference

In-body references should point to the Annex (example: “See Annex: Evidence Drift Loop (adapted for )”).

---

5d) Vendor-safe conclusion (recommended)

End by critiquing 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: opposable, testable questions (vendor or internal owners).

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.

v2.3+ recommended question:

• “Can we verify this claim later with a source/output receipt, or is it just a slide?”

---

6) Claims Register (required when the source contains measurable claims)

When the source includes measurable claims (numbers, %, retention windows, tiers), include:

Claims Register (source-attributed)

• The source claims: “<verbatim line>”

Rules:

• Cap at 3–7 claims; choose the most distinctive/measurable claims only.
• Claims must be complete sentences/clauses. If a claim is truncated (“27% of AI-”), treat it as unusable and omit it.
• If the claim is split across lines (PDF hyphenation), stitch it into one clean quote; do not rewrite.
• Do not “normalize” or “improve” claims. If the extracted line is unusable, omit it rather than rewriting it.

---

7) Required footer (always)

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.

---

8) Format correctness (non-negotiable)

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

• JSON/YAML/code blocks must be syntactically valid.
• Mermaid blocks must render.
• Do not fabricate tables/logs that look real; prefer clearly labeled placeholders.

---

9) Tone modes (optional)

Support three tone levels without changing mirror 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.

Never introduce emojis unless present in source, regardless of tone.