# Orbit authoritative edition — 14 September 2026

## Shared refactor — 14 September 2026

The edition now selects shared SendGrid transport from Base while retaining its own durable send policy. Accepted responses may lack a remote receipt; uncertain outcomes remain distinct and are not automatically repeated. Authoring1.1 includes changed-input diagnostics, retained baseline extraction, mapped comparison and portable adjacent release receipts verified against a clean clone. Source integrity does not establish product or deployment acceptance; the remaining obligations below are preserved.


Read CONTRACT.md, BASELINE.md and ACCEPTANCE.md together. This repository owns its effective source and composition, including its selected Sales core and Base components. Maintainers and forks edit and release this same source; ordinary Git updates must preserve recorded owner intent.

## Source authority conversion

The current source was materialized from completed Sales `4b7a3a6c4ecdbb27742d565dfd96e0704175f23b` and Base `603ee025aa5991fb44e0c3b0731f2113be85ceab`, preserving the product Git history from `c65a2054227426c980bb7ec7ed2a1a94c9366b4f`. The protected 199 runtime, migration, requirements, dependency-lock and operating-description files are byte-identical to that completed export. `provenance/source-custody-20260914.json` records all 351 imported files including the historical composition lock.

`edition.json` and `sources.lock.json` now select authoritative local source and retained immutable comparison origins. `scripts/edition-authoring/` travels in the product; maintainers and community forks use its same source check, materialization, promotion and local release commands. See AUTHORING.md. The Sales cutover removes Orbit's generated target and former source; Ferry remains separately owned during its conversion. `composition.lock.json` is an import receipt only.

Current hosted receipt scripts require a clean source check before external work and stamp the edition commit. This identifies local candidate source; independent deployed-version and provider evidence remains necessary. Historical verification is retained in `provenance/imported-verification/` and the dated sections below, and does not automatically accept this converted source. No deployment or provider work was performed for this conversion.

## Conversion verification

The unchanged product passed full `pnpm verify`: 100 core, 10 component, 14 deployment, 26 browser and one archive-browser test, emitted Worker checks and the full declared-capacity archive/restore/erasure run. All 86 executed clauses passed; that is local execution coverage, not fresh external acceptance. The final source-preflight changes passed two focused regressions after the tool refresh. Search p95 stayed below 16ms in this local run; the 6,150,005-row archive restored in about 94 seconds and contact erasure completed in about 9.4 seconds. See `verification/authoring-20260914/result.json` and preserved full output. Operations describe passed; input check accurately reports missing private deployment configuration and provider inputs.

## Implemented product

Native emailed magic links protect the operator application. The Worker serves TanStack Start documents and authenticated Hono APIs, rejects framing, validates origins and uses durable public rate limits. Owner bootstrap creates an operator, workspace and pipeline without sample customer records.

The interface provides the NOW queue, opportunity evidence and recommendations, complete company/contact records and aliases, custom fields, imports, merges, erasure, lifecycle/stage/assignment changes and workspace/operator settings. Signed source ingestion records immutable attribution and diagnostics; ambiguous identities remain held for explicit review. Evaluations are transactional, completed actions do not repeat identical evidence, and failed evaluations remain visible beside the last valid result.

Operators can preview the exact AI request, explicitly generate a cited explanation and unsent draft, and inspect usage and estimated costs. Changed context invalidates previews. Manual drafting remains available without AI. Draft editing, explicit stale review, immediate approval, scheduling and cancellation retain revision checks. Approval discloses the actual mandatory SendGrid footer. Recipient permission, stop rules, quiet hours, limits, bounded retry and ambiguous-delivery reconciliation apply to dispatch. Signed provider events and threaded inbound replies update durable state without duplicate effects. Notifications retain recipient-specific read state.

Authenticated export/restore preserves workspace records and history, with source secrets reconfigured after restoration. The minute timer handles evaluation and dispatch work. Owner extension points and immutable composition provenance support customized fork updates.

## Verification and release evidence

The verification command runs real D1 tests, build/typecheck, shared component/deployment tests, isolated browser journeys, emitted-Worker checks and full declared-capacity measurements. Its result catalog derives status from executed assertions; test names alone do not establish semantic coverage. External installation, native emailed access, actual provider outcomes, recovery and customized-owner updates require their separate receipts.

