10 pillars. One platform. One ledger.

Your headless build and our hosted theme run the same renderer at runtime, so there is no divergence between what engineering deploys and what merchants configure.

Both deployment modes compile to the same Next.js server components and share a single set of data-fetching hooks against the platform API. A section component built for the hosted theme works identically when dropped into a headless project, and vice versa — the only difference is where the server process runs. This means you can migrate from hosted to headless (or back) without rebuilding your content model, and preview links work identically in both environments.

• Single compiled renderer output for hosted and headless modes
• Shared section component library — build once, run anywhere
• Live-preview works identically in both deployment targets
• No content-model migration required when switching modes
• Theme overrides respected in headless builds via cascade config

Hot pages stay fresh through incremental static regeneration; cold pages are generated on demand and cached at the edge, keeping compute costs proportional to traffic.

Product detail pages, collection pages, and content-heavy landing pages are statically generated at build time and served from the CDN. When a merchant updates a product or a price changes, the platform fires a targeted revalidation webhook that purges only the affected pages — not the entire cache. The platform also exposes an admin trigger for manual purges, giving operations teams a break-glass option during live campaigns without touching deployment pipelines.

• Targeted page-level revalidation on catalog and content changes
• Manual purge trigger available from the admin console
• Stale-while-revalidate semantics to avoid thundering-herd on purge
• Edge-cached HTML responses served in single-digit milliseconds
• Build-time pre-rendering for the highest-traffic URL patterns

Marketers assemble and publish pages visually; engineers add new sections as typed React components without owning layout or content orchestration.

The section system is a content-addressable component registry. Each section is a typed React component that declares its own props schema — the visual editor auto-generates the input form from that schema, so there is no separate form to maintain. Marketers drag sections onto a page, fill props in a side panel, and publish to a staging URL before going live. Engineers add new section types by exporting a component plus a Zod schema; the platform handles versioning and migration when props change.

• Props schema auto-generates the visual editor input form
• Staging preview URL generated before every publish
• Section library is versioned; prop migrations handled by platform
• Sections nest and reorder without code changes
• Full undo/redo history persisted per merchant workspace

Per-segment hero images, badges, and prices are resolved at the edge in milliseconds, so every visitor receives a targeted page without a client-side rehydration round-trip.

At request time, the edge worker reads a compact segment token from the visitor's cookie (set during sign-in or resolved from a geo/device fingerprint) and merges segment-specific overrides into the page context before rendering. Overrides can target hero content, price display, badge copy, and product ordering — all configured in the admin rule builder without code changes. Because the merge happens server-side before HTML is emitted, personalized pages are still fully cacheable at the segment level and retain their SEO value.

• Segment token resolved in the edge worker before HTML render
• Hero images, badges, and prices overridable per segment
• Pages cached at the segment level, not just globally
• Admin rule builder — no code changes to configure new rules
• Geo and device signals available as fallback segment inputs

Currency, locale, tax rules, shipping zones, and hreflang tags are handled centrally, so launching a new market is configuration, not a new codebase.

Each market is defined as a combination of locale, currency, tax region, and shipping profile. The storefront resolves the correct market from URL prefix, Accept-Language, or explicit merchant routing rules, and passes a typed market context to every component. The sections below break out the three axes of international commerce — currency, country/market, and language — each of which is independently configurable.

• 28+ market definitions shipped out of the box
• URL-prefix and Accept-Language market resolution
• Market context is typed and available to every component at render time
• Each axis — currency, market, language — is independently configurable
• Launch a new market without writing code or touching the renderer

Display and settle in the currency your customer expects — with live or pinned FX rates, locale-correct formatting, and rounding rules that respect each currency's conventions.

Each market is assigned a display currency; a separate settlement currency is configured at the payment provider level, so a Euro storefront can settle in USD without exposing that to the customer. Exchange rates are either pulled on a configurable schedule from a rate provider or pinned manually for campaigns where price stability matters more than accuracy. Price formatting follows CLDR rules for each locale — ¥ renders without decimal places, CHF rounds to 0.05, and currencies that use period vs. comma as the decimal separator are handled automatically. Tax-inclusive and tax-exclusive display mode is set per market independently of the currency.

• Display currency is set per market; settlement currency is set independently at the payment layer
• FX rates: live on a configurable refresh schedule or manually pinned per campaign
• CLDR-correct formatting — ¥ no decimals, CHF 0.05 rounding, correct separators per locale
• Tax-inclusive vs. tax-exclusive price display configured per market, not globally
• Currency-aware rounding rules applied consistently across cart, checkout, and invoices

Launch a new country market as pure configuration — per-market catalog availability, pricing, tax regions, shipping zones, and payment methods, with geo-routing to land visitors in the right market automatically.

A market is a first-class entity: it bundles a locale, currency, tax region, set of active shipping zone profiles, and a list of permitted payment methods. Catalog availability is scoped per market — a product can be live in EU markets and hidden from US while sharing the same SKU and inventory. Market resolution runs in the edge worker on every request: the worker checks the URL prefix first, then the Accept-Language header, and finally an explicit routing rule (e.g., IP-to-country lookup) — the first match wins and is stored in a cookie for the session. Per-market legal pages (terms, privacy, returns) are linked in the market config and rendered at the correct URL.

• Market bundles locale, currency, tax region, shipping profiles, and payment methods in one config object
• Per-market catalog availability — show or hide any product or collection per market
• Market resolution order: URL prefix → Accept-Language → IP geo-routing rule → cookie fallback
• Per-market shipping zone profiles and carrier rule sets, not a single global shipping table
• Per-market legal pages (terms, privacy, returns) linked in config and rendered at market-scoped URLs

Full content localization for products, collections, and CMS sections — with locale fallback chains, RTL support, auto-generated hreflang alternates, and a translator workflow with per-string status tracking.

Every translatable string — product titles, descriptions, collection names, CMS section copy — is stored as a locale-keyed record alongside the source. At render time the storefront resolves the best available locale using a configurable fallback chain (e.g., fr-CA → fr → en), so there is never a blank field due to a missing translation. RTL languages (Arabic, Hebrew) trigger a direction flag on the HTML element and flip layout utilities automatically. SEO metadata — title tags, meta descriptions, Open Graph — is generated per locale, and hreflang alternate link elements are emitted for every active locale so search engines index the correct regional URL. The translator workflow exposes a per-string status (untranslated, draft, approved) and a locale progress dashboard so content teams can track completeness before launching a new locale.

• Locale-keyed translations for products, collections, CMS sections, and checkout copy
• Configurable fallback chain per locale — no blank fields from missing translations
• RTL language support: direction flag on HTML element and automatic layout utility flipping
• Auto-generated hreflang alternate link elements for every active locale
• Translator workflow with per-string status (untranslated / draft / approved) and locale progress dashboard

Generate per-SKU translations across 20+ languages in bulk using your configured AI model, with per-string human review before any translation reaches the storefront.

Commissioning human translators for a 50 000-SKU catalog across 10 locales is prohibitively slow and expensive. The AI translation workflow lets you select any slice of your catalog — a supplier batch, a new collection, all untranslated strings for a target locale — and submit it as a background generation job. Your configured AI model (Claude, GPT-4o, or Gemini) translates each string with a structured prompt that includes the source text, locale context, and any brand voice or glossary guidelines saved at tenant level. Outputs land in the untranslated → draft state, waiting for per-string human review before they advance to approved and go live on the storefront. For high-throughput teams, a batch-approve flow lets a reviewer approve a locale's full draft set in one action after spot-checking. Translation quality metrics (review acceptance rate, edit distance from AI draft to approved string) are tracked per locale and per job.

• Bulk generation across 20+ languages — submit an entire collection or locale in one job
• Supports Claude, GPT-4o, and Gemini — per-tenant model routing and BYO keys
• Brand voice guidelines and terminology glossaries injected into every translation prompt
• Per-string draft state — AI output never auto-publishes without human review gate
• Batch-approve flow for high-throughput locales after spot-check review
• Quality metrics: acceptance rate and edit distance tracked per locale and per generation job

Customers find what they mean, not just what they type — semantic search with typo tolerance, synonym expansion, and zero-result recovery surfaced directly in the storefront UI.

The Kynetra Search and vector embedding layers (built in the AI pillar) are exposed as a first-class storefront UX feature. The search bar supports natural-language queries ('comfortable running shoes for flat feet'), not just keyword matching. Typo tolerance handles common misspellings without requiring a curated correction list. Synonym expansion maps colloquial terms to catalog attributes (e.g., 'mobile' → 'smartphone'). When no keyword matches exist, the semantic fallback runs an ANN vector search and returns the closest catalog matches with a 'showing results for…' label rather than an empty page. Frequently-bought-together and customers-also-viewed recommendations are injected below search results on the product page, powered by the same embedding index. All search events (query, results shown, clicks, add-to-cart) are fed back to Kynetra Prime as training signal to improve future relevance automatically.

• Natural-language query support — 'comfortable running shoes for flat feet' returns relevant results
• Typo tolerance without a manually curated correction list
• Synonym expansion from colloquial terms to catalog attribute values
• Zero-result recovery via semantic ANN fallback — no empty search pages
• Frequently-bought-together and customers-also-viewed rails on the product page
• Search events (query, clicks, add-to-cart) feed Kynetra Prime's auto-train loop

