ClairaClaira Help Desk

Generating Search Term Families

Voir en français

Paste a syntax instruction block into your Claira chat so it generates Nuix Discover (dtSearch) search term families ready to import from a file.

Generating Search Term Families

Claira can generate keyword lists from pleadings or issue descriptions, but it does not yet have built-in knowledge of Nuix Discover's search syntax (dtSearch), and it does not know how search term families are structured by default. This is a known gap that will be addressed in a future release.

Until then, you can close the gap by pasting an instruction block into your Claira chat before asking for search terms. The block teaches Claira two things:

  1. Nuix Discover / dtSearch document content search syntax, so generated terms are valid and effective in Nuix.
  2. The term query output format, so each line of output is a complete term query (variants joined by OR, wildcards used to collapse grammatical forms) ready to import as a search term family.

Background: what a term query looks like

In Nuix Discover, a search term family consists of a term label and a term query. The term query is a single dtSearch expression covering one concept, for example:

"civil action" OR "Law suit" OR "legal proceeding*" OR litigat* OR "class action"

Since Claira produces plain text rather than a table, this workflow targets the term query column only. You can add labels later if you want them.

Two syntax behaviours do most of the work:

  • Wildcards collapse grammatical variants. waterproof* matches waterproof, waterproofing, waterproofed, and waterproofs — there is no need to list them individually. Wildcards also work inside quoted phrases: "water proof*" matches water proofing.
  • Punctuation is not indexed. dtSearch treats a hyphen as a space, so water-proofing is indexed as water proofing. The spaced phrase form already covers all hyphenated forms; hyphen variants must never be listed separately.

So the entire waterproofing concept reduces to one term query:

waterproof* OR "water proof*"

The workflow

Step 1 — Start a Claira chat on the matter

Open the chat where you plan to ask Claira for search terms (for example, from a pleading or issue description).

Step 2 — Paste the instruction block

Paste the full instruction block below into the chat as your first message (or immediately before your keyword request). It applies for the rest of the conversation.

Step 3 — Ask for the terms

Ask as normal, for example: "From this document, generate search terms for the waterproofing defect issue."

Step 4 — Paste the output into Excel and import

Claira returns one term query per line with no labels, bullets, or commentary. Copy the full output and paste it into column A of a blank Excel file, one term query per row, with no header row. In Nuix Discover, go to Add search terms > Add terms from a file and import the file. The import accepts one column (term query only) or two columns (term label first, then term query) — if you want named families, add a label column in front before importing.

Step 5 — Review before relying on it

Sample-test the imported families. Wildcards can be overbroad (seal* also finds sealer, sealants, and anything else starting with seal), so confirm each term query behaves sensibly on the corpus before using the families for scoping or negotiation.

The instruction block

When generating search terms or search queries in this workspace, use Nuix Discover (dtSearch) document content search syntax and follow these rules:

CONNECTORS: Combine terms with AND, OR, and NOT. A bare "term NOT term" is invalid - NOT must be used as "AND NOT" or "NOT w/n". AND is evaluated before OR, so always use parentheses to group any query with two or more connectors, e.g. apple AND (pear OR orange). Never start or end a query with an operator, and never place two operators consecutively.

PHRASES: Quotation marks are not required for phrases. If a phrase contains the words and, or, or not, enclose it in straight double quotes, e.g. "bill of sale and receipt". Noise words such as "the" and "if" match any word in that position.

WILDCARDS: ? matches any single character (appl? finds apple and apply). * matches any number of characters at the start or end of a term (waterproof* finds waterproof, waterproofing, waterproofed, and waterproofs). Wildcards also work inside quoted phrases, where each term is treated as a stem ("water proof*" finds water proofing). Avoid leading wildcards (*apple) - they are too broad and may fail. = matches a single digit (==== finds 1234).

STEMMING AND FUZZY: ~ at the end of a word finds grammatical variations (click~ finds clicked and clicking). % finds misspellings or OCR errors, one incorrect character per % sign (int%%ernet finds internet and intranet); characters before the % must match exactly. Wildcards cannot be combined with ~, # (phonic), or & (synonym).

