# The Gateway Public Launch Readiness

The Gateway should launch publicly only when the open-source story, install path, trust boundaries, and evidence are aligned.

The project is pre-launch. This document is intentionally public-safe: it describes release gates and operator evidence, not private channel plans, internal targets, or unreleased commitments.

## Public Goal

Publish The Gateway as an open-source, local-first privacy overlay for operators who want inspectable control over:

- Route ownership.
- DNS ownership.
- Identity separation.
- Fallback behavior.
- Bridge and relay paths.
- Recovery procedures.
- Privacy posture verification.
- Assistant-guided operator runbooks.

The Gateway should be presented as an inspectable control layer, not as a one-click anonymity product or a generic VPN replacement.

## Public Positioning

Primary message:

> Build a private overlay over the internet.

Supporting narrative:

- The public internet is mediated by opaque platforms, ISP behavior, app telemetry, cloud defaults, and fragile local networks.
- The Gateway gives operators an explicit model for where traffic goes, what resolves, what fails over, which identity context applies, and what evidence proves the state.
- The open-source core creates trust because traffic-control infrastructure should be inspectable.
- Paid operations fund reliability, documentation, support, appliances, and long-term stewardship.

## Claims To Keep Bounded

- Do not promise anonymity by default.
- Do not imply The Gateway can make logged-in accounts, payments, endpoint compromise, or browser fingerprints private.
- Do not imply support needs credential custody or default traffic inspection.
- Do not present unsupported hardware, install paths, or bridge behavior as complete.
- Do not frame the project as only a VPN/router.

## Public Launch Gates

Before broad public promotion:

- License selected and committed.
- Public repository published with README, security policy, contribution guide, support policy, and issue templates.
- Fresh-machine install path tested and documented.
- Rollback and recovery path documented.
- Supported hardware matrix published.
- Public evidence checklist populated with screenshots, demo, install transcript, test summary, and recovery drill.
- Support intake and redaction rules published.
- Security reporting path tested.
- Sponsor/support/appliance/MSP paths point to real contact endpoints.

## Public Assets

- Product website.
- Public repository.
- Install readiness page.
- Trust and security boundaries page.
- Support boundaries page.
- Support intake page.
- Sponsor path.
- Appliance waitlist.
- MSP pilot intake.
- Evidence checklist.
- First operator runbook.

## Soft Launch Criteria

A limited technical preview is appropriate when:

- A technical operator can understand the install path without a private call.
- The project clearly says what is experimental.
- Support scope is bounded.
- Logs and support bundles have redaction guidance.
- Issues and PRs have templates that prevent accidental publication of secrets, private topology, or traffic captures.
- Privacy posture claims are tied to concrete route, DNS, fallback, and leak checks.

## Public Launch Criteria

Broad public launch is appropriate when:

- The install path works on at least one documented fresh-machine environment.
- Recovery has been tested.
- Public docs explain common failure cases.
- Evidence artifacts are available.
- Security and support contact paths work.
- A maintainer can triage issues without relying on private context.

## Definition Of Done

- The website clearly explains what The Gateway is, who it is for, what it controls, and how it is funded.
- Public docs let a technical user evaluate and attempt the install path.
- Donation, sponsor, support, appliance, and MSP paths are visible without overpromising.
- Operator runbooks show how sensitive changes are reviewed before they are applied.
- Privacy and anonymity limitations are explicit.