AI that reads your real data, not a sample

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