Search Engine
The Search Engine page (/admin/se/instance) manages the search backends that power Semantic Navigation Sites. It is accessible from the Enterprise Search section of the sidebar.
Each Search Engine instance is a configured connection to a search backend. Semantic Navigation Sites bind to a specific instance when their cores (collections) are created. Viglet Turing supports four backends via a plugin architecture: Apache Solr (recommended), Apache Lucene (embedded), Elasticsearch, and Adobe AEM Content AI.
The first three are indexes Turing owns and writes to. Content AI is different: it queries an index Adobe owns and fills, so it is read-only (see Adobe AEM Content AI below before choosing it).
Instance Listing
The page displays all configured instances as a grid of cards (title and description). Use the "New" button to add an instance. When no instances exist, a blank state guides you to create the first one.
Create / Edit Form
General Information
| Field | Required | Description |
|---|---|---|
| Title | ✅ | Display name for this instance: shown in SN Site dropdowns |
| Description | Free-text notes about this instance |
Connection Settings
| Field | Required | Description |
|---|---|---|
| Vendor | ✅ | Backend type: SOLR, LUCENE, ES, or CONTENTAI |
| Endpoint URL | ✅ | Connection URL for the backend service |
Default endpoint URLs per vendor:
| Vendor | Default Endpoint URL |
|---|---|
| SOLR (Apache Solr) | http://localhost:8983/solr |
| LUCENE (embedded Apache Lucene) | /data/turing/lucene |
| ES (Elasticsearch) | http://localhost:9200 |
| CONTENTAI (Adobe AEM Content AI) | none: paste the Content AI base URL Adobe gave you, e.g. https://author-p1234-e5678.adobeaemcloud.com/adobe/experimental/aemcontentai-expires-20261231/contentAI |
The Content AI base URL carries both a version and an expiry date, so paste it exactly as Adobe's developer portal shows it rather than assembling it by hand.
Instance Detail Pages
After creating an instance, its detail page exposes three navigation sections.
Settings
Editing form for all fields listed above, plus a Delete instance button. An instance cannot be deleted if any SN Site cores are still using it.
Cores (Collections)
Manages the search indices (called cores in Solr terminology) within this search engine instance. Each Semantic Navigation Site locale maps to one core.
Core Listing
The list shows all cores found in the connected backend:
| Column | Description |
|---|---|
| Name | Core identifier (e.g., my-site_en_US) |
| Documents | Number of indexed documents (numDocs) reported by the engine |
| Sites | Badges showing each SN Site and locale using this core, with a country flag for quick recognition |
Cores are grouped by locale pattern: {base}_{lang}_{COUNTRY} (e.g., product-docs_pt_BR). A search/filter field at the top narrows the list by core name.
Core Actions
| Action | Description |
|---|---|
| Delete core | Permanently removes the core and all its indexed data. Blocked if the core is in use by any SN Site, the UI shows which sites and locales are preventing deletion. |
| Clear documents | Erases all indexed documents from the core without removing the core itself. Useful for a clean re-index without reconfiguring site associations. |
Create a New Core
| Field | Required | Description |
|---|---|---|
| Name / Name Prefix | ✅ | Core name or prefix |
| Locale | ✅ | Language and country (e.g., en_US, pt_BR) |
| Append locale to name | Toggle: when enabled, the locale is automatically appended to the prefix, generating the canonical name (e.g., prefix my-site + locale en_US → my-site_en_US) |
A name preview shows the final core name as you type, before saving.
Use the {site-name}_{lang}_{COUNTRY} pattern consistently. This makes it easy to identify which site and locale each core belongs to when browsing multiple instances.
System Information
Live monitoring panel for the connected backend:
| Item | Description |
|---|---|
| Status badge | UP (green) or DOWN (red): real-time connectivity check |
| Engine version | Solr or Elasticsearch version string |
| Lucene version | Underlying Lucene library version |
| Operating system | OS name and version of the engine host |
| Java version | JVM version running the search engine |
| JVM memory | Heap usage reported by the engine |
| Other properties | Additional dynamic properties returned by the engine's status API |
Adobe AEM Content AI
If you already run Adobe AEM Content AI, you are already paying for a vector index
over your published AEM content. The CONTENTAI vendor lets Turing query that index
directly, so you do not embed the same content a second time. You keep the index you
already pay for, and Turing adds the layer above it: multi-turn chat, AI agents,
skills, facets, its own analytics, and every non-AEM source Content AI does not reach.
What it can and cannot do
Turing does not own this index: Adobe fills it, using Adobe's embedding model and the schema declared in Adobe's IndexConfig. So the backend is read-only, and that is deliberate rather than unfinished:
| Works | Does not |
|---|---|
| Search, including semantic + keyword together | Indexing content from Turing or a connector |
| Facets (from the source's filterable fields) | Creating, clearing or deleting a core |
| Sorting and paging | Adding or changing fields in the schema |
| Document count and live status | Deleting documents |
A write attempt fails with a message saying so rather than silently doing nothing, so you cannot end up believing a document was published when it was not. Do not point a connector at an SN Site backed by Content AI. Publish that content in Adobe (AEM publish, or Content AI's own acquisition service) and let Turing query it.
Setting one up
- In the Adobe Developer Console, add the "AEM Content AI" card to your project and note the base URL and the credential it issues.
- Create a Search Engine instance here with Vendor
CONTENTAIand that base URL. - Set the credential and switch the backend on:
turing.content-ai.enabledplusturing.content-ai.token(orapi-key). See Configuration Reference → Adobe AEM Content AI. - Tell Turing which Adobe content source each site queries:
turing.content-ai.sources.<site-name>. Without a mapping, the site's core name is used as the source name. - Bind an SN Site to the instance and search.
What to expect
- Relevance is Adobe's. The embedding model and the ranking are theirs, so Turing's own hybrid ranking and reranker settings do not apply.
hybrid,vector-boostandfulltext-boostare the whole of the tuning available. - Pages are shallower. Adobe returns at most 50 results per page and offers no way
to jump to a page, so deep pagination is bounded by
max-page-walk; beyond it a page comes back empty (the total is still correct). - Facets need filterable fields. A facet field the Adobe source does not carry as filterable simply returns no values.
- It is a hard dependency of the answer. Search on that site stops working if the
Content AI subscription lapses or the credential is revoked. System Information
reports
DOWNwhen no credential is configured.
"My Content AI site returns nothing"
Adobe answers a query naming a source it does not have with zero results, the same answer as a source that exists and matched nothing. Turing therefore checks your configuration against Adobe rather than letting you guess:
- Instance detail → System Information lists the content sources your Adobe tenant
actually has, next to the mapping you configured. A source name that does not resolve
is marked
(NOT FOUND). Start here. - The first empty result on a site logs a warning naming the source you asked for and the ones available, so the answer is in the log even if nobody opens the console.
- Cores (Collections) lists the real source names, so you can copy one instead of
typing it. Document counts read
-1there: Turing does not own these indexes, and a0would look like "this source is empty".
Three more settings fail the same quiet way, and are reported in the same warning:
| Setting | If it is wrong |
|---|---|
source-type | The search names the type, so it resolves against the wrong index |
vector-space / lexical-space | Adobe silently falls back to its default space, so relevance is not what you configured |
| A facet field | If the Adobe source does not mark that field filterable, the facet renders with no values |
If System Information says sources: unavailable, the credential or the endpoint URL
is the problem, not the source name.
Grounding an AI answer on a Content AI site
Adobe holds the embeddings, so Turing's own vector store is empty on such a site and the RAG chat reports itself unavailable (correctly) rather than answering from nothing.
What does work is a Custom Tool calling turingSearch.sn(...): it
queries the Content AI index and, with turing.content-ai.include-chunks enabled, each
hit's content is the passage Adobe matched rather than the whole AEM page. That is
better grounding than a truncated page body, and it is the only sub-document grounding
available on a federated site, since Turing cannot re-chunk an index it does not own.
The vectorless copilot needs no embeddings: it turns prose into a grounded query over the site's declared fields and answers strictly from the matched rows, which makes it the grounded-answer path that suits a federated index. It runs through the DSL API, which serves a defined subset of the query syntax on Content AI.
Plugin Architecture
Turing uses a plugin architecture to support multiple search backends behind a unified interface. The active plugin is resolved at runtime based on the vendor configured per instance. If a vendor is unrecognised, the factory falls back to Solr.
For the full interface reference (all methods across search, index management, schema management, and document operations) and instructions on implementing a new backend, see Developer Guide → Search Engine Plugin Architecture.
Protections
| Scenario | Behaviour |
|---|---|
| Delete core in use | Blocked: the UI displays a list of SN Sites and locales currently using the core |
| Delete instance in use | Should be avoided: removing an instance with active sites will break indexing and search for those sites |
Repository-level caching is enabled for search engine instances to avoid repeated database reads during high-frequency searches.
Related Pages
| Page | Description |
|---|---|
| Administration Guide | Full console reference |
| Field Manifest & Schema-as-Code | Declaratively provision/evolve a site's field schema; field-coverage observability |
| Semantic Navigation | How SN Sites use cores and search engines |
| Architecture Overview | Solr, Elasticsearch, and Lucene in the system architecture |
| Configuration Reference | Solr and Elasticsearch timeout settings in application.yaml |
| Configuration Reference → Adobe AEM Content AI | Credential, source mapping and query settings for the CONTENTAI vendor |
| AEM Connector | Indexing AEM content into Turing, the alternative to federating to Content AI |