How a Querix request moves through the platform

Every search enters through a tenant-bound endpoint. Querix validates the request, separates explicit constraints from descriptive intent, chooses the appropriate retrieval path, fetches current approved catalog rows, and returns a bounded result page.

1. 01

   Tenant-authenticated request

2. 02

   Intent and constraint validation

3. 03

   Browse or hybrid retrieval

4. 04

   Current-row hydration

5. 05

   Mapped response and next cursor

Search-ready data supplies retrieval text and filter metadata. Search indexes identify candidate IDs, while the tenant's canonical database supplies the current allowlisted fields returned to the client. The API does not expose private source columns or internal ranking payloads.

• Explicit request and UI filters override inferred intent.
• Inferred categories guide ranking rather than silently excluding alternatives.
• Current catalog rows are hydrated before the response is mapped.
• Credentials, cursors, cache state, indexes, and response mappings remain tenant-scoped.

Querix uses bounded fallbacks when an optional planning or ranking provider is unavailable. Critical serving failures return an error rather than presenting degraded quality as a normal response. Authentication, validation, rate-limit, cursor, and temporary-service errors remain explicit HTTP outcomes for clients to handle.

• Use readiness for public traffic checks and tenant health for authenticated dependency detail.
• Restart the original query when a cursor expires instead of modifying or decoding it.
• Honor Retry-After for rate limits and temporary capacity responses.
• Keep the tenant key behind the application's server-side credential boundary.