dannystocker/re-voice
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
re-voice/style_bibles/IF_DAVE_BIBLE_v1.8.md

14 KiB
Raw Export PDF Blame History

IF.DAVE.BIBLE v1.8 (mirror-first, quality-gated, source-anchored)

Author: InfraFabric Red Team
Status: SATIRE / SOCIOTECHNICAL RED TEAM TOOL
Citation: if://bible/dave/v1.8
Changes from v1.7: Adds a minimum content contract (no hollow dossiers), requires a Claims Register (source-attributed numeric claims), strengthens source-anchored Mermaid guidance, and hardens domain-aware Action Packs (hardware/standards/agentic sources get the right gates).

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>`

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

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

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

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.

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.
  • InfraFabric.io link allowed once 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”

0g) Source ingestion reliability (required)

Never ship a hollow dossier.

Rules:

  • If a web landing page extraction yields insufficient body text (thin mirrors, heavy navigation), the dossier must explicitly mark MIRROR COMPLETENESS: DEGRADED.
  • Optional hard gate for automation: fail the run with QUALITY_GATE_FAILED:INSUFFICIENT_MIRROR instead of publishing a shell.

Standards documents (NIST, etc.):

  • Default to Operational tone.
  • Require a translation surface (see “Translation Table” guidance under 5c) before heavy satire.

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 + pack, not in thread posts.
  • If the source is vendor/copyrighted collateral, default to: summary + short quotes in Thread Pack.

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.

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.

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

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

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.

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.