The storefront ships as a Progressive Web App — installable directly from the browser, capable of offline browsing, and updatable instantly without an app-store release cycle.

A Progressive Web App combines a web app manifest (name, icons, display mode, theme color) with a service worker that pre-caches shell assets and key catalog pages on install. The storefront registers a beforeinstallprompt handler to surface a native install prompt at the right moment in the customer journey, and a dedicated /app page explains the install flow with device-specific instructions. Once installed, the app launches in standalone full-screen mode from the home-screen icon with no browser chrome — identical to a native app from the customer's perspective. Because it is still a web app, every update ships the moment a new deployment lands: the service worker detects the changed asset manifest, fetches the delta in the background, and activates on the next navigation — no App Store review, no user-initiated update, no version fragmentation.

• Installs to the home screen from the browser — no App Store or Play Store submission, review delay, or 15–30% store commission
• Service worker caches shell and catalog assets so browsing and cart work on flaky or offline connections
• Web Push support for drop alerts, back-in-stock, and order update notifications (where OS/browser permits)
• Updates ship instantly on deployment — no release cycle, no app-store approval, every user always on the latest version
• Full-screen standalone display and near-instant launch; smaller footprint than a native binary
• Dedicated /app install page with device-specific instructions and a beforeinstallprompt-driven in-app prompt

Run experiments on layout, copy, price, and product order directly from the admin, with bucketing handled at the edge and results tied to actual order conversions.

Experiments are defined as a set of variants (each a named set of section prop overrides or route-level changes) plus a traffic split and a primary metric. The edge worker buckets each visitor deterministically by user ID or anonymous ID and applies the correct variant before rendering — no client-side flicker. Results are aggregated against the same order and revenue events that power your analytics, so conversion lift is measured against real checkout completions, not proxy metrics. Experiments can be paused or force-assigned to a variant from the admin without a deployment.

• Deterministic bucketing at the edge — zero client-side flicker
• Variants can change sections, copy, prices, and sort order
• Results joined to actual order and revenue events
• Pause, stop, or force-assign variant from admin without deploy
• Bayesian significance reporting with configurable confidence threshold

Every store gets its own white-label App Store and Play Store app, configured from the admin — same storefront, on the home screen, with push notifications and native share.

The native apps are generated per tenant from a single shared codebase, so each merchant ships an app under their own name, icon, splash screen, and bundle id without a separate engineering project. The app loads the merchant's live storefront — the exact same renderer that runs on the web, so there is no second frontend to maintain and features land on web and mobile simultaneously. Identity, branding, push provider, deep-link scheme, and store URLs are all set in Settings → Mobile App; the build pipeline reads that config, downloads the assets, and produces signed-ready iOS and Android projects. Push tokens register against the same customer record as web and POS, and a server-driven version gate can force an update before an outdated app continues.

• White-label per-tenant app — own name, icon, splash, and bundle id
• Loads the live storefront renderer — no separate mobile frontend
• Configured entirely from admin Settings → Mobile App
• Push notifications register to the unified customer record
• Server-driven force-update gate for outdated app versions
• One generated build pipeline produces both iOS and Android projects

Sell, refund, and capture customer details for up to 72 hours with zero connectivity, then reconcile automatically when the device reconnects.

The POS app maintains a local SQLite journal of all transactions on the device. Inventory availability is snapshotted at sync time and updated optimistically during offline operation; when the device comes back online, the journal is replayed against the platform's central ledger in timestamp order, and any conflicts (such as items that went out of stock on another channel) surface as flagged exceptions for staff to resolve. Payment terminals that support offline authorizations are integrated into this flow — approved offline charges are submitted for settlement automatically on reconnect.

• Local SQLite transaction journal with 72-hour retention
• Optimistic inventory decrements during offline operation
• Automatic journal replay and conflict surfacing on reconnect
• Offline payment terminal authorization for supported hardware
• Customer capture (email, phone, loyalty lookup) works fully offline

A cart started in-store can be completed online, and an online cart can be paid at the counter — inventory stays accurate in both directions.

Carts are stored centrally and addressed by a short code or QR that can be scanned at any POS terminal or loaded on any web session. When a staff member pulls up a web order at the terminal to accept payment in-store, the order's fulfillment method updates automatically and inventory is not double-decremented. The same mechanism powers "ship from store" — a POS transaction can trigger a pick-and-pack workflow without any manual re-entry.

• Cart transfer via short code or QR scan — no manual re-entry
• Fulfillment method reattribution when channel switches
• No double-decrement on cross-channel inventory
• Online returns processable at any POS terminal
• Ship-from-store order creation directly from POS cart

A pre-certified set of terminals, receipt printers, label printers, scales, and kitchen display screens ships ready to use with zero driver configuration.

The reference stack covers the most common hardware from BBPOS, Verifone, Star Micronics, Epson, and Ohaus, with driver bundles that are tested against each platform release. Pairing a new device is a QR scan from the admin — no IP configuration or certificate management required. Kitchen display screens and label printers are addressed as output channels on a per-location basis, so a single terminal can route receipts to the front counter and order tickets to the kitchen without custom code.

• Certified integrations: BBPOS, Verifone, Star, Epson, Ohaus
• QR-based device pairing — no IP or certificate configuration
• Per-location output channel routing (receipt, label, KDS)
• Hardware tested against each platform release before shipping
• Add-on peripherals (scales, barcode scanners) via USB-HID driver bundle

Sales per hour, basket size, attach rate, and refund rate are calculated in real time and displayed on every device, so managers have visibility without pulling a report.

Each transaction is attributed to the logged-in staff member at the time of payment. The metrics engine aggregates over a rolling window (current shift, today, last 7 days) and pushes updates to devices over a WebSocket channel — no manual refresh. Attach rate tracks when a secondary product is added to a transaction that started with a single item, making it useful for measuring upsell coaching effectiveness. Refund rate is tracked separately from voids so that post-sale returns do not inflate the void signal.

• Real-time push updates via WebSocket — no refresh required
• Rolling windows: current shift, today, last 7 days
• Attach rate metric for upsell coaching visibility
• Refund and void tracked as separate signals
• Per-location leaderboard view for managers

Points earned, rewards redeemed, and tier status checked in two taps at checkout — promotions and loyalty stack predictably every time.

At checkout, the POS resolves the customer's loyalty profile by phone number, email, or scan of a wallet pass, and displays available rewards alongside the current cart. The platform's promotion engine runs the same stacking logic used online — it evaluates all active promotions and loyalty rules in a single pass and applies them in the configured priority order, so staff cannot accidentally over-discount a transaction. Points are awarded and tier recalculations triggered as part of the order-complete event, not as a separate async job, so the receipt is always accurate.

• Customer lookup by phone, email, or wallet pass QR
• Available rewards surfaced inline on the cart screen
• Same stacking logic as online — no separate POS promotion config
• Points awarded synchronously on order complete, not async
• Tier recalculation and threshold notifications shown at receipt

Granular permission sets, manager override flows, and end-of-day cash-drawer reconciliation give operators tight control over what staff can and cannot do.

Roles are defined at the organization level and assigned per-location. Sensitive actions — refunds above a threshold, price overrides, discount applications above a set percentage, cash-drawer opens without a transaction — each require a manager PIN or NFC badge tap, and the override is logged with the authorizing manager's ID. End-of-day cash reconciliation prompts staff to count the drawer and compares the counted total against the expected total derived from the day's cash transactions, flagging any variance for manager review.

• Org-level roles assigned per-location, not per-device
• Manager PIN or NFC badge tap for override actions
• Every override logged with authorizing staff ID and timestamp
• Configurable thresholds for refund, discount, and price-override gates
• End-of-day drawer count reconciled against transaction-derived expected total

Orders are assigned to fulfillment nodes according to merchant-defined rules that weigh cost, carbon footprint, available capacity, and promised delivery SLA simultaneously.

The routing engine evaluates each order against a ranked set of merchant-configured rules at the moment the order is placed. Rules can reference carrier rate quotes (fetched in real time from connected carrier APIs), location stock levels, DC capacity utilization, and estimated transit days to the delivery address. When no single node is optimal, the engine can split the order across locations and route each line separately, generating distinct shipments with their own tracking numbers. Merchants can inspect every routing decision and its score in the order timeline.

• Real-time carrier rate fetches factored into routing score
• Multi-node split routing with per-line shipment generation
• Configurable rule priority: cost, SLA, carbon, capacity
• Routing decision and score recorded on every order timeline
• Override routing manually from the order detail page

Inventory is held with an optimistic reservation the moment an order is placed across web, POS, and marketplace channels, keeping oversell rates near zero without locking stock.

When an order is placed, the platform immediately writes a reservation record against the fulfillment location's available quantity. Reservations are optimistic — they do not use database row locks — but the reservation table is append-only and reconciled against committed stock in a sub-second background check. If two simultaneous orders would exhaust the last unit, the slower reservation is automatically escalated to an exception queue where it can be resolved by sourcing stock from another location or notifying the customer. This architecture handles high-concurrency flash-sale loads without serializing checkout.

