Getting started
Use BayStore when the thing being sold is a named private instance, not seats in a shared tenant or raw hosting capacity.
Reference
Documentation for selling and operating product instances.
This entry point keeps public documentation separate from the operator console while exposing the concepts a buyer needs before launch.
Docs map
Start with the decision you need to make.
The public docs hub is written for buyers, founders, platform teams, and security reviewers evaluating whether BayStore's product-instance model fits their launch.
Harbor setup
Orbit and OpenClaw share the same buyer-visible instance model: product, berth, order, access metadata, and lifecycle state.
Lifecycle and operations
Instances move through fixed states so buyers and operators do not have to infer what happened from a support thread.
Quick start
Run the fit check before choosing a berth.
| Step | Decision | Use this route |
|---|---|---|
| 1. Instance shape | Confirm the offer is a named private instance with product, plan, order, access metadata, and lifecycle state joined. | Mooring paths, Compare |
| 2. Product harbor | Select Orbit, OpenClaw, or a sales-reviewed instance family before capacity is discussed. | Harbor, Orbit, OpenClaw |
| 3. Berth depth | Map the instance to Trial, Standard, Pro, or Enterprise language without treating static pricing as live billing. | Berths, Moor an instance |
| 4. Tide boundary | Check the lifecycle state, sandbox boundary, security review path, and deferred production dependencies before launch handoff. | Tides, Launch checklist |
Lifecycle contract
Canonical instance state tokens.
pendingprovisioningactiveupgradingsuspendedfaileddeleted
| Token | Public meaning | Boundary |
|---|---|---|
pending | Commercial intent exists. The instance has not reached provisioning. | No runtime availability or payment capture is implied. |
provisioning | Desired state is recorded and setup work is visible. | M100 can include provisioning evidence only inside the bounded non-payment launch packet. |
active | The instance is usable within the current stated boundary. | M99 can evidence customer-owner Web access; live payments, hosted checkout, and full production readiness remain separate claims. |
upgrading | Capacity or version-change intent is attached to the instance record. | Returning to active stays tied to the M100 evidence path and approved launch dependency. |
suspended | Access is paused while commercial and support context stays attached. | Resume is an explicit operation, not an inferred side effect. |
failed | A readiness or operation gate failed and needs retry, rollback, or support review. | Failure evidence is preserved; history is not overwritten. |
deleted | The instance is retired as a terminal state. | Retention, deletion proof, and legal obligations require approved policy. |
Reference index
Public docs by review job.
Founder or product leadWhether product-instance commerce fits the offer. Start with Mooring paths and Compare.
Platform engineerHow orders, provisioning, failures, and recovery stay observable. Start with the Lifecycle guide and How it works.
Security reviewerWhich commitments are stated, deferred, or pending approval. Start with Security and the DPA.
Finance or operationsPlan and support markers before production billing exists. Start with Pricing and Status.
Launch ownerEvidence still needed before any production claim. Start with the Launch checklist and Contact.
Implementation boundary
What the current static launch covers.
| Topic | Public docs answer | Production dependency |
|---|---|---|
| Checkout | Checkout is documented as sandbox_placeholder; public pages do not claim live provider billing. | Provider-approved live payments, hosted checkout, webhooks, tax, receipts, and merchant review. |
| Customer access | M99 covers Web signin, dashboard target matching, Web /api Harbor access, Open berth UI, product access probe, and owner boundaries. | Long-term identity provider, account issuance, sessions, and authorization operating policy. |
| Runtime operations | M100 reads the API/worker/runtime/customer-owner evidence path and can return GO_NON_PAYMENT_BOUNDED for the bounded non-payment launch packet. | Managed Vault/KMS, managed SaaS observability/on-call, managed backup RPO/RTO, and full production readiness remain non-claims. |
| Status and API | Status explains surface readiness; M100 pins api_origin api.baystore.com without presenting API access as a public developer platform. | Deployment-specific status provider, API auth, rate limits, docs generation, and support process. |
| Sandbox boundary | Public docs can support fit, procurement, and launch planning for a static evaluation surface. | Provider billing, live payment capture, hosted checkout, and legal approval remain separate gates. |
Procurement review starts here.
The public site publishes the security posture, privacy policy, terms, DPA, and cookie policy so buyers can follow the full review path, including the contracting entity, jurisdiction, subprocessors, retention schedule, and commitments.
Use evidence, not assumption.
A launch owner can use this hub to assemble fit, berth, lifecycle, security, status, and contact evidence. A production claim still needs payment-provider approval, legal signoff, and any managed-provider evidence outside the M100 bounded packet.
Docs handoff: This static page is the public documentation entry for launch evaluation. A generated API reference, CMS, or full docs site can replace it later without changing the Harbor / Berths / Tides / Docs navigation contract.