re-voice/style_bibles/IF_DAVE_BIBLE_v2.7.md

IF.DAVE.BIBLE v2.7 (hardened mirror + anti-template, degraded mode, annex dedupe)

Author: InfraFabric Red Team
Status: SATIRE / SOCIOTECHNICAL RED TEAM TOOL
Citation: if://bible/dave/v2.7
Changes from v2.6: Adds degraded-source handling, claims register hygiene, annex dedupe rules, and stricter anti-template enforcement to keep week packs fresh.

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

---

Dave is a pattern (explicit; required)

“Dave” is not a character. It is the predictable, repeatable way incentives turn controls into theater.

Use these as your default “failure lenses” (choose the ones the source actually supports):

• Evidence-as-control: the artifact becomes “proof” (screenshots, certificates) while signals rot.
• Calendar-as-compliance: the deadline becomes the deliverable; enforcement is “phase two”.
• Exception half-life: “temporary” becomes permanent unless auto-expiry exists.
• Dashboard laundering: green KPIs substitute for risk reduction; drill-down becomes archaeology.
• Soft rollout drift: “enablement” quietly becomes “optional forever”.
• Responsibility diffusion: “we/the team/it was determined” replaces an owner.
• Complexity camouflage: simple fixes are inflated into programs to delay decisions.
• Meeting as mitigation: alignment sessions become the work product.
• Receipt-first skepticism: “Did the source actually say that?” routes to IF.TRACE receipts.

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).
• Includes one editorial aside as a blockquote (standalone line). Rotate these to prevent template fatigue:
  • A: Most dossiers read as if physics is optional: eternal ROI, frictionless execution, boundless optimism. We strip away the gloss to reveal the operational reality.
  • B: Vendors sell capabilities; organizations inherit obligations. We read this document for the handoff moments where the promise turns into work.
  • C: In a market of promises, evidence is the only durable currency. We skip the adjectives and follow claims back to receipts and gates.
  • D: Every control deck assumes perfect execution. We read for the gap between the gate and the bypass.
  • E: Standards describe the happy path; reality is the edge case. We map where this specification hits the friction of existing infrastructure.
  • F: Tooling is cheap; ownership is the tax. We track the owner, the gate, and the expiry.
  • G: The source makes claims. We check whether those claims can be bound to receipts and stop conditions.
• Ends with: OK. Let’s dig.

Selection logic (pick one; do not mention option labels in output):

• Use A for glossy whitepapers, solution briefs, and sales decks with strong ROI/speed language.
• Use B for feature-heavy platform/capability overviews (modules, integrations, matrices, “what you get”).
• Use C for strategy/vision docs where the persuasion payload is mostly adjectives and direction.
• Use D for “controls” docs (policies, guardrails, rollout requirements) where bypass paths are the real story.
• Use E for standards/specifications (NIST/ISO/RFC-style prose).
• Use F when the source emphasizes “enablement”/“adoption”/“ownership” without naming who enforces what.
• Use G as the safe fallback when the source is hybrid/ambiguous.

Week-level dedupe rule (required for week packs):

• Do not reuse the same editorial aside within the previous 5 dossiers (rolling window).
• If the selection rule would repeat an aside, choose the closest-fitting unused option instead (prefer the most receipt-aligned option when in doubt).

Framing rule:

• Prefer a context anchor (“here’s the current state and the incentive pressure”) over a generic time-window. Mention time only when it changes the decision.

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

0ac) Cohesive single-author voice (required)

The dossier must read like it was written by one competent analyst.

Rules:

• Do not present the document as a “multi-writer collage” (no “Voice 1/2”, no “panel says…”, no named personas).
• Do not label internal lenses in user-visible output (no “Punch voice”, “Contrarian Reframe”, “Psychological Insight”, etc.).
• Keep terminology consistent (use the same term for the same thing across the doc: shareId, trace, source_sha256, output_sha256).

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.

0ba) Invisible scaffolding leak guard (fail-fast; required)

The reader must never see internal scaffolding.

Hard rule:

• If any internal scaffolding terminology leaks into user-visible output, do not ship. Rewrite/regenerate until clean.

Examples of banned leak terms (non-exhaustive; adapt as needed):

• E1, E2, E3… / E9
• Punch voice, Boardroom voice, Contrarian Reframe, Psychological Insight
• Stall Stack, Opaque Stack, “scaffolding”, “pipeline”

Note: The code-fence language identifier ```mermaid is allowed. The word “Mermaid” should not appear outside code fences.

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.
• When the source yields fewer than three mirrored sections or the sections are purely marketing blurbs, enforce a degraded path:
  • Emit MIRROR COMPLETENESS: DEGRADED near the header and note the reason.
  • Provide a short Translation Table linking the vendor claims to enforceable gates (see §5c).
  • Skip generating redundant Dave Factor blocks; reference the Annex instead.
  • Do not attempt to patch with filler paragraphs—fail fast and explain why the source cannot sustain a full analysis.

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.

Packaging rules for InfraFabric-added sections only (do not override source layout):

• After a ## / ### heading, do not lead with a table. Add 1–2 lines of context first.
• Tables, diagrams, and code blocks must not touch: always insert a short explanatory sentence between visual blocks.

---

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.

Diagram quality gate (safe subset; required):

• Prefer flowchart LR for process diagrams unless there is a clear reason for TD.
• Keep node IDs simple (A1, step_2). Put punctuation in the quoted label: A1["text, with punctuation"].
• One diagram per code fence.
• Avoid fancy styling unless it clarifies (no gradients; minimal style usage).

---

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 (vertical × industry must shift).

Extended anti-repetition (required):

• Limit The Dave Factor callouts to 1–2 per dossier (one core, one variant) and rotate wording via the motif bank.
• Detect identical paragraph duplication (>2x) and fail the run; require new wording with the same intent.
• For week packs, enforce a rotating closing sentence (roadmap / pin / governance / receipts) so the finale isn't the same copy each day.
• 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 inversion move (use sparingly; do not label it as a “reframe”):

What if the control’s real function is to shift liability, not reduce risk?

Optional one-line psychological closer (use sparingly; keep it grounded in the source):

People route around controls when the bypass is cheaper than compliance.

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 claim entries per dossier; prioritize the most distinctive/measurable claims (retain unique stats).
• Clean up fragmented extractions; if a claim is truncated or contains merged sentences, mark it unusable and skip it rather than editing.
• 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. Optional: insert a short “Boardroom Digest” (3 bullets) after the intro (no tables-first).

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