Search, Filters, Infrastructure
This October 2026 release is a major step making Coreon’s graph backend more secure, more scalable. With this release the new search engines are productised, filters have been significantly improved, and term recognition gains tunable precision for different workflows.
Fast Search, Fast Term Recognition
Available as a tech preview already since January we were this spring and summer revisiting couple of technological decisions to make our search engines even faster and the term recognition (so-called entity detection in more general NLP words) more tolerant. An update to the tech preview from January:
- Search – the “normal” query for a word, a term:
We replaced Apache Solr with tantivy. The new engine runs directly inside the application — no separate Java process, no extra server. The result is extremely fast responses with a very low resource footprint. - Term Recognition – the analysis of a sentence to identify terms that occur in there:
We replaced Apache Solr here, too, namely with an own-developed letter-trie based index.
Why a custom term recognition / entity detection algorithm? Instead of sticking to Apache Solr’s term-tagging capabilities. Well, there are two very different use cases to be covered:
- Translation / Terminology Checking: Detect terms in text to guarantee that the desired, approved terms are used in the source or target languages. Known from and supported within Trados Studio, memoq translation software.
In this context the source sentences are usually in very good quality (no spelling errors, style reviewed) etc. Yes, inflection, morphology needs to be resolved – but that is then usually it. No surprises. - Chatbot-like interaction, spontaneous utterances: Spot terms in a user’s typed snippets to identify named entities, often for further prompting to LLMs.
In this context the input is usually in a, say, rather mediocre quality (typos, words swapped, spaces or hyphens inserted or dropped) etc …
In both situations the response must be extremely fast (< 200 ms), precision relatively high (do not find too much noise), while e.g. typos should be in the second case more tolerantly treated than in the first case. The custom development of a letter trie based index did resolve the two challenges we were faced with.
New in this release: the recognition API now exposes match options that let you control exactly this trade-off. Strict matching for translation workflows where precision matters, tolerant matching for chatbot scenarios where recall matters more — configurable per request.
And – of course – both search methods support performant filtering and querying within selected branches of the knowledge graph.
Overall, months of research and development went into this, to integrate Coreon as a single source of a truth, as a backbone into GenAI / LLM and other enterprise solutions. A live connection to Coreon makes the querying software solution benefit from the always up-to-date live data and particularly Coreon’s smart search and term annotation for many languages.
Do the new search engines only work in upcoming Coreon 2 – or also in Coreon 1 (the legacy UI)?
Answer: under the hood, they work for both UIs. Concretely:
- Coreon 2 directly “goes” to the new Search (and benefits further from various performance optimisations)
- Coreon 1 as well as the CAT tool plugins using the term recognition continue to send calls against the legacy APIs. These are now internally routed through the new engines. We are already working on updating the plugins, so that they soon connect directly to the new term recognition engine.
- The recognition endpoint is now also available via
GET— making it easier to integrate into CAT tools and other clients that prefer simple URL-based requests.
API: Search by Classification Code
The API is equipped with a further new search option that lets you find concepts by their classification code (breadcrumb path in the knowledge graph). This is particularly useful for large, deeply structured terminologies where you already know the domain area you are looking for — for example, searching for all concepts under a specific branch like Medicine › Anatomy › Cardiovascular. The search supports both exact and prefix matching.
Term-as-you-type Improvements
By leveraging the new Search we also improved the algorithm of the so-called term-as-you-type behaviour (also referred to as quick search, auto-complete). In particular the matching no longer requires that the order of the tokens queried for must be identical to the stored term. This is particularly helpful for multiword terms.
Filters
Filtering logic has received a significant focus in this release:
- Concept vs. Term scope works as expected: “concept” scoped filter rules now no longer behave like a “term” scoped filter in the Terms list, but as intuitively expected. Concept-level filters properly restrict which concepts appear, while term-level filters act on the terms themselves.
- Concept filter applied during search: When a concept filter is active, search results now respect it correctly.
- Markup is now ignored: Filtering on terms and text values no longer trips over formatting markup. A search for “Atlantic” finds the term regardless of whether it carries bold or italic formatting in the stored value.
- Special characters in filters: Filter conditions containing characters like
. * +are now treated as literal text, not as pattern syntax. - ‘Exists not’ works on the Terms list: The “exists not” operator for properties now properly applies when viewing the Terms list, not only for concepts.
- Sort order parity (API2 only): The filter set index now sorts consistently between the Coreon 1 and Coreon 2 interfaces.
Import / Export
- Performance: Imports run significantly faster, especially for large datasets. Search index updates during import are now batched rather than processed one by one.
- Large files: ZIP imports are now processed as a stream, so even very large import archives no longer cause memory issues.
- Data integrity: A rare issue where property types could be corrupted during XLSX imports has been fixed.
- Export: various performance improvements
Faster in Various Aspects
Beyond the new search engines, this release includes many optimisations that make the everyday experience noticeably faster:
- Terms list: Loading a page of terms now requires far fewer database queries, making the Terms list respond much faster — particularly in repositories with many languages.
- Concept navigation: Opening a concept, navigating the hierarchy, and browsing branches all benefit from new caching that avoids re-computing data that has not changed.
- Deep links survive sign in: When you follow a direct link to a concept and need to log in first, you are now taken to that concept after sign in — instead of landing on the start page.
- Limit search results (API only): A new
maxHitsparameter lets you control the number of search results returned, useful for integrations that only need the top matches.
Updates and Security Hardenings
Besides above improvements and the two new search engines a lot of internal updates and library liftings have happened. These accompany the recent update of the authentication module and further prepare us for an ISO 27001 certification.
- ICU based sorting (now using established
libicu) - A security fix ensures that administrative metadata on nested properties is no longer visible to regular users
- Configuration changes to a repository are now also recorded in an audit trail
- Middleware components lifted to current versions (Ruby 3.4, Rails 8.1, Mongoid 9.0)
Enjoy these product improvements. And – as you may know – we are making big progress also in the beta phase of Coreon 2!
