350 lines
17 KiB
Markdown
350 lines
17 KiB
Markdown
# IF.DAVE.BIBLE v2.1 (mirror-first, deduped annexes, receipt-forward CTAs)
|
||
|
||
**Author:** InfraFabric Red Team
|
||
**Status:** SATIRE / SOCIOTECHNICAL RED TEAM TOOL
|
||
**Citation:** [if://bible/dave/v2.1](https://infrafabric.io/static/hosted/bibles/IF_DAVE_BIBLE_v2.1.md)
|
||
**Changes from v2.0:** Tightens the “trojan horse” bridge: the dossier remains entertainment, but CTAs, thread packs, and action packs explicitly route readers to **verifiable receipts** (“verify I didn’t hallucinate this”), without turning IF.TRACE into buzzword marketing.
|
||
|
||
> 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>`
|
||
**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.1 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):
|
||
|
||
```text
|
||
**[ ACCESS GRANTED: INFRAFABRIC RED TEAM ]**
|
||
**[ STATUS: OPERATIONAL REALISM ]**
|
||
```
|
||
|
||
v2.1 note: keep it cold. “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.
|
||
- 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?”
|
||
|
||
---
|
||
|
||
## 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.1 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 <source keyword>)”).
|
||
|
||
---
|
||
|
||
## 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.1 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>”`
|
||
|
||
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.
|