# Orbit complete-product acceptance

Acceptance is determined from the immutable edition source release and the execution receipts described below.

Orbit is a complete, owner-run CRM for one revenue team: maintain customer
relationships, ingest trustworthy attributed signals, inspect explainable priority,
review a credible next action, and track the real outcome of every approved
customer message. The entire retained [contract](CONTRACT.md) and applicable
[baseline](BASELINE.md) are acceptance obligations. The earlier bounded manual
pilot does not define the product's completion scope.

Completion includes native installation and access, records and workspace
management, source administration and unlinked review, lifecycle and timed queues,
AI previews and validated drafts, human-reviewed immediate and scheduled outreach,
stop rules, delivery and reconciliation, notifications, data export/restore,
privacy, accessibility, failure/recovery, and preserved owner changes across an
ordinary upstream update. The 13 September 2026 owner-authorized COO ruling resolves PUBLIC-002's method:
use a safe experience backed by real workflow-created data, never runtime or browser
mock records. Its safety purpose and all retained obligations remain acceptance
requirements. The dedicated real workflow preview has native deployment and browser receipts; the final release must bind those to its unchanged implementation. The hosted demo
must expose only the maintainer-consented Orbit walkthrough record, prove that
record and its draft were created through the native workflow, and capture a
browser receipt showing read-only loading plus local preview with no write or
adapter requests.
No clause is waived or relabelled by this document.

`pnpm verify` runs the real local runtime suites and writes
`verification/contract-results.json` from actual Node and Playwright completions.
An unmapped, failed, or skipped clause blocks the gate. The report establishes
executed coverage, not that a test label covers every sentence or that a test
provider proves real delivery. Semantic breadth, capacity measurements, native
provider and mailbox outcomes, and the exact candidate's deployment/redeployment
must also be reviewed.

The prior deployed-pilot receipt is historical evidence only. Complete acceptance
requires the immutable candidate export, frozen install, full verification with
no missing applicable clauses, desktop/mobile browser evidence, a real empty
installation and native magic-link session, provider acceptance and observed
mailbox delivery/reply/unsubscribe outcomes, repeat deployment preserving records,
export/restore equivalence, and the recorded owner-intent update exercise.

Report executed gates, any failed or uncovered obligations, and external unknowns
separately. Provider acceptance alone is never mailbox delivery. A published source
tree, a health response, or an injected test session is not product acceptance.