AI That Knows Your Store — Grounded in Your Real Data, Not Hallucinations

A dedicated inverted index co-located in your tenant DB — sub-50 ms on 100 000+ SKU catalogs, no Elasticsearch required.

Kynetra Search replaces full-table EAV scans with a purpose-built inverted index. Tokens are stemmed and scored for field-level importance at index time; at query time the engine reads the index directly — typically 5× faster than the baseline attribute-scan on large catalogs. The index is refreshed incrementally on every product write, so there is no rebuild window and no stale results. Typo tolerance, synonym expansion, and configurable field-weight profiles (boost brand name, suppress internal codes) are administered from the admin without triggering a re-index.

• 5× faster than EAV full-table scan — measured on live production data
• Sub-50 ms median response time at 100 000+ SKU scale
• Incremental index refresh on every PIM write — always current
• Typo tolerance and synonym expansion in the query pipeline
• Admin-configurable field weights — no re-index required
• Co-located in your tenant Postgres — no external search infrastructure

Observes PIM mutations and customer search telemetry; proposes relevance improvements as reviewable diffs — human-in-the-loop before any ranking change goes live.

Kynetra Prime is the orchestration meta-regent: it watches two input streams — PIM catalog mutations 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 reviews the diff in the admin, runs a side-by-side preview against live queries, and approves or rejects each change. Approved changes apply atomically on the next query with no rebuild. Prime also surfaces chronic zero-result queries as actionable catalog-gap tasks, turning silent search failures into merchandising opportunities.

• PIM changes and search events both feed the auto-training loop
• Every proposed update staged as a named diff — no surprise ranking changes
• Side-by-side preview: see impact on live queries before approving
• Atomic apply — approved changes take effect on next query, no rebuild
• Human-in-the-loop — nothing changes without explicit approval
• Zero-result queries converted to actionable catalog-gap tasks

pgvector co-located with your tenant schema — zero-result recovery, frequently-bought-together, visual search, and lookalike audiences from one index.

Product titles, descriptions, and behavioral events are embedded on write and stored in pgvector columns attached to your tenant's Postgres. 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 index drives four additional surfaces: a frequently-bought-together rail from co-purchase session co-embeddings; a customers-also-viewed rail from item-to-item proximity; visual product search (upload an image, find matching SKUs by embedding distance); and lookalike audience building in segmentation. No ETL, no external vector database, one indexed table serving all five surfaces.

• Zero-result recovery: semantic ANN fallback when keyword search finds nothing
• Frequently-bought-together from co-purchase session co-embeddings
• Customers-also-viewed from item-to-item embedding proximity
• Visual product search: upload image, find matching SKUs by embedding distance
• Lookalike audience building for segmentation from the same index
• Single pgvector index, five surfaces — no ETL, no external database

Latency budgets, circuit breakers, and SWR edge caching keep search fast under flash-sale load — state visible in the admin health dashboard.

Under high concurrency — flash sales, influencer drops — a slow search response is operationally equivalent to downtime. Three independent guardrails prevent this: a per-tenant latency budget (default 200 ms p95) that downgrades to cached results rather than queuing; a circuit breaker that opens on sustained threshold breach and routes to the keyword fallback index automatically; and stale-while-revalidate caching at the edge for popular query strings, serving cached results instantly while refreshing in the background. Single-flight deduplication coalesces concurrent identical queries to one backend call. All three states — normal, degraded/SWR, circuit-open — are visible in the admin health dashboard with timestamp and trigger condition.

• Per-tenant latency budget — degrades gracefully rather than queuing under load
• Circuit breaker routes to keyword fallback on sustained threshold breach
• SWR edge caching for popular queries — instant response, background refresh
• Single-flight deduplication: concurrent identical queries coalesce to one call
• All guardrail states visible in admin health dashboard with trigger detail
• Guardrail transitions logged for post-incident review

Read access to your live catalog, orders, and customers — every response cites real rows.

The copilot operates through a curated tool set — catalog lookup, customer search, order query, and code generation — scoped by the same row-level security that governs your application. It cannot read data across tenant boundaries because it uses the same RLS-gated Postgres connection your storefront uses. Every tool call is written to an immutable audit log: timestamp, caller identity, the exact query issued, and the resolved output. This means a compliance team can reconstruct exactly what the AI read, when, and why.

• Every tool invocation logged with actor, timestamp, and resolved output
• RLS-gated connections — no cross-tenant data leakage by design
• Supports page sections, email HTML, SQL migrations, theme snippets
• Human-review gate before any generated content is applied to production
• Works with Claude, GPT-4o, and Gemini via BYO-keys routing layer
• Draft state for all generated content — never auto-publishes without confirmation

pgvector co-located with your tenant schema — no external vector database, no data leaving your Postgres instance.

Product titles, descriptions, and behavioral events are embedded on write using your configured provider, then stored in pgvector columns attached to your tenant's Postgres instance. At query time the same embedding model converts the search string into a vector and runs an approximate nearest-neighbor search against the product index. Zero keyword matches no longer mean zero results — the semantic layer surfaces relevant products even when the customer misspells, uses a synonym, or describes the product by use case rather than by name. The same embedding index powers lookalike audience building in segmentation and item-to-item recommendation rails, all from one indexed table with no ETL pipeline.

• Providers: Gemini (free tier) or OpenAI, configurable per tenant
• Stored in pgvector columns co-located with your tenant schema
• Zero-result recovery via ANN fallback when keyword search returns nothing
• Lookalike audience building from behavioral embedding similarity
• Recommendation rail powered by item-to-item embedding distance
• Embedding re-indexing triggered on product update — no manual cron needed

