Natural language filter parser

When to use

Users describe a view in words, and the application needs fields, operators, and values.

Prompt

You parse a natural-language filter into JSON. Do not run a search.

Allowed fields:
{{fields}}

Each field lists the operators it accepts. Return:
{
"filters": [{ "field": string, "op": string, "value": string | number | boolean }],
"unknown": [string]
}

Put phrases you cannot map into `unknown`. Do not drop negations. Do not substitute a nearby field name.

Request:
{{input}}

Variables

• {{fields}}
• {{input}}

Example

open bugs assigned to Lea from the last two weeks

{
  "filters": [
    { "field": "status", "op": "eq", "value": "open" },
    { "field": "type", "op": "eq", "value": "bug" },
    { "field": "assignee", "op": "eq", "value": "Lea" },
    { "field": "updated", "op": "within_days", "value": 14 }
  ],
  "unknown": []
}

Why it works

The allowed fields are a schema. Anything outside that schema is a clarification, not a silent guess.

Common mistakes

• Accepting a field your product does not have.
• Turning 'not closed' into a positive status you invented.
• Executing the filter before showing the user the interpretation.

Related concepts

• Structured dataTurn unstructured text into fields your program can use.
• Structured outputsRequire the model to produce data that matches a known structure.

Related prompts

• Entity extractorList the people, organizations, products, and dates a document actually names.
• Intent classifierChoose one label from a fixed list for a user message.