• Append-only reservation table — no database row locks at checkout
• Sub-second reconciliation against committed stock levels
• Automatic exception queue for over-reservation edge cases
• Reservations visible across web, POS, and marketplace channels
• Reservation expiry configurable per channel (e.g., POS holds expire sooner)

Built-in pick-path optimization, multi-order cluster picking, and cart logic eliminate the need for a separate WMS license for most warehouse configurations.

Pick waves group orders by shipping carrier cutoff time, shipping zone, or product zone within the warehouse. Within a wave, the planner builds pick batches that minimize travel distance using a configurable slot-location map; pickers on mobile devices follow a prompted path through the warehouse and scan each item to confirm. Cluster picking allows a single picker to carry multiple orders simultaneously, with the device UI directing them to deposit each item into the correct tote as they traverse the pick path. All of this runs on warehouse staff's existing Android or iOS devices — no proprietary hardware required.

• Wave grouping by carrier cutoff, shipping zone, or product zone
• Travel-distance optimization using configurable slot-location map
• Cluster picking for multi-order simultaneous picks on one device
• Scan-to-confirm on Android or iOS — no proprietary hardware
• Real-time wave progress dashboard for warehouse supervisors

Customers can drop returns at any participating store location; automated grading and restock workflows handle what happens next without manual touchpoints.

When a return is initiated, the platform generates a return authorization with a QR code the customer presents at any networked store. The receiving associate scans the QR, the return item is logged against the original order, and a grading prompt guides them through a condition assessment (sellable, refurbish, liquidate, discard). Based on the grade and merchant-configured restock rules, the item is either restocked to the receiving location's available inventory or routed to a returns processing center. Refunds are triggered by the grading action, not held until the item reaches a central DC.

• Any-store drop-off with QR-based return authorization
• Guided grading workflow: sellable, refurbish, liquidate, discard
• Refund triggered at grading — not held for central DC receipt
• Configurable restock rules per condition grade and product category
• Returns processing center routing for non-sellable items

Issue refunds as instant wallet credits or store-value balances — spendable at checkout before the bank transfer settles, with no manual reconciliation.

Bank refunds take 3–5 business days, losing the customer for days after an already-frustrating return experience. The wallet refund path issues credit to the customer's loyalty wallet the moment grading is completed — visible in their account immediately and spendable at the next checkout. Merchants configure which refund method to offer (bank transfer only, wallet-credit default, customer's choice) per return reason code and order value threshold. Wallet credits are issued as a stored-value instrument with an optional expiry and are redeemable across all channels — web checkout, POS, and conversational checkout — from the same wallet balance. For multi-brand operators, credits issued by one brand are redeemable across the entire network, which turns a return into a cross-sell moment rather than a cost center.

• Wallet credit issued at grading — customer sees value instantly, not after 3–5 day bank delay
• Configurable refund method per return reason code and order value: bank, wallet, or customer choice
• Optional credit expiry date to create urgency for re-purchase
• Redeemable across web checkout, POS, and conversational channels from a single balance
• Cross-brand redemption for multi-brand operators — returns drive network-wide re-engagement
• Full ledger trail: return authorization → grading event → credit issuance → redemption

Regulated and perishable goods are tracked end-to-end with lot numbers, serial numbers, and expiry dates, providing audit-grade traceability from receipt to dispatch.

Lot and serial numbers are captured at goods receipt and propagated through every inventory movement — putaway, pick, pack, transfer, and return — creating a complete chain of custody for each unit. Expiry dates trigger configurable alerts when stock falls inside a defined window and can enforce FEFO (first-expiry, first-out) pick sequencing automatically. For serialized goods, the platform supports GS1 GTIN + serial number scanning at pack-out, generating a scan record that can be provided to downstream partners or regulators on demand.

• Lot and serial number captured at goods receipt and propagated through all movements
• FEFO pick sequencing enforced automatically by expiry date
• Configurable expiry alerts at merchant-defined day thresholds
• GS1 GTIN + serial scan at pack-out for compliance reporting
• Full chain-of-custody audit log queryable by lot, serial, or order

First-party API connections to UPS, FedEx, DHL, USPS, Royal Mail, and AusPost mean you pay carrier rates directly, with no middleware markup or API intermediary.

Each carrier integration authenticates directly with the carrier's production API using the merchant's own account credentials, so negotiated rates and account-level services are available immediately. Rate shopping at label creation evaluates all connected carrier services for the shipment's dimensions, weight, and destination, presenting the cheapest option within the SLA, or auto-selecting if configured. Tracking events are ingested via carrier webhooks where available and polled on a schedule otherwise, and normalized into the platform's unified tracking event schema so your customer-facing notifications work identically regardless of which carrier fulfills the order.

• Direct carrier API auth using merchant's own account credentials
• Real-time rate shopping across all connected carrier services
• Auto-select cheapest within-SLA carrier at label creation
• Unified tracking event schema across all carriers
• Customer notifications triggered by normalized tracking events, not carrier-specific webhooks

Maintain per-channel titles, images, and pricing from a single canonical product record.

Each channel has its own content and policy requirements — character limits, image ratios, restricted attributes — and trying to shoehorn a single description into all of them degrades conversion on every one. Channel-aware listings let you define a base record and then layer per-channel overrides (title, bullet points, hero image, price, tax category) that are applied at publish time, not stored as forks. When you update the canonical record, channels inherit the delta unless an override is in place. This means you move fast on catalog updates while keeping each listing precisely tuned.

• Per-channel title, bullet-point, and image overrides without forking the base record
• Automatic attribute mapping to Amazon, Google, and TikTok taxonomy schemas
• Channel-specific pricing rules (currency, margin floor, MAP enforcement)
• Publish, pause, and archive listings across all channels from one action queue
• Conflict detection when a channel override would violate a channel policy

Run your own marketplace — vendors, commissions, payouts, and tax document generation are all built into core.

Building a multi-vendor marketplace on top of a monoproduct platform typically means stitching together a payout provider, a vendor portal, a commission engine, and a tax document generator. QuantumOS X3 ships all of these as first-class platform primitives. Vendors onboard with scoped credentials, submit products for catalog review, and receive automated payouts on a configurable schedule. Commission rates can be set at the marketplace level, by vendor tier, or per SKU. Tax document generation (1099 in the US, T4 in Canada) runs on the same payout ledger, so there is no reconciliation step.

• Vendor onboarding portal with scoped catalog and order permissions
• Commission configuration at marketplace, tier, or SKU granularity
• Automated payout scheduling with hold, dispute, and release workflows
• 1099 (US) and T4 (Canada) generation from the payout ledger — no separate tool
• Vendor-level performance dashboard: GMV, returns rate, fill rate, payout history

Ad spend, ROAS, and incremental lift reconciled to actual orders on a daily cadence.

Most ad platforms report attributed revenue using their own click-based windows, which inflate ROAS and make channel-to-channel comparison meaningless. QuantumOS X3 pulls raw spend data from connected ad platforms (Meta, Google, TikTok, Pinterest) and reconciles it against the order ledger using a configurable multi-touch attribution model. The result is a single blended view of spend efficiency that is grounded in transactions rather than platform-reported conversions. Teams can choose last-click, linear, time-decay, or data-driven models and compare them side by side.

• Daily spend ingestion from Meta, Google, TikTok, and Pinterest via platform APIs
• Order-level reconciliation against actual revenue, not platform-reported conversions
• Configurable attribution model: last-click, linear, time-decay, or data-driven
• Incremental lift analysis via holdout group comparisons
• ROAS and CPA broken out by channel, campaign, ad set, and product

Reviews collected across channels flow back into your hosted storefront automatically.

Reviews on Amazon or Google carry social proof that shoppers trust, but they typically sit in channel silos and never make it back to your own storefront. QuantumOS X3 aggregates verified review content from connected channels, normalizes the rating scale, and surfaces it on your product pages with source attribution. Because reviews are tied to the canonical product record, they aggregate across channel variants (color, size) correctly. Moderation controls let you quarantine low-quality or policy-violating content before it goes live.

• Aggregation from Amazon, Google Shopping, Etsy, and eBay into one review feed
• Source attribution preserved on storefront (e.g., 'Verified purchase on Amazon')
• Normalized rating display with weighted aggregate when scales differ across sources
• Moderation queue with quarantine, approve, and reject actions
• Review reply syndication: reply once and publish to the originating channel

Auto-generated Google Merchant Center, Meta, and TikTok feeds with rules-based suppression.

Keeping product feeds healthy is unglamorous but high-leverage — a disapproved feed means zero impressions regardless of budget. QuantumOS X3 generates GMC, Meta Catalog, and TikTok Product feeds continuously from the live catalog, applying channel-specific field transformations (GTIN normalization, image URL formatting, availability mapping) automatically. Rules-based suppression lets you exclude products by stock status, margin threshold, category, or custom attribute without touching the base catalog. Feed diagnostics surface disapproval reasons and link directly to the offending product record.

