Planned identity boundary
The production design is intended to authenticate operators at the edge, then resolve a verified identity against organization memberships before selecting a tenant.
Security Design
Dealer data stays on the dealer side of the table.
For production, StockDex Pro is being designed around tenant boundaries, narrow public views, attributable operator actions, and deployment checks that fail closed.
Planned tenant scoping
The production data model is intended to carry an organization identifier on inventory, events, storefronts, print jobs, and mutations. A client-supplied organization choice will not grant membership.
Planned public surfaces
Public QR item pages and storefronts are intended to use explicit field lists: card identity, condition or grade, availability, and asking price—not cost, margin, notes, or staff history.
Planned integration boundary
Market-link discovery is intended to keep provider credentials server-side, use transient responses without an application cache, and keep discovery data out of the price book.
Planned remote protection
Remote deployment mode is intended to require a valid access assertion even when traffic reaches the application origin directly. Public routes are intended to remain read-only.
Release acceptance criteria
Before a production deployment is accepted, the release process is intended to verify the exact Git revision, migration count, HTTP readiness, and restart policy.
Design intent—not a certification or claim of current production availability. Controls and vendors may change during private beta, and StockDex Pro does not claim a third-party audit it has not completed.
Private Beta
Put StockDex Pro behind your table.
Tell us how you intake, price, label, and sell today. We will map the first workflow with you.