A Guide to the Koryki Query Language

Marketing managers are creative and imaginative; they often ask questions that traditional IT systems are not designed to answer.

The same applies to research, investigative work, product analytics, and many other domains where curiosity moves faster than IT-department.

Today, if a marketing manager wants to answer a complex business question, they typically have three options:

  • Wait for IT - submit a ticket and wait days or weeks for a report.
  • Learn SQL - spend months mastering technical concepts like INNER JOIN, GROUP BY, and HAVING.
  • Ask an LLM - translate natural language into SQL and hope the generated query is both correct and safe.

Each option introduces friction: time, complexity, or uncertainty.

Koryki Query Language (KQL) is designed to remove that friction.

KQL provides a structured yet readable way to express analytical intent directly, without requiring full SQL knowledge and without delegating correctness to an opaque translation step.

The cross-selling opportunity - "Gourmet Gap"

Let’s look at a concrete business problem.

The Goal: Identify customers who are highly engaged with seafood products but have not yet discovered our condiments.

Marketing Strategy: Send these customers a “Perfect Pairing” campaign featuring sauces and spices specifically designed for fish dishes.

Business Question: Find customers who have ordered more than 3 seafood items but have zero orders for condiments.

The Anatomy of a Query

KQL expresses queries in three conceptual parts: FIND, FILTER, and FETCH.

FIND — What are we looking at?

'FIND' defines the entities involved in the query.

We are interested in:

  • customers
  • orders
  • product categories

Unlike SQL, you don’t start by thinking in tables and joins.

You start by declaring the business objects you care about.

FILTER — What conditions must be true?

'FILTER' defines the business logic.

In this case:

  • customers must have ordered more than 3 seafood items
  • and must have zero orders in condiments

FETCH — What should the result contain?

FETCH defines the output shape.

For example:

  • company name
  • contact information
  • email address

This separates what you want to know from how it is computed, making queries easier to read and review.

Why this matters

KQL is designed to sit between two extremes:

  • Too low-level: SQL, where intent gets buried under syntax
  • Too high-level: natural language, where correctness becomes ambiguous

KQL aims for a middle ground: structured enough to be precise, readable enough to be understood without training.

From Intent to Execution

A key design principle of KQL is that every query should clearly separate three concerns:

  • What is being analyzed ('FIND')
  • What constraints apply ('FILTER')
  • What is returned ('FETCH')

This separation makes queries:

  • easier to read at a glance
  • easier to validate in reviews
  • easier to translate into execution plans

It also reduces one of the most common failure modes in SQL-based analytics: hidden logic embedded in joins, subqueries, and aggregation layers that is difficult to reason about without stepping through execution mentally.

A more formal perspective

The earlier example can be seen as an informal specification. KQL also supports a formal interpretation:

FIND customers c, orders o, order_details od, products p, categories cat
FILTER cat.category_name = 'Seafood' 
  AND count(od) > 3
  AND NOT EXISTS (c orders o2, order_details od2, products p2, categories cat2
      FILTER cat2.category_name = 'Condiments'
  )
FETCH c.company_name, c.contact_name, c.mail

What matters here is the consistency of structure:

  • every variable is introduced in FIND
  • every constraint is expressed in FILTER
  • every output is explicit in FETCH

Grammar intuition

At a high level, KQL follows a simple declarative structure:

QUERY := FIND <sources>
        [FILTER <expression>]
        FETCH <fields>

More intuitively:

  • 'FIND' declares the domain of interest
  • 'FILTER' applies logical constraints
  • 'FETCH' defines the output projection

This makes KQL intentionally closer to a declarative specification language than a procedural query system.

Structural completeness

KQL operates on top of a predefined semantic layer. Entity relationships are known in advance via a schema catalog and do not need to be explicitly repeated when they are unambiguous.

Structural completeness is therefore enforced by deterministic resolution rules, rather than manual join specification.

The same principle applies to aggregation: aggregate expressions in 'FILTER' and 'FETCH' define grouping implicitly, without requiring a separate 'GROUP BY' or 'HAVING' construct.

This design ensures predictable semantics while keeping the query syntax minimal and intent-focused.