• Continuous feed generation — no manual exports or scheduled uploads
• Rules-based suppression by inventory status, margin, category, or custom tag
• Channel-specific field transformation: GTIN normalization, URL signing, availability strings
• Feed health dashboard with disapproval reasons linked to product records
• Support for supplemental feeds for promotional pricing and sale events

Per-channel attribute mapping and auto-generated feeds purpose-built for Amazon.in, Flipkart, and Meesho — with the field-level transforms each channel demands.

India's three dominant marketplaces each enforce distinct attribute schemas, image specifications, and feed formats that global catalog syndication tools handle poorly. QuantumOS X3 ships native feed generation for all three: Amazon.in flat-file format with category-specific attribute sheets, Flipkart's JSON product upload API, and Meesho's CSV/xlsx bulk-upload specification. Per-channel attribute mappings translate your canonical PIM attributes — brand, material, size, color, HSN code, country of origin — to the exact field names and allowed values each marketplace requires. Variant grouping (parent–child ASIN structure for Amazon, style IDs for Flipkart) is handled automatically from your PIM's variant model. Feed generation runs on a configurable schedule or on-demand, and a validation pass flags schema errors before submission.

• Amazon.in flat-file generation with category-specific attribute sheet selection
• Flipkart JSON product upload API with parent–child style variant grouping
• Meesho CSV/xlsx bulk-upload format with auto-mapped allowed-value lists
• Per-channel attribute mapping: brand, material, size, color, HSN code, country of origin
• Variant structure auto-generated from PIM variant model — no manual parent/child setup
• Pre-submission validation pass flags schema errors before the feed is sent to the marketplace

Competitive price monitoring and automated repricing rules keep your margins and buy-box position in balance without manual price table maintenance.

Pricing decisions are time-sensitive and volume-heavy — manually updating prices across channels in response to competitor moves is not operationally viable at scale. The repricing engine monitors your competitors' prices on connected channels at a configurable polling cadence and evaluates each product against a set of merchant-defined rules: maintain margin floor at X%, match the lowest price in category, stay within Y% of the buy-box winner, or hold MAP. When a rule triggers, the proposed new price is staged for review or applied automatically depending on the rule's confidence threshold. Every price change is logged with the trigger signal, the previous price, and the competitor event that drove it — a full audit trail for pricing governance.

• Competitor price monitoring on Amazon.in, Flipkart, and Meesho at a configurable polling cadence
• Rule types: margin-floor protect, lowest-in-category match, buy-box proximity, MAP enforcement
• Staged-for-review or auto-apply mode per rule based on configurable confidence threshold
• Full audit log: trigger signal, previous price, new price, competitor event, timestamp
• Bulk rule application across collections, brands, or supplier batches — not SKU-by-SKU
• Price change notifications via admin webhook or email digest for governance review

Underperforming listings surface with a prioritized fix queue, not just a status dashboard.

A dashboard that shows listings are 'unhealthy' without telling you what to fix and in what order is not useful at scale. Listing health score computes a composite score per SKU across content completeness, image quality signals, keyword coverage, pricing competitiveness, and channel compliance. Listings that fall below threshold are added to an actionable fix queue with the specific remediation required — fill this field, swap this image, adjust this price — and estimated impact ranked by revenue-at-risk. Teams can bulk-apply AI-assisted fixes from within the queue.

• Composite health score per SKU across content, images, pricing, and compliance dimensions
• Fix queue ranked by revenue-at-risk rather than alphabetical or chronological order
• Specific remediation prompts — field-level, not just 'listing is incomplete'
• Bulk-apply AI-assisted title and bullet-point improvements from within the queue
• Score trend over time to confirm that fixes are holding after channel re-indexing

Configurable loyalty schemes including paid memberships, with full receipt-level history for every earn and burn event.

Loyalty schemes vary enormously — points-only, tier-gated perks, spend-based cashback, paid subscription memberships, or combinations thereof. The loyalty engine in QuantumOS X3 supports all of these from a single configuration surface without requiring code changes per scheme. Points accrue at receipt line-item granularity (so a return removes exactly the points earned on that item), and tier evaluation runs on every qualifying event rather than at a batch cadence. Paid membership tiers (think Prime-style programs) integrate with the billing engine so access is gated on active subscription status.

• Points, cashback, and tiered perk schemes — configurable without code
• Line-item granularity on earn and burn: returns deduct exactly what was earned
• Tier evaluation on every qualifying event, not a nightly batch
• Paid membership tiers gated on active subscription via built-in billing integration
• Full receipt-level history exportable per member for dispute resolution

Build audiences from every event the platform captures — from session start to post-return survey — without a separate CDP.

CDP tools re-ingest data that already exists in your transactional system, adding latency and another reconciliation layer. QuantumOS X3 exposes a segment builder that runs directly against the event store: page views, add-to-cart, checkout steps, order events, return events, loyalty events, and support interactions are all first-class segmentation dimensions. Segments are defined with a visual rule builder supporting AND/OR nesting, time windows, event frequency counts, and calculated fields (e.g., 'average order value in the last 90 days'). Segments update continuously — there is no refresh button.

• Visual rule builder with AND/OR nesting, time windows, and frequency filters
• Segment on any platform event: session, order, return, loyalty, support, or custom
• Calculated fields: LTV, AOV, purchase frequency, days since last order, tier
• Continuous evaluation — segments reflect current state without manual refresh
• Segment size preview before saving to avoid unintentionally large batches

Email, SMS, WhatsApp, and push notifications from one canvas, with built-in deliverability infrastructure.

Managing separate sending infrastructure for email, SMS, and push means separate suppression lists, separate deliverability reputations, and no unified view of the message a customer has received across channels. QuantumOS X3 runs all channels through a single campaign canvas with a shared suppression and preference layer. Sends are triggered by platform events (abandoned cart, post-purchase, tier upgrade, point expiry) or scheduled as batches. The sending infrastructure handles DKIM/DMARC signing for email, carrier routing for SMS, and delivery receipts for WhatsApp — with bounce and complaint handling that updates the contact record automatically.

• Unified canvas for email, SMS, WhatsApp Business, and push — one suppression list
• Event-triggered sends: abandoned cart, post-purchase, tier change, win-back, and custom
• DKIM/DMARC signing and reputation monitoring built into the email infrastructure
• WhatsApp Business API integration with template pre-approval and delivery receipts
• Automatic contact-record update on bounce, complaint, or unsubscribe

An optional cross-brand loyalty wallet that enables point pooling and surfaces stored value at checkout.

For merchants operating multiple brands or franchise networks, the wallet identity layer lets customers carry a single loyalty balance across all participating storefronts. Identity is resolved by phone or email at wallet creation, and the wallet ID becomes a persistent identifier that works at web checkout, POS, and on any channel. Stored-value instruments (gift cards, credits, promotional allowances) are visible and redeemable from the wallet without the customer needing to remember which brand issued them. For marketplace operators, the wallet provides a neutral identity layer that vendors can tap into without needing direct access to customer PII.

• Cross-brand point pooling for multi-brand operators and franchise networks
• Wallet ID resolves at web, POS, and conversational channels from phone or email
• Stored-value instruments (gift cards, credits, promos) consolidated in one place
• Vendor access to wallet balance and redemption without exposure to customer PII
• Cryptographic wallet token for low-friction POS lookup without card-present requirement

Win-back, replenishment, VIP upgrade, and post-return flows built visually and version-controlled in git.

Lifecycle automations are where CRM ROI actually accrues, and they are also where most platforms let you down: visual builders that cannot express complex branching, no way to test before sending, and automation state that lives in a vendor's database rather than your own repo. QuantumOS X3 automations are defined as declarative JSON/YAML that the visual builder writes and reads — meaning every automation is version-controlled, reviewable, and deployable through standard CI pipelines. The runtime evaluates branch conditions in real time (not at cron intervals), so a customer who qualifies for a win-back flow mid-day enters it immediately.

• Visual builder writes declarative YAML — every automation is version-controlled in git
• Real-time entry evaluation, not batch cron — flows start the moment a condition is met
• Built-in A/B holdout at the automation level, not just the message level
• Pre-built templates: win-back, replenishment reminder, tier upgrade, post-return survey
• Sandbox test mode: run a contact through an automation without sending real messages

A multi-touch attribution model that reconciles back to GA4, paid platforms, and the revenue ledger.

Attribution models that live only in an email or ad platform always report higher revenue than the ledger shows — because they count attributed revenue independently and double-count customers who touch multiple channels. QuantumOS X3 attribution runs on the order ledger as the ground truth and works backward to assign credit across touchpoints (email, SMS, paid, organic, loyalty, direct). The model is configurable (last-click, first-click, linear, time-decay) and outputs a reconciled revenue-by-channel table that matches the finance team's numbers because it is derived from the same transactions. GA4 and ad platform data are pulled in as supplemental signals, not as the primary source.

• Order ledger as ground truth — attributed revenue reconciles to finance reports
• Multi-touch models: last-click, first-click, linear, time-decay — switchable without data loss
• Cross-channel credit: email, SMS, paid, loyalty, organic, and direct in one view
• GA4 and ad platform data ingested as supplemental signals for path analysis
• De-duplication of attributed revenue across channels for accurate blended ROAS