The 13 September 2026 native acceptance run at Sales `d1dd4a28df5487f35a44bfe40210e76ce124de3d` and Base `dbaf65f3bc9e16bce62cd8cc969a07f0a6d423a9` verified emailed single-use access, actual AI generation, operator-reviewed SMTP delivery, a threaded reply from the test customer, schedule cancellation and provider one-click unsubscribe in 10.75 seconds. A separate auth-only recovery deployment restored every exported domain table, revoked the temporary session and accepted a fresh emailed sign-in. The ordinary owner update preserved a custom generated-column/WITHOUT ROWID data model, customer data and creator-assignment policy through the running application. Later UI copy and privacy-erasure fixes preserve the native provider workflow; a subsequent boundary correction rejects provider redirects without forwarding credentials or request content to another destination. Local two-server redirect checks cover that correction separately from the existing paid-provider receipts. Release evidence records unchanged archive/capacity inputs alongside separate same-name, exact-mailbox and shared-opportunity erasure checks, and binds final gates to the immutable export.

PUBLIC-002 now follows the owner-authorized 13 September ruling: a dedicated real Orbit deployment publishes one explicitly selected workflow-created record, with no recipient address or raw payload exposure. The public page reuses native draft fields for a browser-local preview, never a simulated successful send. Native desktop/mobile checks observed no write requests, no stored draft changes, no outbound messages, no accessibility violations and no access to an unpublished record. SETUP.md describes the explicit publishing boundary. The original browser-generated sample approach is preserved in the dated contract rationale, not shipped as runtime data.

Run `pnpm verify` from the committed authoritative edition for the final contract, emitted-Worker, browser and declared-capacity verdict. Keep prior failed attempts alongside the final receipts. Historical pilot evidence below remains distinct from complete-product acceptance.

The existing pilot Worker and its D1 remain intact. A new production installation must name its separate resources and document any later adoption of pilot data. No destructive migration or replacement of the pilot dataset is authorized by this handover.

## Deployed pilot evidence — 12 September 2026

The pristine composed Sales revision `5f1ab8f94aebf11170a1b2d761950d7d0e52d950` with Base `976859c9c7b50f6e8456d89ba21c975fd4d4e96d` was installed with the frozen lockfile and deployed using `pnpm run deploy -- --owner-file <private owner JSON>` to `https://orbit-sales-pilot-20260912.james-d16.workers.dev`. The same command was run again successfully; final Worker version is `aa103a4d-77c7-4a47-9ea1-74cf100da608`. Both live health checks passed.

Before workflow verification, remote D1 contained exactly one owner/operator, one workspace, three stages, and no customer records, signals, drafts or sessions. The deployed public documents and native access denials worked. A bounded test session was inserted in remote D1 solely for this verification and exercised the actual production session guards; this does not prove consumption of the emailed magic link. It was revoked afterward and subsequent API access was denied.

Exactly one native sign-in request and one operator-reviewed outreach submission were made to the owner's authorized mailbox. The browser inspected the exact persisted recipient, subject and body before approval. The real workflow created one account/contact/opportunity, stored one attributed signal with score 25 and cited evidence, persisted one draft, recorded one provider-accepted outbound message and moved the opportunity to NEXT. The provider receipt is recorded in `verification/deployed-pilot-20260912.json`; provider acceptance is not mailbox delivery, which was not verified.

Redeployment preserved the same D1 ID, owner/workspace/pipeline, workflow records and single outbound message. There are zero fixture seed runs and zero active test sessions. No private deployment configuration, owner file, token or secret file is committed. The sanitized evidence JSON and `visual/13-deployed-opportunity.png` document this bounded pilot; this pilot receipt does not establish later complete-product acceptance.

## Materialized verification and evidence identity

Local reporting also works in a Git-free `materialize` build tree. Such a tree cannot certify external receipts with a Git identity. External receipts are considered only at the actual edition repository root with matching HEAD and unchanged source outside verification evidence; hosted receipt generation retains its stricter clean-source preflight. Three focused regressions cover Git-free reporting, enclosing repository identities, dirty source and hosted preflight. Reprocessing the retained local results in a real materialization reported 86 satisfied clauses; this was not a new runtime suite run.

The earlier full verification ran in the conversion working tree with the 199 protected files byte-identical to completed Sales `4b7a3a6` and Base `603ee025` before and after execution. The subsequent clean release independently passed build, typecheck, component, receipt and source checks. Keep these two evidence scopes distinct; no full suite was rerun for this reporting-only correction.