Stop writing prompt rules. Describe what you want in plain English.

Every rules engine eventually meets a case it wasn’t built for. “Keep invoices over $1,000” works until someone needs “invoices over $1,000 from vendors we’ve used more than twice.” Now you’re editing the rule, adding a field, hoping the next weird request doesn’t show up next week.

There’s a simpler model. Describe what you want, and let the model figure out the matching.

The checkbox problem

Checkboxes feel safe. They’re explicit, auditable, predictable. They’re also frozen — they only catch what you thought to ask for at the time you built them.

Real documents aren’t checkboxes. A contract “with a non-compete clause” isn’t a field; it’s a concept spread across three paragraphs in legal-ish language. A “go-to-market strategy deck” is a vibe more than a data point. Rigid filters simply can’t see those things.

Plain language as the interface

Instead of building a filter, you write: keep documents that look like a GTM strategy deck, or invoices above $1k, or resumes for React/TS roles. The AI reads each file, scores how well it matches, and tells you why.

The upside isn’t just flexibility — it’s that your non-technical team can do this. Nobody has to learn the filter syntax. They type what they mean.

When rules still make sense

I’m not anti-rules. For repetitive, high-volume, absolutely-must-be-exact cases (tax forms, compliance flags), a hard rule with a threshold is great. The point is to stop forcing natural-language problems into checkbox cages.

Use rules where the answer is binary and permanent. Use language where the answer is “you’ll know it when you see it.” Most document work is the second one.

KIRA.id lets you keep both: plain-language criteria for the messy stuff, plus a keep-score threshold for the cutoff. See the document & data feature or talk to us about your use case.