tRPC and Zod give you compile-time type safety from server procedure to client call, eliminating an entire class of integration bugs.

REST APIs with OpenAPI specs still leave a gap between the spec and runtime behavior — the spec can drift, and client code only fails at runtime. QuantumOS X3 uses tRPC as its primary API layer, which means the TypeScript types on every procedure are the authoritative contract: if the server changes a response shape, any consumer that has not been updated fails to compile, not at runtime in production. Zod schemas validate inputs at the boundary, so invalid payloads are rejected with structured errors that include field-level detail. External integrations that cannot use tRPC directly call the same procedures over HTTP with full OpenAPI documentation generated from the live router.

• tRPC procedures shared across admin UI, storefront, and external integrations
• Zod input validation with structured, field-level error responses
• OpenAPI 3.1 spec auto-generated from the live tRPC router on every deploy
• Compile-time breakage when a consumer is out of sync with a server type change
• Discriminated union response types — success and error shapes are always explicit

Every webhook delivery carries an idempotency key at the source, and any event window can be replayed from the console without re-running the originating transaction.

Webhooks fail — endpoints go down, TLS certificates expire, and deployments introduce brief unavailability. Most platforms expose a webhook log after the fact, but recovery requires understanding which events were missed and replaying them in order. QuantumOS X3 persists every outbound webhook event in a durable outbox before attempting delivery. Each event carries a content-addressed idempotency key derived from the event payload, so replays can be safely retried by receivers without double-processing. The console surfaces delivery status, response codes, and latency per endpoint, and replay can be scoped to a time window, an event type, or a specific failed delivery.

• Durable outbox: events persisted before first delivery attempt
• Content-addressed idempotency key on every event for safe replay by receivers
• Configurable retry policy: exponential backoff with configurable ceiling and jitter
• Console replay scoped by time window, event type, or individual failed delivery
• Delivery log with HTTP status code, response body, and latency per attempt

Connect product images and playable videos from PIM to SignOS quotes, proposals, WhatsApp signing links, and reserve flows.

KynetraSign/SignOS installs from Platform -> Plugins, but the operating workflow spans PIM, Media/DAM, Sell, CRM, Marketplace, Analytics, Compliance, and Integrations. PIM owns the required conversion media pack for each product: primary image, video, thumbnail, captions, QC state, and tracker binding. SignOS renders that pack inside a high-intent product decision room, then emits media and document events back to QuantumOS so operators can attribute product view, video play, document view, signature, reserve payment, and order value to the exact product asset that influenced the buyer.

• Admin menu: Platform -> Plugins for install, PIM -> Products for readiness, Content -> Media for QC
• Every product can require image, video, thumbnail, alt text, captions, and tracker binding before promoted publish
• Playable product media inside quotes, proposals, checkout confirmations, marketplace reserve flows, and WhatsApp signing
• Unified event envelope for product-room views, image views, video milestones, CTA clicks, signatures, payments, and orders
• Attribution models include first touch, last touch, time decay, SignOS assist, and product-media lift

Clone production data into a writable branch environment for safe integration testing and pre-launch rehearsal.

Staging environments that are seeded with synthetic data miss bugs that only appear with real product catalogs, real customer records, and real promotion configurations. Sandbox branching creates a point-in-time copy of production data (with PII scrubbed according to configurable rules) into an isolated, fully functional branch environment. The branch runs the same infrastructure as production — same edge functions, same queue workers, same webhook routing — so integration tests and UAT sessions reflect actual runtime behavior. Branches are cheap to create and destroy, and a diff view surfaces data changes made during the session so nothing unexpected carries forward.

• Point-in-time production data clone with configurable PII scrubbing rules
• Full-stack branch: edge functions, queue workers, webhooks, and database all active
• Branch-scoped API credentials that cannot accidentally hit production endpoints
• Session diff view showing every data change made within the branch
• One-click teardown — branches do not accumulate or incur idle cost

Per-tenant and per-user feature flags with built-in cohort analysis to validate rollouts before going wide.

Feature flags without analytics are just slow deploys. QuantumOS X3 flags integrate with the event pipeline so every flag evaluation is recorded alongside the user context, enabling cohort comparison between the flag-on and flag-off populations directly in the platform — no external experimentation tool required. Flags can target by tenant ID, user ID, user tier, geographic region, or a percentage rollout with deterministic bucketing (same user always gets the same variant). Kill-switch flags are evaluated at the edge in under 1ms, making them suitable for guarding high-traffic storefront code paths, not just admin UI features.

• Targeting by tenant, user, tier, region, or percentage rollout with deterministic bucketing
• Flag evaluations recorded in the event pipeline for cohort comparison
• Built-in A/B analysis: conversion rate, revenue per visitor, and statistical significance
• Edge-evaluated kill switches for storefront code paths — sub-millisecond flag read
• Flag history and audit log: who changed what, when, and what the rollout looked like

An in-platform assistant that drafts pages, SQL queries, email copy, and theme code grounded in your actual catalog and schema.

The copilot is positioned here as a developer-experience accelerator — a way to generate boilerplate theme code, draft tRPC procedures, or write complex segment queries without leaving the platform. It has read access to your live schema and catalog, so generated SQL and tRPC queries reference real table names and real field types rather than hallucinated ones. All tool use is audit-logged with the generating user's identity. For AI capabilities oriented toward merchandising, marketing, and autonomous decision-making, see the AI & Intelligence pillar.

• Schema-aware SQL and tRPC query generation grounded in your live data model
• Theme code scaffolding for sections, components, and edge personalization hooks
• Email and campaign copy drafts with product and segment context injected
• Audit log of every copilot interaction with user identity and generated output
• Operates within your existing role permissions — cannot access data the user cannot

Auto-generated TypeScript, Python, Go, and Ruby SDKs published on every platform release.

Manually maintained SDKs drift from the actual API within months; auto-generated ones that lag releases are almost as bad. QuantumOS X3 generates SDK packages from the live OpenAPI spec as part of the CI pipeline, so every platform release ships a matching SDK version with no manual authoring step. The TypeScript SDK is the highest-fidelity output because it is derived from the same tRPC types used internally — discriminated union responses, literal type enums, and optional vs. required fields are all preserved. Versioning follows SemVer, and the changelog is generated from the diff between OpenAPI spec versions.

• TypeScript, Python, Go, and Ruby SDKs generated from the live OpenAPI spec on every release
• TypeScript SDK preserves discriminated unions and literal types from the tRPC source
• SemVer versioning with auto-generated changelogs from spec diffs
• Published to npm, PyPI, pkg.go.dev, and RubyGems automatically
• SDK version pinned in sandbox branches so integration tests run against a stable surface

Third-party SaaS builders and system integrators get scoped API tokens, OAuth flows, webhook subscriptions, and an MCP endpoint — with a self-serve developer portal for key management and docs.

The QuantumOS X3 developer platform is a self-contained public API surface hosted at a dedicated subdomain, purpose-built for ISVs, agencies, and in-house engineering teams that build on top of the platform rather than configuring it through the admin. Token issuance follows an OAuth 2.0 client-credentials flow; each token carries a granular scope set (catalog:read, orders:write, loyalty:admin, webhooks:manage) so integrators get exactly the access their application needs without over-provisioning. The Model Context Protocol (MCP) endpoint exposes platform resources — catalog, orders, customers, segments — as typed MCP tools, enabling AI agents and copilots outside the platform to read and act on commerce data using the same RLS guardrails that govern internal AI features. The developer portal (self-serve, no sales call required) handles token creation, scope selection, webhook endpoint registration, real-time webhook delivery logs, and a live API playground. Usage metrics and rate-limit status are visible per token so integrators can debug quota issues without opening a support ticket.

• OAuth 2.0 client-credentials flow with granular scope tokens (catalog, orders, loyalty, webhooks)
• MCP endpoint exposes catalog, orders, customers, and segments as typed tools for AI agents
• Self-serve developer portal: token management, webhook registration, API playground, usage metrics
• Rate-limit headers on every response — no silent throttling surprises
• Per-token usage dashboard: request count, error rate, and quota remaining, visible in real time
• RLS guardrails apply to MCP and public API calls identically to internal platform calls

SOL ORBIT is no longer only architecture copy. It is a persisted operator console for every tenant.

The platform stores cache policies, per-control overrides, approval/action requests, freshness ledger rows, and scorecards. Super-admins can seed all tenants by industry, tune rollout percentage, save safe controls immediately, and route risky changes through two-person approval before they touch live traffic.

• 100 controls mapped across Sun, Origin/Earth, Luna/Moon, Orbit, and Eclipse
• Tenant policy documents with speed profile, industry profile, rollout, route contracts, and safeguards
• Approval queue for dangerous cache actions and private-route changes
• Freshness ledger plus scorecards for hit rate, p95, Core Web Vitals, origin pressure, invalidation lag, and approval debt
• Response headers: X-SOL-Layer, X-SOL-Profile, and X-SOL-Policy

Public HTML, JSON, search, images, and assets live as close to the shopper as the stack can safely place them.

