# The Gateway Operator Runbooks Program

## Purpose

The Gateway should maintain operator runbooks for assistant-guided privacy infrastructure work.

The product controls sensitive network behavior. Users will need repeatable, reviewable procedures for install, privacy audit, identity separation review, troubleshooting, policy changes, and recovery. Runbooks package those procedures so assistants can help operators without each user inventing workflows from scratch.

## Positioning

Operator runbooks are not a replacement for documentation. They are procedural guidance for assistants and operators:

- Read the local environment.
- Inspect configuration.
- Explain risk before changing network behavior.
- Verify privacy posture and leak assumptions before claims are trusted.
- Make scoped edits.
- Run validation commands.
- Produce recovery notes.

This reinforces the product story: The Gateway gives users control over traffic and privacy posture, and runbooks give operators reliable help managing that control.

## Runbook Packs

Additional runbooks should cover the operational cases that create the most risk:

- Route ownership migration.
- DNS outage and resolver leak response.
- Policy change approval.
- Upgrade and rollback.
- Privacy incident and leak report.
- Support snapshot redaction.
- Node compromise and key rotation.
- Managed service onboarding and offboarding.

### Install and Provision

Goal:

- Help operators install The Gateway, select deployment mode, configure basic routing/DNS, and validate health.

Includes:

- Environment discovery.
- Preflight checks.
- Install steps.
- First policy setup.
- Local validation.
- Rollback notes.

### Privacy Audit

Goal:

- Help operators understand where traffic goes, which identity context applies, and which policies affect outbound behavior.

Includes:

- DNS policy review.
- Route and bridge path review.
- Identity separation review.
- Leak check and fallback review.
- External dependency list.
- Local-only vs managed service boundary check.
- Human-readable audit report.

### Traffic Recovery

Goal:

- Help recover from broken routing, DNS failure, bridge outage, or bad policy changes.

Includes:

- Safe-mode checklist.
- DNS restore path.
- Route rollback path.
- Connectivity diagnostics.
- Out-of-band recovery through local console, temporary management SSID/LAN port, or SSH safe mode.
- Known-good config slot, factory reset path, backup import/export, and emergency DHCP/DNS restore.
- Locked-out procedure: regain admin access, disable policy apply, restore last good route/DNS/firewall.
- Post-incident notes.

### MSP Operations

Goal:

- Help consultants and MSPs repeat deployments without losing consistency.

Includes:

- Site intake checklist.
- Client topology template.
- Change log format.
- Support handoff.
- Monthly review checklist.

### Bridge and Mesh

Goal:

- Help operators create and validate bridge paths between local network, VPS nodes, relay nodes, and remote clients.

Includes:

- Topology discovery.
- Peer inventory.
- Latency and fallback checks.
- Failure-mode test plan.
- Policy notes.

### Policy Templates

Goal:

- Provide reusable traffic, DNS, privacy, and fallback policies for common scenarios.

Includes:

- Home lab template.
- Small office template.
- Privacy-focused workstation template.
- Travel laptop template.
- MSP managed site template.

## Repository Structure

Create a dedicated public docs area when ready:

```text
operator-runbooks/
  README.md
  runbooks/
    install-and-provision.md
    privacy-audit.md
    traffic-recovery.md
    msp-operations.md
    bridge-and-mesh.md
    policy-templates.md
  examples/
    home-lab.md
    small-office.md
    msp-site.md
  tests/
    fixtures/
```

Each runbook should include:

- Trigger conditions.
- Required context.
- Safe commands.
- Commands requiring explicit user approval.
- Validation steps.
- Rollback steps.
- Output format.

## Safety Rules

Operator runbooks must be conservative because network changes can lock users out.

Rules:

- Never silently change live routing, DNS, firewall, credentials, or remote access.
- Always inspect current state before edits.
- Always produce a rollback path before risky changes.
- Prefer dry-run and validation commands first.
- Ask for explicit confirmation before destructive or connectivity-breaking operations.
- Do not collect or print secrets.
- Redact tokens, keys, IPs, and private hostnames when producing shareable reports.

## Launch Plan

### Phase 1: Specs

- Draft the six runbook specs as plain Markdown.
- Align each runbook with website functions and product docs.
- Add safety rules and output formats.
- Publish the runbook program on the website as planned operator procedures.

### Phase 2: Prototype

- Build `install-and-provision` first. Prototype path: `docs/runbooks/install-and-provision.md`.
- Test it against one local dev environment and one fresh operator environment.
- Add validation checklist and known failure modes.
- Publish a short demo.

### Phase 3: Docs Launch

- Create public `operator-runbooks` docs.
- Link from the website when the docs are ready.
- Ask early operators to run the install and privacy audit runbooks.

### Phase 4: Monetization Tie-In

- Keep baseline runbooks open.
- Offer paid support for guided runs, custom policy packs, MSP templates, and incident recovery.
- Bundle appliance builds with the install/provision runbook.
- Use sponsor funding to prioritize new runbooks.

## Public Readiness Targets

- Published runbook repository or docs section.
- Draft runbook set covering install, privacy audit, recovery, bridge setup, policy changes, and MSP handoff.
- Working install/provision prototype.
- Redacted example report format.
- Known failure modes documented.
- Route, DNS, fallback, recovery, and privacy posture checks included.

## Validation Targets

- Runbooks validated with technical users.
- Evidence from fresh-machine install and recovery drills.
- Redaction guidance tested against example support bundles.
- MSP/consultant template needs documented without publishing private customer topology.

## Done Criteria

- Website explains operator runbooks in product language.
- Public docs have at least one usable runbook.
- Safety rules are documented.
- Runbooks connect directly to launch and monetization: install help, audit reports, recovery, paid support, appliance setup, and MSP operations.