TRUST

The boundary is part of the product.

Launch surfaces should make the important line readable early: what stays yours, what the service can prepare, and what needs explicit approval before it moves.

What stays yours

Domains, email accounts, payment providers, store accounts, source files, and customer data stay under user or workspace ownership.

What the service can help with

The workflow can prepare drafts, explain required steps, organize evidence, preview changes, and guide the next safe action.

What needs approval first

External writes, account-linked actions, publishing, billing-affecting steps, raw access exceptions, and high-impact changes require explicit confirmation.

CONNECTION LIFECYCLE

External actions move through explanation, verification, preview, approval, record, and revoke.

1

Explain

Show what will be connected, changed, sent, published, or charged before the action moves forward.

2

Verify

Confirm ownership or authority without locking one exact launch method such as DNS, OAuth, or email as the only path.

3

Preview

Present the user-facing summary or draft first, especially before external writes and live changes.

4

Approve

Proceed only after the user confirms the specific action, account, and scope.

5

Record

Keep an audit trail for approval, raw-open exceptions, expensive steps, and external-action preflight decisions.

6

Revoke

Make the boundary understandable when access, approval, or a queued action needs to be removed or stopped.

SAFETY

The safety baseline does not move with plan upgrades

  • Every plan shares the same safety baseline.
  • Higher plans add depth, task scope, and priority. They do not loosen guardrails.
  • Input checks, packet compile, execution gates, output review, and revision re-entry all carry safety boundaries.

DATA

Public proof is curated, not raw customer exposure

  • Private customer data, sensitive values, and raw internal traces are not treated as public proof.
  • Files and references go through preview-first handling instead of raw-open by default.
  • Examples exist to prove direction and help onboarding, not to leak customer work.

Other launch boundaries

  • All plans keep the same safety baseline.
  • Mobile means mobile-usable web first; native store delivery is a separate scope.
  • Design-sensitive work should ask for one early direction check, then move detail changes into the result revision loop.
  • Usage is described publicly as usage, remaining usage, additional usage, or estimated usage rather than raw internal metering math.