Sun combines OpenNext KV ISR, Cloudflare Cache API hot lanes, response cache headers, immutable assets, image transformations, and per-brand static route chunks. The rule is strict: only tenant-safe, anonymous, variant-keyed content belongs here.

• OpenNext incremental cache and tag cache
• Per-PoP Cache API for hot anonymous search and storefront APIs
• Cache-Control, Cloudflare-CDN-Cache-Control, Cache-Tag, X-Cache
• Image transformation and owned CDN asset delivery
• Per-brand route chunks to avoid shipping every tenant home to every tenant

Origin is Earth: it keeps tenant, catalog, price, stock, CMS, order, and search truth durable and isolated.

Origin is not a public cache. It is the Earth layer: authoritative truth plus prepared read models such as Hyperdrive/Postgres, D1 tenant planes, product/search matviews, native KV read-through, catalog SWR, home snapshots, and root tenant maps.

• Hyperdrive/Postgres and per-tenant D1/Neon/Supabase data planes
• Product/search materialized views for list, PDP, and category reads
• Native KV read-through for theme, routing, CMS, catalog, and nav
• Home and catalog snapshots with stale-good fallbacks
• Explicit tenant/theme root maps for Worker-safe resolution

Luna is Moon: it keeps fast content honest with cache tags, exact deletes, prewarm, version bumps, and gauges.

Luna moves whenever Origin changes. Product edits, category changes, content publishes, theme changes, search configuration edits, and domain updates all map to bounded invalidation actions and prewarm routes.

• Shared CACHE_TAGS registry for publish events
• /api/x3/cache/invalidate for CF tags, KV prefixes, and exact PDP keys
• Home snapshot version bumps and route prewarm
• Server-Timing, X-Cache, and image verification gauges
• Eclipse Bypass for checkout, account, sessions, and mutations

The architecture ports public cache patterns from commerce platforms, CDNs, framework hosts, search systems, media CDNs, and database caches.

The scan maps full-page cache, subrequest cache, surrogate/cache tags, SWR/SIE, origin shield, durable edge cache, query cache, image transformation cache, search-session cache, negative-result cache, stampede locks, and prewarm into SOL ORBIT-native names and guardrails.

• Shopify Oxygen-style full-page clarity without losing X3 tenant isolation
• Fastly/Akamai-style tag invalidation mapped to CACHE_TAGS and tenant scopes
• Cloudflare/AWS-style tiered/origin-shield patterns for campaign traffic
• Algolia/Typesense-style search caching for anonymous query hot lanes
• Hyperdrive/matview read paths for database-heavy catalog tenants

Every industry gets a cache orbit tuned to its freshness risk, traffic shape, and conversion path.

Electronics needs aggressive PDP/search/image cache with precise stock and price invalidation. Food needs short TTLs for slots and serviceability. Professional services needs hot service pages and no-store lead workflows. Travel needs seasonal prewarm and D1/R2 media planes. Marketplace/B2B needs vendor and buyer-group variants.

• orbit-electronics for electronics, imaging, and dense PIM catalogs
• orbit-food-fresh for grocery, beverages, restaurants, and D2C foods
• orbit-professional-services for CA, finance, hospital, spa, and service sites
• orbit-travel for destinations, packages, journals, and campaigns
• orbit-marketplace-b2b for vendor storefronts, buyer groups, and price lists

Observe, Route, Build, Invalidate, Tune turns cache from a header trick into an operating system.

The loop makes cache reviewable. Every public route declares its layer, variants, invalidation events, and observability markers. Every publish should say what Luna moved. Every tenant should show hit rate, origin trips, invalidation lag, prewarm lag, image failure rate, and p95 TTFB.

• Observe cache state with Server-Timing, X-Cache, RUM, and image checks
• Route public traffic to Sun and private traffic to Eclipse Bypass
• Build narrow Origin/Earth read models before demand
• Invalidate via exact tags, keys, prefixes, and version bumps
• Tune TTLs, prewarm routes, and campaign mode by tenant profile

A dedicated search index built from your live PIM data delivers sub-50 ms catalog queries at any scale — no Elasticsearch license, no external service.

Kynetra Search replaces full-table scans with a purpose-built inverted index co-located in your tenant's database. At indexing time, product titles, attributes, brand names, and category paths are tokenised, stemmed, and scored for field-level importance. At query time, the engine executes against the pre-built index rather than scanning the catalog table — typically 5× faster than the baseline EAV-attribute search on catalogs of 10 000+ SKUs. The index is refreshed incrementally on every product write, so there is no batch rebuild window and no stale results. Typo tolerance, synonym expansion, and configurable field-weight profiles (boost brand name, suppress internal codes) are all set in the admin without re-indexing.

• Sub-50 ms median response time on catalogs with 100 000+ SKUs
• 5× faster than EAV-attribute full-table scan — benchmarked on live tenant data
• Incremental index refresh on every product write — no rebuild window, no staleness
• Typo tolerance and configurable synonym expansion built into the query pipeline
• Field-weight profiles: boost title, brand, category; suppress internal SKU codes
• Admin-configurable without re-indexing — changes apply to the next query

Prime observes PIM changes and customer search events to retrain relevance models continuously — with human-in-the-loop approval before any ranking change goes live.

Kynetra Prime is the orchestration meta-regent: it watches two input streams — PIM catalog mutations (new products, attribute changes, category reassignments) and customer search event telemetry (zero-result queries, click-through rates, add-to-cart from search) — and uses them to propose relevance model updates. Each proposed update is staged as a diff: which synonyms were added, which field weights shifted, which boost rules changed. A merchant can review the diff in the admin, run a side-by-side preview against live queries, and approve or reject each change. Approved changes are applied atomically without a rebuild. Prime also identifies chronic zero-result queries and suggests catalog additions or synonym expansions as actionable tasks rather than silent gaps.

• Observes PIM mutations and customer search telemetry as continuous training signals
• Proposes synonym expansions, field-weight adjustments, and boost-rule changes as staged diffs
• Human-in-the-loop: every proposed change is reviewed and approved before it goes live
• Side-by-side query preview: see how a change affects real search results before approving
• Atomic apply — approved changes take effect on the next query, no rebuild required
• Chronic zero-result queries surfaced as catalog-gap tasks, not silent failures

Vector embeddings power zero-result recovery, 'frequently bought together', visual product search, and lookalike audience building — all from one pgvector index.

Product titles, descriptions, and behavioral events are embedded on write using Google Gemini (free tier) or OpenAI, stored in pgvector columns co-located with your tenant schema. At query time the same model converts the customer's search string into a vector and runs approximate nearest-neighbor search — returning semantically relevant results even when zero keyword matches exist. The same embedding index drives four additional surfaces: a 'frequently bought together' recommendation rail computed from co-purchase session data; a 'customers also viewed' rail from item-to-item embedding proximity; visual product search (upload an image, find matching SKUs); and lookalike audience construction in segmentation. Every surface reads from one indexed table — no ETL, no separate vector database.

• Zero-result recovery: semantic ANN fallback when keyword search returns nothing
• Frequently-bought-together recommendations from co-purchase session co-embeddings
• Customers-also-viewed rail from item-to-item embedding proximity — same index
• Visual product search: upload an image, find matching SKUs via embedding distance
• Lookalike audience building: find customers with similar behavioral embeddings to a seed list
• Single pgvector index serves all five surfaces — no ETL pipeline, no external vector DB

Drafts pages, SQL, emails and theme code grounded in your live catalog, orders and customers — with audit-logged tool use.

The copilot is given read access to your tenant's schema and a curated tool set — catalog lookup, customer search, order query, and code generation — so every response cites real rows, not hallucinated examples. Each tool call is written to an immutable audit log with timestamp, caller identity, and the exact query issued. When the copilot generates a database query, it runs through the same RLS-protected connection your application uses, so it cannot read data across tenant boundaries. Draft outputs (page sections, email HTML, SQL migrations) are staged for human review before any write completes.

• Audit log captures every tool invocation with actor, timestamp, and resolved output
• Operates through RLS-gated connections — no cross-tenant data leakage by design
• Supported draft types: page sections, email HTML, SQL migrations, theme snippets
• Human-review gate before any generated content is applied to production data
• Works with Claude, GPT-4o, and Gemini via the BYO-keys routing layer

Vector embeddings power lookalike segments, recommendations and zero-result recovery on raw product and session data.

Product titles, descriptions, and customer behavior events are embedded on write using Google Gemini (free tier) or OpenAI, then stored in pgvector columns attached to your tenant's Postgres instance. At query time the same embedding model converts the user's search string into a vector and runs an approximate nearest-neighbor search against the product index — returning semantically relevant results even when zero keyword matches exist. The same embedding layer powers lookalike-audience building in segmentation and the 'customers who viewed this also bought' recommendation rail, all from one indexed table.

• Embedding providers: Google Gemini (free tier) or OpenAI, configurable per tenant
• Stored in pgvector columns co-located with your tenant schema — no external vector DB
• Zero-result recovery: falls back to semantic ANN search when keyword search returns nothing
• Lookalike segment building: find customers with similar behavioral embeddings to a seed list
• Recommendation rail powered by item-to-item embedding similarity on session event data

