A simple search box works for casual browsing. Type “landscape” and see landscapes. But a power user managing ten thousand AI-generated assets needs precision: “show me all ComfyUI outputs using the SDXL model with a CFG scale above 7, generated in the last two weeks, that contain the word ‘cyberpunk’ in the prompt.” A keyword search cannot express this. A search grammar can.
Part of our AI-Native DAM Architecture
A search grammar defines a structured syntax for expressing multi-dimensional queries against the rich metadata that AI generation tools produce. It sits on top of the hybrid search engine, translating human-readable query expressions into structured filters combined with semantic search. The grammar makes the search box as powerful as the database — without requiring the user to write SQL.
The Forces at Work
- Metadata richness exceeds UI capacity: A ComfyUI generation has dozens of searchable parameters — model, sampler, scheduler, CFG scale, steps, seed, resolution, LoRAs, custom node configurations. No faceted search UI can expose all of these without becoming overwhelming. A grammar allows users to query any field without requiring a dedicated UI control for each one.
- Query complexity varies by user: Casual users search by visual similarity or simple keywords. Power users construct complex boolean queries with field-specific filters, range expressions, and negations. The grammar must serve both — simple queries should work without syntax knowledge, while complex queries should be expressible for those who need them.
- Cross-tool queries require abstraction: The same concept has different field names across tools. A “model” query should work whether the asset was generated by ComfyUI (checkpoint file path), Midjourney (version flag), or DALL-E (model name). The grammar must operate on the normalized schema, not tool-specific field names.
- Discoverability matters: A grammar is useless if users do not know it exists or cannot learn it. The search interface must provide progressive disclosure — showing basic search by default, suggesting grammar features contextually, and offering autocomplete for field names and common patterns.
The Problem
Without a grammar, users are limited to what the UI explicitly exposes. Most DAM systems offer a search box (keywords only) and a panel of filters (a fixed set of dropdowns and sliders). Adding a new searchable dimension requires building a new UI control — a dropdown for tools, a slider for CFG scale, a date picker for creation time. As the number of searchable metadata fields grows, the filter panel becomes unwieldy, and obscure-but-valuable fields never get UI controls at all.
Search Approaches for Rich Metadata
| Approach | Expressiveness | Discoverability |
|---|---|---|
| Keyword search box | Low — text matching only | High — everyone knows search boxes |
| Faceted filter panel | Medium — limited to exposed fields | Medium — users must find the right filter |
| SQL/API query | High — any field, any condition | Very low — requires technical knowledge |
| Search grammar | High — field filters + semantics | Medium — learnable with autocomplete |
A search grammar is the middle ground between the simplicity of a keyword box and the power of a database query. It gives power users precision without requiring them to be database administrators, and it gives the system a way to expose every metadata field without building a UI control for each one.
The Solution: A Composable Query Grammar
The search grammar defines a set of composable expressions that users type directly into the search box. Each expression targets a specific metadata dimension, and expressions combine with boolean logic to form complex queries.
Field-Specific Filters
The grammar supports field:value syntax for querying specific metadata dimensions. The field names map to the normalized schema, so they work across all tools. A query like “tool:comfyui model:sdxl” filters by generation tool and model checkpoint regardless of how each tool stores this information internally.
Range Expressions
Numeric and temporal fields support range syntax. CFG scale, step count, seed value, resolution, and creation date all accept range expressions. This enables queries like “steps:20..50” (twenty to fifty steps) or date range filters that integrate with temporal search. Range expressions are essential for the kind of parameter exploration that power users perform — finding all images generated with high step counts, or all outputs from a specific seed range.
Boolean Composition
Expressions combine with AND (implicit between terms), OR (explicit), and NOT (prefix negation). This enables precise queries: “tool:comfyui model:sdxl NOT tag:draft” finds all SDXL generations from ComfyUI that are not tagged as drafts. Parenthetical grouping allows complex boolean logic for users who need it, while simple queries work without any explicit operators.
Semantic Fallback
Any term that does not match the grammar's field:value syntax is treated as a semantic search query. This means a query like “tool:comfyui dramatic sunset over ocean” combines a structured filter (ComfyUI only) with a semantic search (images visually or conceptually matching “dramatic sunset over ocean”). The structured filters narrow the search space, and the embedding similarity finds the matches within that space.
Progressive Disclosure in the UI
The search box starts simple — type anything and get results. As users type, autocomplete suggests grammar features: typing “tool:” shows a list of available tools, typing “model:” shows known model names. Syntax highlighting in the search box visually distinguishes structured expressions from free-text terms. A help icon explains the grammar with examples. Power users learn the grammar progressively through use, not documentation.
Consequences
- Unlimited query expressiveness: Every metadata field is searchable without requiring a dedicated UI control. When the system ingests a new tool or metadata format, the grammar automatically exposes its fields — no UI changes needed.
- Learning curve: A grammar has inherent learning overhead. Users who never discover the grammar will be limited to keyword search and whatever faceted filters the UI provides. Progressive disclosure mitigates this, but some users will never use structured queries. The system must deliver good results for simple queries even without grammar features.
- Parser complexity: The grammar requires a parser that handles syntax errors gracefully. Malformed queries should degrade to keyword search, not show error messages. The parser must be fast enough to run on every keystroke for autocomplete without perceptible latency.
- Grammar evolution: As new metadata fields appear and new query patterns emerge, the grammar must evolve without breaking existing queries. This requires careful versioning of grammar syntax — new features must be additive, never changing the meaning of existing expressions.
Related Patterns
- Hybrid Search describes the search engine that the grammar targets — combining structured filters with semantic similarity.
- Temporal Search provides the time-dimension expressions that the grammar includes as range types.
- The Normalization Pipeline produces the canonical field names that the grammar exposes to users.
- Embedding Space powers the semantic fallback for free-text terms within structured queries.