Brainforge Knowledge

ooo-coverage-handoff-spec

4 min read

OOO coverage handoff — standard spec

Status: Draft — living practice doc for Brainforge team members
Last updated: 2026-05-08

Purpose

Give anyone stepping in as coverage owner enough context to monitor health, answer predictable questions, and escalate without needing deep code review or architecture ownership—unless you explicitly assign that scope.

When to use this spec

Use a written handoff when any of the following is true:

  • You will be unreachable or mostly offline for more than one business day (PTO, sick leave, travel).
  • You are the primary owner of a fragile surface (integrations, workers, cron, governance approvals, vendor dashboards) and absence would otherwise silence alerts or block decisions.
  • Client or internal stakeholders habitually route questions to you alone for that area.

Routine same-day absence with Slack availability usually does not require a vault doc—Calendar + Slack status + a channel note can be enough.

Principles

  1. Coverage is stewardship, not heroics. The coverage owner runs checks, routes questions, and escalates. They do not silently expand scope into implementation unless pre-agreed.
  2. One named coverage owner + one named escalation backup. Avoid “ask the channel” as the only path for emergencies.
  3. Time-box daily checks (for example 10–20 minutes) so coverage stays realistic alongside other work.
  4. No secrets in the vault. Reference 1Password item names or vault paths—not passwords, API keys, or session tokens. Follow .cursor/rules/no-secrets-in-repo.mdc.
  5. Reusable structure. Keep client-specific URLs and queries in the instance handoff; keep universal guidance in this spec.

Where to save the instance handoff

Default path (create folders if missing):

knowledge/clients/{client}/coverage-handoffs/{person-or-topic}-ooo-YYYY-MM-DD.md

Examples:

  • knowledge/clients/eden/coverage-handoffs/zoran-ooo-2026-05-11.md
  • knowledge/clients/{client}/coverage-handoffs/data-pipeline-ooo-2026-06-02.md

For internal-only surfaces that are not tied to one client, use a team folder under knowledge/engineering/ or knowledge/ops/ and link from the relevant project README—pick one convention per initiative and stay consistent.

Instance handoff — required sections

Copy the block below into each new handoff and delete unused bullets.

1. Header

  • Out: Dates and timezone if ambiguous
  • Coverage owner: Single name (Slack handle optional)
  • Escalation: Backup name + when to use them
  • Optional: Super-emergency path (for example phone) — only if the person going OOO explicitly agrees

2. Quick context (3–6 sentences)

What system or responsibility you own, why it matters, and what “good” looks like during the absence.

3. Daily (or weekly) checklist

Concrete, bounded steps:

  • Data / pipelines: Which warehouse or project; example freshness queries or where schedules live; what “stale” means (thresholds).
  • Product / site: URLs or flows to smoke-test; what failure looks like.
  • Vendor dashboards: Which product area (analytics, DNS, workers, etc.); what tab or signal to glance at.

Each step should list approximate time so the coverage owner can plan.

4. Predictable questions / scripts

Short if asked → respond with guidance (for example “review waits until I’m back unless escalation agrees”).

5. Escalation table

Symptom or triggerAction
…Ping escalation backup
…Client-facing comms only after backup agrees

Keep rows concrete—avoid generic “something seems wrong.”

6. Access

How to reach dashboards or consoles without embedding secrets:

  • 1Password: vault name + item title (or pointer to existing setup doc)
  • Slack: internal + client-facing channels
  • Links: dashboards, Linear projects, runbooks—non-secret URLs only

7. Acknowledgments (fill before OOO starts)

  • Coverage owner read the doc and agrees to the time-boxed checks
  • Escalation backup confirmed availability for the window
  • Optional: CSO or service lead aware if client-visible risk exists

Before you go OOO — originator checklist

  • Instance handoff file exists under the path above and is linked from Slack or the client folder README if helpful
  • Calendar reflects OOO; Slack status set
  • Linear / Ops norms satisfied (for example sick/OOO request issues when your team requires them)
  • No undocumented solo credentials needed for coverage—backup can access systems via normal governance

After you return

  • Brief the coverage owner on anything that fired
  • Update this instance doc with lessons (thresholds, missing links) or archive it if one-off

Reference instance

  • Eden Cloudflare worker governance handoff: knowledge/clients/eden/coverage-handoffs/zoran-ooo-2026-05-11.md

Graph View