Commercial state
Plans describe capacity, backup metadata, access eligibility, and support markers for one named instance.
Mooring path
Managed product instances for buyers who need private state.
BayStore keeps each order tied to a named product instance, plan, lifecycle state, and access boundary so sales, support, buyers, and operators talk about the same object.
Why it matters
Dedicated instance buying needs more than a product card.
Customer visibility
The buyer can see lifecycle state and access metadata without seeing operator-only controls or internal runtime details.
Operational boundaries
Access metadata reflects the sandbox/test-runtime boundary unless a separate production deployment is completed.
Shared vocabulary
The instance record becomes the source of truth for launch state.
| Question | BayStore answer | Boundary |
|---|---|---|
| What did the buyer choose? | Product family, plan depth, and account metadata. | Checkout remains sandbox_placeholder; this public site does not charge cards or configure production provider billing. |
| Where is the instance? | Lifecycle state moves from pending to provisioning, active, suspended, failed, or deleted. | State is visible; M100 provides the bounded non-payment evidence path for launch review. |
| How does access work? | Access metadata appears when the instance reaches the appropriate lifecycle state. | M99 covers customer-owner Harbor access boundaries; long-term identity policy remains a launch decision. |
Berth manifest
Every managed instance needs the same buyer-readable manifest.
Commercial recordThe manifest names the product family, selected berth depth, customer owner, support marker, and launch contact before runtime access is discussed.
Access boundaryAccess metadata can be shown in sandbox/test-runtime form. Production routing, sessions, and authorization remain deployment evidence.
Operating stateLifecycle state, operator action records, backup metadata, and restore intent stay attached to the same named instance.
Production handoff
What changes when the berth leaves evaluation?
IdentityReplace intake-only sign-in pages with approved customer auth, sessions, account issuance, and authorization rules.
BillingReplace static berth copy with provider-approved checkout, receipts, tax handling, refunds, and order-form policy.
RuntimeReplace recorded operator intent with worker-backed execution, queues, secrets, clusters, runbooks, and rollback evidence.
TrustConfirm the legal and security commitments — terms, DPA, privacy details, subprocessors, retention, and incident process — in the order.
- Private workspaces, coordination tools, automation engines, and internal platforms sold as named instances.
- Teams that need buyer-friendly readiness language before production launch.
- Operators who want an audit trail before wiring production runtime actions.