The same engine that drives WhatsApp/Telegram maps plain-language requests to catalog, order and support actions.

The interpreter is a graph-based node execution engine: each intent class (product search, order lookup, return request, support escalation) is a named node with typed input slots. When a message arrives — whether from the chat bot, the admin copilot, or an API caller — it is classified and its slots are filled from the text or from the session's stored context. The resolved node is then executed against the live database using the same RLS-gated query layer used everywhere else. Sharing one interpreter across the web copilot and both messaging channels means a prompt-injection fix or a new catalog action deploys once and is live in all surfaces simultaneously.

• Graph-based node engine: each intent is a node with named, typed input slots
• Covers catalog browse, order lookup, shipment tracking, return initiation, and support escalation
• Shared runtime across web copilot, Telegram bot, and WhatsApp bot — one deploy, every surface
• Slot-filling from message text or persisted session context reduces repetitive prompting
• Unrecognized intents fall back gracefully rather than producing incorrect action calls

Real-time order screening with weighted signals and allow / review / hold / block decisions on every order.

Every order passes through a weighted-signal scorer before it is confirmed. Signals include velocity (orders per IP, card, email over configurable windows), address mismatch, device fingerprint reputation, and order value relative to customer lifetime history. Each signal contributes a weighted score, and the aggregate maps to one of four dispositions: allow, review, hold, or block. Review and hold orders surface in a dedicated queue with the contributing signals and scores visible, so a human operator can make an informed decision. Thresholds and weights are configurable per tenant, not globally fixed.

• Signals: velocity windows, address mismatch, device fingerprint, LTV anomaly, payment method risk
• Four dispositions: allow, review (flag for human), hold (pause fulfillment), block (reject at checkout)
• Weighted scoring model — signal weights and thresholds are configurable per tenant
• Flagged orders land in a dedicated review queue with full signal breakdowns
• Runs synchronously in the order confirmation path with sub-100ms target latency

Resolve audiences instantly from nested rules across LTV, order history, tier, points and geography — no CDP required.

Segments are defined as nested AND/OR trees stored as JSONB, evaluated against your live transactional tables at query time — no copy to a separate analytics store required. Available dimensions span lifetime value bands, cumulative order count, loyalty tier, points balance, product category purchase history, location down to city level, and any custom event property your application emits. The segment evaluator runs as a parameterized SQL query generated from the JSONB tree, so it inherits Postgres query planning and indexes. Segments are referenced directly in campaign targeting, the recommendation engine, storefront personalization, and ad-audience exports.

• Rule tree stored as JSONB; evaluated as generated SQL — no secondary data store needed
• Dimensions: LTV band, order count, loyalty tier, points, category history, city/country, custom events
• Nested AND/OR logic with unlimited nesting depth per segment definition
• Real-time count preview before saving a segment — no wait for a batch pipeline
• Segments used directly in campaigns, personalization, recommendations, and ad-audience sync

Auto-suggests coupons, campaigns, segments and pricing — apply with one click or route to manual review.

The engine analyses your recent order, campaign, and loyalty data to surface specific, actionable suggestions: a coupon code calibrated to your current cart-abandonment rate, a win-back campaign timed to your median churn window, a segment definition that captures high-LTV customers who have not purchased in 60 days. Each suggestion is presented with the signal that triggered it and the expected impact. An operator can apply the suggestion with a single click — which creates the coupon, campaign, or segment in draft state for final confirmation — or dismiss it. Dismissed suggestions are fed back to the model to tune future relevance.

• Suggestion types: coupons, email/SMS campaigns, audience segments, and pricing adjustments
• Each suggestion includes the data signal that triggered it (e.g., cart-abandonment rate, churn window)
• One-click apply creates the asset in draft state; a second confirmation step writes it live
• Dismissals are captured as negative feedback to improve future suggestion quality
• Suggestions can be routed to a specific team member for review rather than applied immediately

Batch-generate and polish product descriptions across Claude, GPT and Gemini with per-job cost tracking.

Select any subset of your catalog — a collection, a supplier batch, or a manual list — and the enhancer submits each product to your configured model with a structured prompt that includes the product's existing attributes, category, and any brand voice guidelines you have saved. Generations run as a background job so large catalogs do not block the UI; progress and per-item status are visible in real time. Each job records token counts and estimated cost against the API key that ran it, so you can attribute spend to the product team or campaign that requested it. Outputs are staged for review; an editor can accept, edit, or reject individual descriptions before they are published.

• Supported models: Claude (Anthropic), GPT-4o (OpenAI), Gemini (Google) — per-tenant routing
• Batch jobs run asynchronously with real-time per-item progress and status display
• Per-job cost tracking: token counts and estimated spend recorded against the issuing API key
• Brand voice guidelines stored at tenant level and injected into every generation prompt
• Staged review workflow: accept, edit, or reject each description before publishing to the storefront

Bring your own model keys, set per-tenant budgets, and enforce PII blocking, injection detection and rate limits — with model routing and fallback.

You register your own OpenAI, Anthropic, and Google API keys in the platform's secrets vault; they are encrypted at rest and never logged. Each key is scoped to one or more features (e.g., only the description enhancer may use the OpenAI key), and you set a monthly spend budget per key — the platform hard-stops requests once the budget is reached. All prompts pass through a guardrail pipeline before dispatch: a PII detector redacts emails, phone numbers, and card-adjacent patterns; an injection detector scores the input for common jailbreak structures and blocks high-confidence attacks. If a primary model returns a 5xx or budget-exceeded error, the router automatically falls back to a configured secondary model rather than surfacing an error to the end user.

• Keys stored encrypted at rest; never written to logs or audit trails in plaintext
• Per-key feature scoping: restrict which platform features may consume each API key
• Hard monthly spend budgets per key — requests are blocked, not just alerted, at the limit
• PII guardrail: redacts emails, phone numbers, and card-adjacent patterns before dispatch
• Injection detection scores every prompt; high-confidence attacks are blocked at the pipeline level
• Model fallback routing: automatic failover to a secondary model on upstream errors or budget exhaustion

Latency budgets, circuit breakers, and SWR caching keep search fast under flash-sale load without degrading result quality.

Under high concurrency — flash sales, influencer drops, promotional events — a slow search response is indistinguishable from downtime from the customer's perspective. The search layer applies three independent guardrails: a latency budget (configurable per tenant, default 200 ms) that downgrades to cached results rather than queuing; a circuit breaker that opens on sustained p95 > threshold and routes to the keyword fallback index automatically; and stale-while-revalidate caching at the edge for popular query strings, serving a cached response instantly while refreshing in the background. All three states — normal, degraded/SWR, circuit-open — are visible in the admin health dashboard with the timestamp and trigger condition.

• Per-tenant latency budget: configurable target, defaults to 200 ms p95
• Circuit breaker opens on sustained threshold breach — routes to keyword fallback automatically
• Stale-while-revalidate edge caching for popular query strings — instant response, background refresh
• Single-flight deduplication: concurrent identical queries coalesce to one backend call
• Admin health dashboard shows current search state (normal / degraded / circuit-open) with trigger detail
• All guardrail transitions logged for post-incident review

One bot runtime drives both channels with a shared session and intent model — no third-party middleware tax.

The orchestrator is a single Node.js service that maintains persistent sessions for both Telegram and WhatsApp through a unified message queue. Inbound messages from either channel are normalized to a common event format before being handed to the intent interpreter, so channel-specific formatting quirks (Telegram inline keyboards vs. WhatsApp list messages) are resolved at the adapter layer, not scattered through business logic. Outbound responses are rendered into the correct wire format for each channel automatically. Running one runtime means a single deploy updates both channels; there is no separate bot codebase to keep in sync.

• Single deployable service handles Telegram Bot API and WhatsApp Business API simultaneously
• Common event schema normalizes inbound messages before intent processing — no per-channel logic
• Session state stored per-customer in Postgres, survives restarts and scales horizontally
• Supported WhatsApp providers: WATI, Gupshup, AiSensy, msg91 — switchable per tenant
• Telegram native features (inline keyboards, callback queries) and WhatsApp list messages rendered per-channel automatically

Customers ask in plain language; the interpreter maps it to catalog, orders and support actions.

The same graph-based intent engine used by the admin copilot handles inbound customer messages. When a customer types 'where is my order from last Tuesday' the interpreter extracts the intent (order lookup), resolves the time reference against their session, and issues a parameterized query against the orders table. The result is formatted as a structured reply — shipment carrier, tracking number, estimated delivery — and returned to the chat thread in under two seconds on the p95. Because the interpreter is shared with the web surface, improvements to entity extraction or new catalog actions are live in chat immediately without a separate deployment.

• Shared with web copilot: one intent graph, one deploy, every surface gets the update
• Handles time expressions ('last week', 'yesterday') resolved against customer session context
• Supported intents: product search, order lookup, shipment tracking, return initiation, support escalation
• Parameterized DB queries through RLS layer — no cross-tenant data exposure in chat
• Graceful degradation: unresolved intents escalate to human handoff rather than producing wrong answers

Browse products, check order status and track shipments without leaving the chat.