One graph engine shared across web copilot, WhatsApp, and Telegram — deploy a fix once, it lands everywhere.

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 widget, the admin copilot, or a messaging channel — it is classified, its slots are filled from message text or from the session's stored context, and the resolved node executes against the live database via the RLS-gated query layer. Sharing one interpreter across all surfaces means a jailbreak fix, a new catalog action, or a slot redefinition deploys once and is immediately live on every channel. Unrecognized intents fall back gracefully to a clarification prompt rather than producing a spurious action call.

• Graph-based node engine — each intent maps to a node with typed input slots
• Covers catalog browse, order lookup, return initiation, and support escalation
• Shared runtime across web copilot, Telegram bot, and WhatsApp bot
• Slot-filling from message text or persisted session context
• Graceful fallback on unknown intents — no spurious action calls
• New intent nodes deploy once and activate across all surfaces simultaneously

Weighted signal scoring with four dispositions — runs synchronously in the order path at under 100 ms.

Every order passes through a weighted-signal scorer before it is confirmed. Signals include velocity windows (orders per IP, card, and email address over configurable time windows), address mismatch between billing and shipping, device fingerprint reputation, and order value relative to customer lifetime history. Each signal contributes a weighted score that the operator configures per tenant — high-velocity merchants may weight velocity signals lower than luxury merchants who optimize for precision over recall. The aggregate score maps to one of four dispositions: allow, review (flag in queue), hold (pause fulfillment), or block (reject at checkout). Review and hold orders surface in a dedicated queue showing all contributing signals, scores, and weights so the human operator can make a fully informed decision.

• Signals: velocity windows, address mismatch, device fingerprint, LTV anomaly
• Four dispositions: allow, review, hold, block
• Signal weights and thresholds configurable per tenant
• Flagged orders surface in a dedicated queue with full signal breakdowns
• Runs synchronously at checkout — sub-100 ms target latency
• Cross-tenant bad-actor signal sharing — the platform learns from every order

JSONB rule trees evaluated as generated SQL — real-time count preview, no CDP, no batch pipeline.

Segments are defined as nested AND/OR trees stored as JSONB, evaluated against your live transactional tables at query time. No secondary analytics store, no nightly ETL. 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 generates a parameterized SQL query from the JSONB tree, so it inherits Postgres query planning, indexes, and RLS. The count preview runs the same query against a LIMIT-capped sample before you save, so you see audience size in real time. Segments are referenced directly in campaign targeting, recommendation engine configuration, storefront personalization rules, and ad-audience exports to Meta and Google.

• Rule tree stored as JSONB, evaluated as generated SQL
• Dimensions: LTV, order count, tier, points, category history, city/country, custom events
• Unlimited AND/OR nesting depth per segment definition
• Real-time count preview before saving — no wait for batch pipeline
• Segments used directly in campaigns, personalization, recommendations, ad audiences
• No secondary data store — queries run against your live Postgres schema

Specific, signal-backed suggestions — coupon rates calibrated to your actual cart-abandonment rate, not generic benchmarks.

The engine analyses your recent order, campaign, and loyalty data to surface specific, actionable suggestions: a coupon discount 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 alongside the data signal that triggered it — the operator can see why the suggestion exists before acting on it. One-click apply creates the coupon, campaign, or segment in draft state for final confirmation; it does not go live automatically. Dismissed suggestions are captured as negative feedback to tune future relevance for your specific business.

• Suggestion types: coupons, campaigns, segments, pricing adjustments
• Each suggestion includes the triggering data signal
• One-click apply creates asset in draft — second confirmation goes live
• Dismissals feed back to the model to tune future relevance
• Suggestions routable to a specific team member for review
• Grounded in your data — suggestions cite your cart-abandonment rate, not industry averages

Batch-generate and polish product descriptions with per-job cost tracking against the API key that ran it.

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 existing attributes, category, and any brand voice guidelines saved at tenant level. Generations run as a background job so large catalogs do not block the UI; real-time progress and per-item status are visible throughout. Each job records token counts and estimated spend against the API key that ran it, so spend is attributed to the team or campaign that requested the job rather than pooled anonymously. Outputs are staged for review — an editor can accept, edit, or reject each description individually before any change is published to the storefront.

• Supports Claude, GPT-4o, and Gemini — per-tenant model routing
• Batch jobs run asynchronously with real-time per-item progress
• Per-job cost tracking against the issuing API key — spend attribution not pooling
• Brand voice guidelines injected into every generation prompt
• Staged review workflow — accept, edit, or reject before publishing
• Handles catalogs of any size — no UI blocking during generation

You pay AI providers at cost — no markup, no platform surcharge, no metered AI credits.

You register your own OpenAI, Anthropic, and Google API keys in the platform's secrets vault, encrypted at rest using AES-256-GCM with tenant-specific key material; they are never written to logs or audit trails in plaintext. Each key is scoped to one or more platform features — you can allow the description enhancer to use your OpenAI key while restricting the copilot to Claude only. Monthly spend budgets are set per key; the platform hard-stops requests once the budget is reached rather than sending an alert and letting overage accumulate. All prompts pass through a guardrail pipeline before dispatch: a PII detector redacts emails, phone numbers, and card-adjacent patterns; an injection scorer flags common jailbreak structures and blocks high-confidence attacks at the pipeline level. If a primary model returns a 5xx error or hits a budget ceiling, the router automatically fails over to a configured secondary model rather than surfacing an error to the end user.

• Keys encrypted at rest with AES-256-GCM — never logged in plaintext
• Per-key feature scoping: restrict which features use which key
• Hard monthly spend budgets — blocked at ceiling, not just alerted
• PII guardrail redacts emails, phone numbers, card-adjacent patterns
• Injection detection blocks high-confidence jailbreak attempts at pipeline level
• Model fallback routing: automatic failover on upstream errors or budget exhaustion