The AI Search Configuration Assistant on Search Configuration helps admins draft or refine search categories and search.conf — the descriptor that controls indexed fields, filters, scopes, result cards, and search UI behaviour.

The assistant is evidence-driven: it reviews your current configuration, optional reference website URL(s), and your instructions, then returns a proposal for review. Nothing is saved until you click Apply proposal.

What The Assistant Can Safely Change

The assistant can propose a combined category/search bundle, including:

The assistant is conservative by design:

• It preserves existing valid configuration unless there is clear evidence or an explicit instruction to change it.
• Standard fields such as title, description, image, date, page_type, and format are assumed to exist and are not reinvented unless necessary.
• It creates scopes only from categories that already exist or category rules proposed in the same review bundle.
• It does not treat navigation labels as categories unless it can also propose executable matching rules.
• It does not edit service.conf. Apply proposal writes approved category_proposals into ingest.conf and updates search.conf together — you should not paste category rules by hand.
• Scopes that filter on a page_type with no active or proposed category are treated as orphans and must be fixed (paired with category rules) or removed before Apply is enabled.
• When you paste category names with URL/path patterns, the assistant enters category bootstrap mode: it pre-analyzes your patterns (no extra browsing), proposes rules for every listed category, and focuses the report on what will change rather than long "kept as-is" lists.
• Saved auto suggestions in auto_mappings.yaml remain available for review.

What Requires Extra Caution

Some descriptor changes can trigger reprocessing or reindexing:

The assistant shows:

• Validation status — whether the proposed descriptor passes platform validation
• Category rule dry-run — sample URL matches and warnings for broad or zero-match rules
• Diff summary — what would change compared with the current descriptor
• Reprocess impact — plain-language guidance on whether background ingest jobs are likely to be queued when you apply the proposal

Review these sections carefully before applying.

Recommended Workflow

1. Open Search Configuration and click AI Assistant.
2. Provide one or more reference website URL(s) and/or clear design instructions.
3. Optionally enable Browse additional pages when the site structure is not obvious from the homepage alone.
4. Review the returned proposal:
5. category mappings and sample URL matches
6. design summary
7. changed vs kept sections
8. validation and reprocess impact
9. warnings and test checklist
10. Click Apply proposal only when the result looks correct.
11. Use the Preview tab and representative queries to verify scopes, filters, and result cards.
12. Trigger or wait for any queued reprocessing jobs before rolling the experience out broadly.

Good Instructions To Provide

Examples that work well:

• “Create a Courses category from catalog course URLs, then add a Courses tab with delivery/faculty filters if metadata supports them.”
• “Keep the current configuration, but make News use date sorting and show date + type badges.”
• “Review our public site and propose categories/scopes for Programs, Events, and News based on URL patterns.”

Examples to avoid unless you intend a larger change:

• “Replace all categories” — this is a high-impact ingest change. Prefer asking for specific category groups and review the sample matches carefully.
• “Rename every field” — this can force a full reindex.
• “Make search look like our homepage CSS” — styling is handled in Styling / style.css, not in search.conf.

When Reindexing Is Required

You usually need reprocessing when the assistant adds or materially changes indexed field definitions, extraction rules, or category mappings.

You usually do not need reindexing for:

• adding or hiding scope tabs that filter on existing page_type values
• changing result-card layout or badges that reference existing indexed fields
• changing descriptor UI settings such as theme, Ask tab, or overlay template

If Apply queues background jobs, Airgentic will email the applying admin when those jobs complete.

Related Guides

• Site Search Overview
• Configuring Search Result Categories
• Configuring Indexed Fields
• Configuring Filters
• Configuring Search Scopes
• Configuring Result Cards and Layouts
• Testing and Previewing Site Search

Category Bootstrap Mode

When your instructions list category names with URL or path patterns (one category per block), the assistant enters category bootstrap mode:

• Your patterns are parsed and pre-analyzed before browsing.
• The report leads with Category mappings to apply and What will change.
• Long "kept as-is" lists are hidden unless you are making a small targeted edit.
• The assistant is expected to propose executable rules for every category you listed.

Example input:

People
/faculty
-profile-page

Programs
programs-of-study
/undergraduate-studies/

If you omit categories from the prompt, the assistant may still propose rules when scopes or site evidence require them, but it will not run bootstrap mode.

Orphan Scopes And Apply

A scope that filters on page_type: SomeCategory is only valid when SomeCategory exists as:

• an active manual or auto mapping in ingest.conf, or
• a category_proposal in the same review bundle.

If a prior apply left scopes in search.conf without matching ingest rules, the assistant treats them as orphan scopes. It must either:

1. add matching category_proposals, or
2. remove the orphan scopes.

Until the bundle is valid, Apply proposal stays disabled.

After a successful apply with category proposals, Airgentic writes both ingest.conf and search.conf, then queues indexing so documents receive the new page_type values.

Troubleshooting

Atomic Apply Behaviour

When you click Apply proposal:

1. The platform re-validates the bundle (descriptor + category rules + scope parity).
2. search.conf is always updated.
3. ingest.conf is updated only when the proposal includes category_proposals.
4. Stale-state checks compare file fingerprints from when the proposal was generated; if ingest.conf or search.conf changed meanwhile, apply is rejected and you must re-run.
5. Background jobs (including index when categories changed) are queued when Trigger reindex is enabled.