Product discovery, availability checks, price lookups, and order status queries are all handled natively in the chat thread. On WhatsApp, product results are rendered as carousel cards with image, price, and an 'Add to cart' CTA using the WhatsApp Business API's interactive message types. On Telegram, results use inline keyboard buttons for selection. Order status responses include the current fulfillment state, carrier name, and a direct tracking link. The customer's cart persists across the chat session and can be checked out via a payment link sent in-thread — no redirect to a separate browser session required.

• WhatsApp interactive carousels and Telegram inline keyboards for product browsing
• Real-time inventory availability checked at query time — no stale catalog snapshots
• Order status includes fulfillment state, carrier name, and tracking deep-link
• Persistent cart across the conversation session; checkout via in-thread payment link
• Price display respects the customer's locale and currency from their profile

Escalate to a live agent with the full conversation and customer history attached.

When the bot cannot resolve an intent, the customer requests a human, or a confidence threshold is breached, the session transitions to your support queue. The handoff payload includes the full message transcript, the resolved customer profile (name, tier, order history, open tickets), and the last attempted intent with its slot-fill state — so the support agent does not have to ask the customer to repeat themselves. The agent works from a purpose-built inbox view where they can send and receive WhatsApp and Telegram messages in one thread. When the agent marks the conversation resolved, control returns to the bot for future messages.

• Handoff triggered by: explicit customer request, confidence threshold breach, or business-rule escalation
• Payload includes full transcript, resolved customer profile, and last-attempted intent with filled slots
• Unified inbox: agent handles WhatsApp and Telegram threads from one interface
• Mid-conversation context visible to agent — no need to ask the customer to re-explain
• Automatic bot re-engagement on next customer message after agent resolves the session

Opt-in campaigns and abandoned-cart nudges with built-in consent and rate controls.

Broadcasts are sent only to customers who have opted in through a compliant double-confirmation flow — the platform tracks the opt-in event, channel, timestamp, and message ID for each subscriber. Campaign targeting uses the same JSONB-based segmentation engine as email and SMS, so you can target 'Gold-tier customers who have not purchased in 30 days' without duplicating audience definitions. The send queue respects WhatsApp Business API's messaging window rules and Telegram's bot rate limits automatically, spreading large sends over time to avoid delivery failures. Abandoned-cart nudges fire from a triggered workflow that checks cart age and purchase state before sending.

• Double opt-in flow with stored event, channel, timestamp, and message ID per subscriber
• Audience targeting reuses the same JSONB segment engine as email/SMS — no duplicate definitions
• Send queue automatically respects WhatsApp messaging window rules and Telegram rate limits
• Abandoned-cart trigger checks real-time cart and purchase state before firing — no stale sends
• Per-campaign delivery stats: sent, delivered, read, replied — pulled from provider webhooks

Chat sessions resolve to the same record as web, POS and email — one profile, every channel.

When a customer first messages on WhatsApp or Telegram, the platform attempts to resolve their phone number or Telegram user ID to an existing customer record using the same identity graph as web and POS. If a match is found, the conversation is linked immediately; if not, a lightweight verification flow creates a new unified record. From that point on, orders placed in chat appear in the customer's web account history, loyalty points earned through chat accrue to their tier, and a support agent opening the chat handoff inbox sees the same 360-degree profile as the CRM view. No manual deduplication pipeline is required.

• Phone number or Telegram user ID matched against existing customer records on first message
• Linked record shares loyalty tier, points balance, order history, and support tickets
• Orders placed via chat appear in web account and POS customer profile — one source of truth
• Lightweight verification flow creates a unified record when no existing match is found
• No separate deduplication pipeline: resolution runs synchronously at session start

Every partner event is persisted before send and retried with backoff — nothing dropped on a flaky endpoint.

Before any network call is attempted, Bridge writes the event to a Postgres outbox table inside the same transaction that produced the source event — so a crash between the business transaction and the HTTP send cannot cause a silent drop. A scheduled drain worker polls the outbox for pending rows and dispatches them to the partner endpoint. On failure, the row is marked with an error class and a next-attempt timestamp calculated using exponential backoff with jitter. The outbox row is only deleted after the partner returns a 2xx; on any other terminal state the row moves to a dead-letter partition for manual inspection.

• Outbox write is inside the same DB transaction as the source event — atomicity guaranteed
• Scheduled drain worker polls pending rows and dispatches; no message broker required
• Exponential backoff with jitter on failure — configurable base delay and max attempts
• 2xx-confirmed deletion: rows remain in the outbox until the partner acknowledges receipt
• Terminal failures move to a dead-letter partition visible in the partner observability dashboard

Onboard partners with scoped credentials and per-partner routing from a single registry.

Each partner is a record in the registry with a name, endpoint URL, authentication method (Bearer token, HMAC signature, or mTLS), and an explicit list of event types it is subscribed to. Credentials are stored in the platform's encrypted secrets vault — the plaintext key is never written to application logs or the outbox row. When the drain worker dispatches an event, it looks up the target partner's credentials from the vault and attaches the appropriate authorization header or signature at send time. Routing rules can include tenant-level overrides, so a multi-tenant deployment can point each tenant's events to a different partner endpoint.

• Per-partner authentication: Bearer token, HMAC request signature, or mTLS — configured in registry
• Credentials stored in encrypted vault; never written to outbox rows or application logs
• Subscription list controls which event types a partner receives — no over-delivery
• Tenant-level endpoint overrides: route each tenant's events to different partner URLs if needed
• Registry changes take effect on the next drain cycle — no service restart required

Scheduled drain workers flush the outbox; replay any window after an outage with full payload fidelity.

Drain workers run on a configurable schedule (default: every 30 seconds) and process pending outbox rows in batches, respecting per-partner concurrency limits to avoid overwhelming endpoints that have rate restrictions. After a partner outage is resolved, operators can trigger a replay job specifying a start timestamp, an end timestamp, and an optional event-type filter — the replay job re-enqueues the matching rows in the outbox table and the standard drain process handles delivery. Replayed events carry their original payload and the same idempotency key as the first attempt, so well-behaved partners can deduplicate without any special replay flag.

• Drain runs on a configurable schedule (default: 30 s); batch size and concurrency are tunable
• Per-partner concurrency limit respected during drain to protect rate-limited endpoints
• Replay job accepts start timestamp, end timestamp, and optional event-type filter
• Replayed rows reuse the original idempotency key — partners deduplicate transparently
• Replay is operator-triggered from the dashboard; no SQL or migration script needed

Partners pin to a payload version; upgrades are opt-in with a compatibility window.

Every event type in Bridge has a schema version. When the platform adds a field or changes the structure of an event, it increments the version and keeps the previous version available for a defined compatibility window. Each partner registration specifies the schema version it expects; the drain worker serializes the payload to that version before dispatch, not to the latest. When a partner is ready to migrate, they update their registry entry to the new version and the platform handles the difference at the serialization layer. This means platform-side schema evolution never forces a simultaneous partner-side deployment.

• Each event type carries an explicit schema version; partners pin their registration to a version
• Drain worker serializes to the partner's pinned version — not automatically to latest
• Compatibility window gives partners a defined migration period before old versions are retired
• Version upgrade is a single field change in the partner registry — no new credentials or endpoint
• Schema definitions are accessible via the partner developer portal for offline validation

Delivery rate, lag and error class broken out per partner, not just a global counter.

The observability dashboard surfaces, per partner: total events dispatched, delivery success rate, current outbox lag (oldest pending row age), and a breakdown of recent failures by HTTP status class (4xx vs. 5xx) and error type (timeout, TLS error, parse error). Time-series charts show delivery rate and lag over configurable windows so operators can correlate dips with partner incidents. Alerting rules can be set per partner on lag threshold and error-rate threshold, firing to your existing notification channel rather than requiring a separate monitoring tool.

• Per-partner metrics: dispatch count, success rate, outbox lag, and error-class breakdown
• Time-series charts for delivery rate and lag over user-selected windows
• Per-partner alert rules on lag and error-rate thresholds, routing to existing notification channels
• Dead-letter partition surfaced in the dashboard with payload preview and retry controls
• Metrics are tenant-scoped: a tenant admin sees only their partner traffic

Bridge traffic respects the same tenant boundaries and RLS posture as the rest of the platform.

The outbox table, partner registry, and credential vault are all row-level-security-protected using the same tenant GUC and policy structure as the rest of the platform's Postgres schema. A query issued in one tenant's application context cannot read outbox rows, partner credentials, or delivery logs belonging to another tenant — there is no separate access-control layer to maintain. When a drain worker processes a batch, it sets the tenant GUC before issuing any outbox query, ensuring that even background jobs cannot cross tenant boundaries. Audit logs for Bridge operations are written to the same immutable audit table as the rest of the platform.

• Outbox table and partner registry are protected by the same RLS policies as all platform tables
• Drain workers set the tenant GUC before querying the outbox — no cross-tenant row access possible
• Credential vault entries are row-scoped to tenant; no shared credential rows
• Bridge audit events written to the platform's central immutable audit log
• No separate permission model: tenant admin roles govern Bridge access the same way they govern CRM or catalog