# The Gateway Support Boundaries

Paid support should sell operational help without taking ownership of the operator's traffic or credentials.

## Support can include

- Guided install and upgrade help.
- Recovery review after DNS, route, firewall, or bridge failures.
- Privacy posture review based on operator-provided evidence.
- Policy design guidance for devices, groups, routes, DNS, fallback, and bridge paths.
- Review of customer-generated, redacted support bundles.
- MSP onboarding guidance, templates, and handoff review.

## Support should not include

- A guarantee of anonymity.
- Endpoint cleanup, browser fingerprinting fixes, legal advice, or payment-trail cleanup.
- Silent changes to live routing, DNS, firewall, credentials, or remote access.
- Traffic inspection as a default support requirement.
- Permanent unattended remote access.

## Access and evidence rules

- Operators keep credentials, traffic paths, and final approvals.
- Operators keep ownership of route policy, DNS policy, fallback behavior, and rollback decisions unless they explicitly delegate a bounded change window.
- Remote access, if used, must be explicit, time-limited, revocable, and logged.
- Support bundles should be generated by the operator, redacted before export, scoped to diagnostics, and retained only as long as needed.
- Sensitive reports should separate assumptions, observed behavior, remaining risks, and recommended next actions.
- Cross-check the launch status page before a live support window starts.

## Change window rules

- Name the current route owner, DNS owner, fallback owner, and final policy approver before support starts.
- Distinguish advisory review from a bounded live change window.
- If a live change window is delegated, record the exact routes, DNS settings, fallback rules, credentials, and remote-access scope that support may touch.
- Set a clear end condition for delegated access: rollback complete, validation passed, or the operator closes the window.
- Confirm console, SSH, or local recovery access before route, DNS, firewall, or remote access changes.
- Keep a known-good rollback target for policy, resolver, and transport state.
- Stop the change window if recovery access or rollback evidence is missing.
- Return full ownership to the operator at the end of the window and summarize what changed, what did not, and what still needs operator approval.
- Share only the route, DNS, fallback, privacy posture, and failure evidence needed for the request.
- State remaining uncertainty when behavior cannot be verified directly from operator-provided evidence.

## Ownership matrix

- Route owner: approves route intent, route changes, and the final apply window for path changes.
- DNS owner: approves resolver policy, upstream DNS changes, split-DNS behavior, and DNS rollback.
- Fallback owner: approves when fallback is disabled, degraded, or allowed and what event triggers each mode.
- Rollback owner: approves back-out conditions, the known-good target, and the point where support stops changing state.
- Support owner: stays inside the scoped request, records what was touched, and hands control back at close-out.

## Close-out checklist

- State what changed and what stayed under operator ownership.
- Record final route, DNS, fallback, and privacy posture outcomes or remaining uncertainty.
- Confirm delegated access is revoked or expired.
- Leave the operator with the rollback point, evidence notes, and any follow-up approvals still required.

## Intake fields

- Deployment mode and hardware.
- Current topology and upstream constraints.
- Current route owner, DNS owner, and fallback owner.
- Desired privacy posture.
- Active DNS and route policy.
- Rollback path and recovery access available before any live change.
- Failure symptoms or support goal.
- What can be shared in a redacted bundle.
- Whether remote access is allowed for this request.