BETA

This feature is currently BETA and requires enabling the feature flag FEATURE_FLAG_ENABLE_DYNAMIC_SCOPE_RULE_UN_17614.

Overview

Dynamic Filter Rules extend the Internal Search tooling by allowing the LLM to extract structured parameters directly from the user query at tool-call time and apply those parameters as metadata filters during document retrieval.

This enables more intelligent and context-aware retrieval flows without hardcoding filter values into the scope configuration.

Typical use cases include:

• Filtering documents by location

• Filtering documents by department

• Filtering documents by region

• Filtering documents by valid dates or effective dates

• Filtering documents by customer, project, or product line

Unlike static scope rules, dynamic filters are evaluated dynamically for every user request.

Concept

The Knowledge Scope Rules UI now supports two types of filtering:

Static Filters

Static filters are always applied exactly as configured.

Examples:

• Only include documents from a specific folder

• Only include documents with a specific metadata value

• Restrict retrieval to a fixed knowledge base segment

These rules:

• do not contain placeholders

• are compiled before the agent starts

• behave exactly like the existing scope rules functionality

Dynamic Filters

Dynamic filters allow administrators to define:

1. Parameters that should be extracted from the user query

2. Rules that use these extracted parameters to filter documents dynamically

The LLM extracts values from the user input. Those extracted values are then injected into UniqueQL scope rules and compiled into metadata filters during search execution.

This makes retrieval adaptive to the user request while still remaining fully controlled by the configured scope rules.

How Dynamic Filtering Works

Step 1 — Define Tool Parameters

Administrators define parameters that should be extracted from the user query.

Each parameter contains:

A mandatory parameter is always processed by the LLM for every user query. If the parameter is not required or cannot be inferred from the query context, the extracted value is None and the parameter is ignored during search construction. If the parameter is required, the LLM must attempt extraction. When extraction fails (for example, no location information is available), the parameter is returned as an empty string ("") rather than None.

Example:

Step 2 — LLM Extracts Parameters

When a user sends a query, the UniqueAI schema includes the configured parameters. The LLM attempts to extract matching values from the query.

Example:

User query:

Show me the London policies valid after 2024

Extracted parameters:

{
  "location": "London",
  "date": "2024-01-01"
}

Important: The parameter description is only used to guide extraction from the user query. Defining a parameter alone does NOT automatically filter documents. Filtering only happens when the parameter is referenced in a scope rule.

Step 3 — Dynamic Rules Are Evaluated

Dynamic rules reference extracted parameters using:

<toolParameters.parameterName>

At search time:

1. The extracted parameter values are injected into the rule

2. The rule is compiled into metadata filters

3. The search only retrieves matching documents

Configuration - Internal Search Tool

Narrow Knowledge Base Scope

Dynamic filtering is configured inside the Knowledge Scope settings.

Administrators can:

• Select folders and files

• Create advanced filters

• Define parameter extraction rules

• Configure dynamic metadata filtering

Default Configuration Mode

The default mode provides a structured UI for:

• Parameter definitions

• Filter rules

• Rule groups

A rule is a single filter condition, such as:

• location "equals" Zurich

• price "greater than" 100

You can define multiple rules and combine them using:

• AND → all rules must match

• OR → at least one rule must match

A group combines multiple rules into a larger condition. You can create multiple groups and combine those groups with AND/OR as well, allowing you to build more advanced and structured filter logic.

Example Configuration

The following example defines:

• a required location parameter

• an optional date parameter

The extracted values are then used inside scope rules.

Example Parameters

Example: Location Filtering

The following rule:

location equals <toolParameters.location>

means:

• location (left side) is metadata stored on documents in the knowledge base

• <toolParameters.location> is the value extracted from the user query

If:

• a document contains metadata:

{
  "location": "London"
}

and the user asks:

Show me London HR policies

then:

toolParameters.location = London

and only documents with:

location = London

will be retrieved.

Example: Date Filtering

The following rule:

validAsOf greaterThan <toolParameters.date> || 2000-01-01

means:

• validAsOf is metadata stored on documents

• the extracted date is used dynamically

• if no date can be extracted, the default value is used

Why Defaults Matter

The date parameter is optional.

If no date is found in the user query:

• the parameter is not extracted

• the fallback value is used instead

Example fallback:

2000-01-01

This ensures that the rule still evaluates safely even when the parameter is missing.

Advanced Mode

Advanced Mode allows direct editing of:

• the parameter schema

• the UniqueQL configuration

This mode is intended for advanced users.

It provides full flexibility but requires knowledge of:

• JSON schema configuration

• UniqueQL syntax

• metadata filtering structure

Example Knowledge Base Metadata

The following example shows a document stored in the knowledge base with metadata attached directly to the file.

Example metadata:

• location: Berlin

• validAsOf: 2026-04-30

These metadata fields are what the dynamic filter rules operate on during retrieval.

For example:

• the rule path location maps to the document metadata field location

• the rule path validAsOf maps to the document metadata field validAsOf

If a user query contains:

Show me Berlin documents valid after 2026

the extracted tool parameters are matched against these metadata values to determine whether the document should be retrieved.

This metadata is configured directly on the documents inside the knowledge base.

Metadata Requirements

Dynamic filters operate on metadata stored in the knowledge base.

This means:

• documents must contain the metadata fields referenced in the rules

• metadata keys must match the configured rule paths

Example document metadata:

{
  "location": "London",
  "validAsOf": "2024-01-01"
}

Without matching metadata on the documents, dynamic filtering cannot work.

Sequence Diagram Dynamic Filters