Filter Predicates: Routing Data with Rules You Can Version

A Filter Predicate is a structured condition that can evaluate a value inside your pipeline’s execution context.

At the core, it’s three things:

• operator: what comparison to perform
• path: where to read the value from (JSONPath)
• value: what to compare against (raw value or another path)

Supported operators include:

`eq`, `ne`, `gt`, `gte`, `lt`, `lte`, `contains`, `startsWith`, `endsWith`, `in`, `nin`, `exists`

So yes—this is the battle-tested stuff you’ve been writing by hand for years, made explicit and portable.

Most real-world rules aren’t a single comparison; they’re combinations.

That’s why Qilin predicates can be composed via a PredicateContainer that supports:

• AND: all sub-predicates must match
• OR: at least one sub-predicate must match

That gives you readable, versionable logic without building a tiny programming language in your own codebase (because nobody deserves that fate twice).

Let’s say you only want to sync offers that are:

• active
• in the EU region
• stock > 0

A predicate container could look like this:

{
  "operator": "and",
  "subPredicates": [
    { "operator": "eq", "path": "$.FlowObjectContents.entry.status", "value": { "raw": "active" } },
    { "operator": "in", "path": "$.FlowObjectContents.entry.region", "value": { "raw": ["DE", "AT", "NL", "BE"] } },
    { "operator": "gt", "path": "$.FlowObjectContents.entry.stock", "value": { "raw": 0 } }
  ]
}

Now that rule can power multiple things:

• a filtering processor (“stop the branch if it doesn’t match”)
• a condition processor (“route to path A if true, B if false”)
• a switch-case processor (“route to the first matching case, or default”)

Same rule. Different execution semantics. Less duplication.

1) Qilin Object Filtering Processor

This processor filters based on the FlowObjectContent and a configured object type path. If the predicate fails, the branch stops – cleanly.

Example (simplified):

{
 "type": "Qilin.QilinObjectFiltering",
 "config": {
  "rules": {
   "order": {
    "name": "Only orders from Shopee",
    "predicate": {
     "operator": "contains",
     "path": "$.marketplaceName.en-GB",
     "value": { "raw": "Shopee" }
    }
   }
  },
  "ObjectTypePath": "$.FlowObjectAttributes.entry.objectType"
 }
}

2) Condition Processor

Same predicate idea, but different behavior: it doesn’t “stop”; it directs flow. Connections out of the processor declare what they expect (`true` or `false`), and Qilin activates the matching paths.

3) Switch-Case Processor

This is routing for grown-ups.

Each connection can contain a predicate condition, and Qilin will activate the matching case – plus a default connection when nothing matches.

For developers

• No more hard-coded routing rules in one-off services.
• Rules become configuration you can store, diff, review, and roll back.
• JSONPath gives you power without forcing you to write custom selectors.
• Shared logic across processors means fewer subtle inconsistencies.

For businesses (merchants + agencies)

• Filtering rules are visible and explainable.
• Agencies can build reusable “policy packs” for clients (e.g., compliance, pricing strategy, catalog hygiene).
• Merchants get safer automations: fewer accidental pushes of incomplete or forbidden data.

For investors

This is the kind of “boring feature” that scales revenue: it reduces implementation cost per customer and makes the platform more composable.

Rules are only half the story.

Next month, we’ll talk about something just as foundational: secure access. Specifically, how Qilin.Cloud is evolving API keys, roles, and permissions so teams can collaborate without handing out “master keys” to everything.

If you’ve ever said “just add another if-statement” – and then regretted it six months later – Filter Predicates are your new best friend.

They keep your logic explicit, reusable, and tame.