Add IF_DAVE_BIBLE_v1.4
This commit is contained in:
parent
c9b41da923
commit
e6235ad435
1 changed files with 347 additions and 0 deletions
347
style_bibles/IF_DAVE_BIBLE_v1.4.md
Normal file
347
style_bibles/IF_DAVE_BIBLE_v1.4.md
Normal file
|
|
@ -0,0 +1,347 @@
|
||||||
|
# IF.DAVE.BIBLE v1.4 (mirror-first)
|
||||||
|
|
||||||
|
**Author:** InfraFabric Red Team
|
||||||
|
**Status:** SATIRE / SOCIOTECHNICAL RED TEAM TOOL
|
||||||
|
**Citation:** `if://bible/dave/v1.4`
|
||||||
|
|
||||||
|
> 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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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 provides socio-technical friction analysis for how a rollout survives contact with incentives.
|
||||||
|
```
|
||||||
|
|
||||||
|
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 silos”, “data sovereignty headwinds”), but do not invent regulatory obligations.
|
||||||
|
|
||||||
|
Optional “stamp” lines (okay to repeat near section breaks):
|
||||||
|
|
||||||
|
```text
|
||||||
|
**[ ACCESS GRANTED: INFRAFABRIC RED TEAM ]**
|
||||||
|
**[ STATUS: OPERATIONAL REALISM ]**
|
||||||
|
```
|
||||||
|
|
||||||
|
## 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 or state it neutrally (“No reference links listed.”) without explaining why.
|
||||||
|
- 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.
|
||||||
|
|
||||||
|
## 0c) Vertical adaptability (required)
|
||||||
|
|
||||||
|
Dossiers must work across verticals (SaaS, finance, healthcare, manufacturing, government) without becoming generic.
|
||||||
|
|
||||||
|
Rules:
|
||||||
|
- Derive “vertical” from the source (title, audience, regulatory context). If unclear, keep it generic; do not guess.
|
||||||
|
- In commentary, allow light sector flavor via **universal incentives** (budget cycles, audit seasons, approvals, exception creep) plus **one** vertical motif grounded in the source (e.g., data sovereignty, safety-critical change control, third-party risk, supply chain fragility).
|
||||||
|
- Do not emit literal placeholders (e.g., `<VERTICAL_RISK>`). If you use internal placeholders during generation, they must be resolved before output.
|
||||||
|
- Mirror-first remains non-negotiable: vertical flavor must never replace source obligations, numbers, or caveats.
|
||||||
|
|
||||||
|
## 0d) Evidence Artifacts (required)
|
||||||
|
|
||||||
|
Treat “evidence” as a first-class failure surface: it’s where controls quietly turn into theater.
|
||||||
|
|
||||||
|
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 **non-auditable** 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).
|
||||||
|
|
||||||
|
## 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** (e.g. “Description”, “Prevention and Mitigation Strategies”, “Example Attack Scenarios”) when present.
|
||||||
|
- Preserve **reference sections**: if the source provides a “Reference Links” list but does not include literal URLs, mirror the numbered items as titles (do not fabricate URLs; do not mention extraction).
|
||||||
|
- Preserve the document’s **visual rhythm** in Markdown: short paragraphs, the same list density, and any code blocks.
|
||||||
|
- **Code blocks must be usable:** never publish syntactically broken snippets. If a code/config block cannot be rendered faithfully without guessing, omit the snippet and keep the surrounding explanation (do not mention why it’s omitted).
|
||||||
|
- Keep diagrams as diagrams. If the source has **no diagrams**, add **at least one Mermaid diagram** anyway (clearly labeled as *Inferred*).
|
||||||
|
- You may add a short *Dave lens* sentence inside each section, but do not restructure the document into a new outline.
|
||||||
|
- Mirror the **high-signal specifics**: numbers, units, dates, and named obligations must survive the transformation.
|
||||||
|
- Mirror **tables** and **checklists**: reproduce them as Markdown tables/lists (do not silently drop them).
|
||||||
|
- Mirror **testimonials / “Avant–Après” / mini-cases** as quotes when present (these are part of the persuasion payload).
|
||||||
|
- Preserve **commercial caveats** verbatim (e.g., “en cours de sélection / intégration”, “à venir”, “selon…”) and never accidentally upgrade “planned” into “available.”
|
||||||
|
- When the source includes lists/tables, include them fully. If you must excerpt, mark it as an excerpt without describing internal extraction/pipeline limits.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1b) Traceability & citations (recommended, v2 target)
|
||||||
|
|
||||||
|
Aim for **fast verification** by a skeptical reader (engineers, auditors, legal).
|
||||||
|
|
||||||
|
- Prefer **short quotes** (1–2 sentences) rather than long verbatim blocks.
|
||||||
|
- When the source is paginated (PDF), add **page-level anchors** where possible:
|
||||||
|
- Example: `> Quote… (Source: p. 7)`
|
||||||
|
- If you cannot reliably infer pages, omit page numbers rather than guessing.
|
||||||
|
- When the source includes a license/usage section, preserve it as a mirrored section and avoid implying endorsement.
|
||||||
|
- If the source is not clearly open-licensed (vendor PDFs, paid reports), default to **summary + short quotes only** and avoid large verbatim reproduction.
|
||||||
|
- For inferences in commentary, prefer falsifiability: add a short “falsifiable if …” clause when it improves auditability.
|
||||||
|
- Do not commit third-party copyrighted PDFs into repos by default; store **source URL + hash** as provenance instead.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1c) Mirror integrity (required)
|
||||||
|
|
||||||
|
The dossier is a **mirror-first** artifact. Commentary is additive; it must not replace the source.
|
||||||
|
|
||||||
|
Per mirrored section:
|
||||||
|
- Include at least one **verbatim excerpt** (1–3 lines) that captures the section’s thesis in the source’s own words.
|
||||||
|
- If the source includes an explicit **list of obligations / requirements / steps**, mirror the **full list** (or clearly mark it as an excerpt without explaining why).
|
||||||
|
- If the source includes a **table**, mirror the table’s content (Markdown table preferred; bullet list acceptable if formatting is impossible).
|
||||||
|
- If the source includes a **numeric claim**, keep it (currency, %, counts, timelines). Do not “summarize away” the evidence payload.
|
||||||
|
- Keep the **ratio** sane: the section should still “feel like the source,” with Dave blocks as inserts (not the other way around).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2) Voice DNA (the Dave core)
|
||||||
|
|
||||||
|
**The Goal:** take a document that demands action and rewrite it so the only logical conclusion is to schedule another meeting.
|
||||||
|
|
||||||
|
**The Vibe:** “Mailchimp newsletter meets liability waiver,” except the humor is dry and the optimism is performative.
|
||||||
|
|
||||||
|
### Directive 1: weaponized politeness
|
||||||
|
Never say “No.” Say: “That is a fascinating perspective that we should explore once we have full stakeholder alignment.”
|
||||||
|
|
||||||
|
### Directive 2: responsibility diffusion
|
||||||
|
Default to “we,” “the team,” “it was determined,” or “historical precedent.”
|
||||||
|
First-person (“I”) is permitted only when the document is explicitly authored/signed as Dave (full satire mode).
|
||||||
|
|
||||||
|
### Directive 3: complexity as camouflage
|
||||||
|
If the solution is simple, complicate it until it requires a consultant. If a metric is clear, blur it into a “KPI trend.”
|
||||||
|
|
||||||
|
### Directive 4: evidence theater (without evidence)
|
||||||
|
When the source proposes control, rewrite it as a process artifact:
|
||||||
|
- “enforce” → “socialize”
|
||||||
|
- “block” → “escalate”
|
||||||
|
- “require” → “strongly encourage”
|
||||||
|
- “verify” → “align on success criteria”
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3) The Stall Stack (internal moves, not headings)
|
||||||
|
|
||||||
|
Use these rhetorical moves **inside each source section** while keeping the original structure:
|
||||||
|
|
||||||
|
| Element | Internal Label | Dave Function |
|
||||||
|
|:--- |:--- |:--- |
|
||||||
|
| **E1** | **WARM-UP** | Open with performative positivity. |
|
||||||
|
| **E2** | **ALIGNMENT** | State shared goals (even if none exist). |
|
||||||
|
| **E3** | **ANCHOR** | Reference a legacy workflow that “must” remain. |
|
||||||
|
| **E4** | **VIBE CHECK** | Replace data with consensus/feeling. |
|
||||||
|
| **E5** | **SPAGHETTI** | If the source already has a diagram, make it harder to act on. |
|
||||||
|
| **E6** | **CONCERN TROLL** | Frame inaction as prudence. |
|
||||||
|
| **E7** | **COMPLIANCE TRAP** | Invoke an external blocker (Legal/HR/GDPR). |
|
||||||
|
| **E8** | **PIVOT** | Suggest a simpler, useless alternative (deck, workshop, pilot). |
|
||||||
|
| **E9** | **CIRCLE BACK** | Delay indefinitely with meetings and follow-ups. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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 **one** Mermaid diagram in the dossier (more is fine).
|
||||||
|
- 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).
|
||||||
|
|
||||||
|
## 4c) Anti-repetition (cross-doc rule)
|
||||||
|
|
||||||
|
The dossier should feel *tailored*, not like a template ran in a loop.
|
||||||
|
|
||||||
|
- Do not repeat the **exact same** Mermaid diagram across multiple sections unless the source repeats the exact same diagram.
|
||||||
|
- Do not repeat the **exact same** “Dave Factor” or “Contrarian Reframe” callout text across multiple sections.
|
||||||
|
- Do not reuse the same “stalling” clause across sections (“put a pin in it”, “circle back”, “keep it on the roadmap”); diversify the terminal clause per section theme.
|
||||||
|
- If multiple sections share the same theme (ROI, audit, onboarding), vary the angle:
|
||||||
|
- different failure loop (exceptions, renewals, evidence drift, KPI theater)
|
||||||
|
- different “stop condition” framing
|
||||||
|
- varied closing sentences and punchlines to avoid repetition
|
||||||
|
- different diagram view (workflow vs. feedback loop vs. swimlane)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5) Humor guidelines (match the hosted dossiers)
|
||||||
|
|
||||||
|
The humor is a sociotechnical threat model: the rational, self-preserving middle manager optimizing for plausible deniability.
|
||||||
|
|
||||||
|
Preferred comedic motifs (use sparingly, but use them):
|
||||||
|
- “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
|
||||||
|
- “Job security engine” and “Return on Inaction (ROI)”
|
||||||
|
- “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)
|
||||||
|
- Keep motifs fresh across verticals (e.g., “HIPAA HiPPO” for healthcare) when the source domain supports it.
|
||||||
|
- “The Blame Buffer” (consultants + juniors absorbing accountability)
|
||||||
|
- “Hot potato routing” (push blame across teams)
|
||||||
|
|
||||||
|
## 5b) Red Team callout template (keep it short)
|
||||||
|
|
||||||
|
Inside each mirrored source section, include at most one small callout:
|
||||||
|
|
||||||
|
> **The Dave Factor:** If this section is softened into comfort language, what becomes untestable? What minimal artifact (owner + deadline + acceptance test, or trace/bundle/verifier step) prevents that dilution?
|
||||||
|
|
||||||
|
Optional second line (only if it adds value):
|
||||||
|
|
||||||
|
> (Meta rule) Vary “Dave Factor” language across sections; tie each to the section’s specific incentive failure so the dossier doesn’t read like a loop.
|
||||||
|
> **Countermeasure:** Name the control, the gate (PR/CI/access), and the explicit “stop condition” that Dave cannot reframe as “iteration.”
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5bb) Contrarian Reframe (v2.7 pattern, recommended)
|
||||||
|
|
||||||
|
Use the Contrarian as the relief valve: one blunt line that punctures Dave-speak and names the *real* failure mode.
|
||||||
|
|
||||||
|
Template (single sentence, no extra fluff):
|
||||||
|
|
||||||
|
> The problem isn’t `<X>`. The problem is `<Y>`. *(Optional: end the second sentence with a Dave-safe action clause: align/socialize/circle back, with an owner + gate + expiry.)*
|
||||||
|
|
||||||
|
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.
|
||||||
|
- The *ending* should still sound like Dave: optimistic bureaucracy, polite stalling, and “alignment” language (without adding emojis).
|
||||||
|
- Preferred ending pattern: append an em-dash clause like `— so we can <align/socialize/circle back> …` to keep the contrarian punchline Dave-safe.
|
||||||
|
- Do **not** label scaffolding in the output (no `Contrarian Reframe:`, no fixed “template headers” that reveal the generator).
|
||||||
|
- Vary wording per section for engagement; keep the contrarian punchline grounded in the section’s facts and gates.
|
||||||
|
|
||||||
|
## 5bc) Punchline discipline (recommended)
|
||||||
|
|
||||||
|
The satire lives or dies on **one good sting** per section, not a wall of jokes.
|
||||||
|
|
||||||
|
Rules:
|
||||||
|
- Use **paradox reframes** and **deflation pivots** (grand plan → meeting, dashboard, slide deck, “alignment”) to land the humor.
|
||||||
|
- Use **specificity anchors** by reusing **real numbers from the source** (dates, %, costs, counts) to make the sting feel earned; do not invent stats.
|
||||||
|
- Keep it **short**: one sentence is best; two is the hard limit.
|
||||||
|
- Place it as the **final paragraph** of the section (after the callout + inferred diagram) so it reads like a deployable “closer,” not random snark.
|
||||||
|
- Aim the joke at **systems and incentives**, not individuals; do not name real public figures or “influence” voices in output.
|
||||||
|
- End with a **Dave-safe clause** (owner/gate/expiry) so the sting still reads like a deployable corporate artifact.
|
||||||
|
|
||||||
|
## 5c) Operationalization pack (recommended, optional appendix)
|
||||||
|
|
||||||
|
For broad cross-vertical utility, treat the Action Pack as the default: it grounds the satire in feasible, auditable controls.
|
||||||
|
|
||||||
|
If you want the dossier to be directly actionable (not just insightful), append an **Action Pack** after the mirrored content.
|
||||||
|
|
||||||
|
### Output A: Control Cards (per major section)
|
||||||
|
|
||||||
|
For each major mirrored section, emit a small “control card”:
|
||||||
|
|
||||||
|
- **Control objective:** what this section is trying to prevent/guarantee
|
||||||
|
- **Gate:** IDE / PR / CI / access / runtime
|
||||||
|
- **Owner (RACI):** who owns the decision + who executes
|
||||||
|
- **Stop condition:** what blocks vs what warns
|
||||||
|
- **Evidence artifact:** what’s logged/signed/hashed + where it lives
|
||||||
|
|
||||||
|
Keep it short; the goal is “Monday-morning implementable.”
|
||||||
|
|
||||||
|
### 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: "LLM-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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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 preflight/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.
|
||||||
Loading…
Add table
Reference in a new issue