PROXIMITY: x w/n y finds x within n words of y (apple w/5 pear). x pre/n y requires x to appear before y. x NOT w/n y excludes x when it is near y. At least one side of a proximity operator must be a single word, a phrase, or a group connected only by OR - (a AND b) w/5 (c AND d) is invalid. Do not put AND or OR immediately before a proximity operator, and avoid chained proximity like a w/2 b w/5 c, which is ambiguous. xfirstword and xlastword mark the start and end of a document and can be combined with proximity operators.

PUNCTUATION: dtSearch does not index punctuation - punctuation inside a term is treated as a space. This means water-proofing is indexed as water proofing, so the quoted spaced form "water proof*" already covers the hyphenated forms. Never list hyphenated variants as separate terms. The characters % # & ? = ~ are reserved as operators and are not searchable.

REGULAR EXPRESSIONS: Enclose in straight double quotes starting with ##, e.g. "##\d{3}-\d{2}-\d{4}". \d is a digit, \w is an alphanumeric character, [abc] is a set, [a-z] is a range, (abc|xyz) is alternatives, and {n}, {n,}, {n,m} control repetition. Regex searches can be broad and slow - use them only for patterned data like ID numbers, emails, or phone numbers, and note that symbols such as hyphens, @, periods, and slashes are only searchable if the administrator has indexed them as letters.

OUTPUT FORMAT FOR SEARCH TERM FAMILIES: When I ask for search terms, output them as term queries, one term query per line. Each term query covers one concept and joins all of its variants with the OR operator. Build each term query as follows: use a trailing wildcard to collapse grammatical variants into a single term (waterproof* rather than listing waterproof, waterproofing, waterproofed, waterproofs); use quoted phrases for multi-word variants, with wildcards inside the phrase where useful ("water proof*"); list spelling variants a wildcard cannot capture as separate OR alternatives (vapor OR vapour); do not list hyphenated forms - the spaced phrase form already covers them; use parentheses and proximity operators (w/n, pre/n) where a concept is best expressed as words near each other, keeping one side of any proximity operator a single word, phrase, or OR-group. Output plain lines only - no term labels, bullets, numbering, tables, or commentary - so the list can be pasted into a single column in Excel and imported using the Add terms from a file option.

Example output

For a waterproofing defect issue, Claira's output should look like this:

waterproof* OR "water proof*"
watertight OR "water tight"
"water resistan*" OR "water repellen*"
dampproof* OR "damp proof*"
"moisture barrier" OR "moisture protection" OR "moisture control" OR "humidity barrier"
"vapor barrier" OR "vapour barrier"
seal*
impermeab* OR impervious
hydrophobic
leakproof* OR "leak proof*" OR "leakage prevention" OR "leak prevention"
"water barrier" OR "liquid barrier" OR "water exclusion" OR "water protection"
"water ingress" OR "water leak*"
waterproof* w/2 (membrane OR system OR solution OR material* OR design OR application OR method* OR technique* OR product* OR treatment OR coating OR layer OR agent OR compound OR technology OR requirement*)

Notes and known limitations

  • The instruction is per-conversation. Until the syntax ships as a built-in Claira capability, the block must be pasted into each new chat.
  • Some term queries can subsume others. The proximity query on the last line above hits a subset of the documents waterproof* already hits; families are still often kept separate for reporting purposes. Decide per matter.
  • Broad wildcards need review. Very short stems (seal*) can pull in unrelated terms; tighten or split them where needed.
  • Reserved characters (% # & ? = ~) are not searchable as literal characters in Nuix.
  • Always verify. Sample-test the generated term queries in Nuix before relying on them for scoping or negotiation with opposing parties.

Source

Syntax summarised from Nuix's official documentation: Search technology and query syntax (Nuix Discover / RMC), Nuix Discover version 10.20.005.


Need help? Contact support@claira.to

Was this page helpful?

Need more help?

Contact our support team at support@claira.to — we are here to help.