Understanding 'Query Analysis' vs 'Tools Selection' with regards to inheritance and overrides

[ensodx-jbokkers]

When reading through systemmap.md the approach seems logical and straight forward:

2. Query Analysis

   • Item type detection
   • Relevance checking
   • Memory processing

3. Tool Selection

   • Load tool definitions
   • Evaluate tools against query
   • Route to specialized handler if matched

Subsequently router.py defines a (temporary) hierarchy:
TYPE_HIERARCHY = { "Recipe": ["Item"], "Movie": ["Item"], "Product": ["Item"], "Restaurant": ["Item"], "Event": ["Item"], "Podcast": ["Item"] }

When adding a new item type (in my case question for schema.org faqs), when setting an equal hierarchy for "Question" to inherit from "Item", it 100% will choose a tool from "Item" opposed to the tool specifically added and defined for "Question".

The only way to ensure that when type is detected as "Question" that the correct tool selected is by making "Question" inherit "Question" in the router hierarchy at which point there's no more fallback options given there's no more hierarchy.

(I realize that faq's are not items but things, but given the TODO on the type hierarchy and the scope of work (create an faq handler) I didn't want to rework the entire system to a schema.org correct implementation).

Given the need for a specific tool, is the intent to setup unique types with unique inheritance or follow the tool override pattern so for the new types override search/details/compare/ensemble?

[rvguha]

To be honest, I am really not happy with the simple type based inheritance hierarchy for tools and prompts. We need something that is more flexible ...

…

On Tue, Aug 19, 2025 at 1:47 AM Jochem Bökkers ***@***.***> wrote: When reading through systemmap.md <https://github.com/nlweb-ai/NLWeb/blob/main/systemmap.md> the approach seems logical and straight forward: 2. Query Analysis - Item type detection - Relevance checking - Memory processing 3. Tool Selection - Load tool definitions - Evaluate tools against query - Route to specialized handler if matched Subsequently router.py <https://github.com/nlweb-ai/NLWeb/blob/main/code/python/core/router.py> defines a (temporary) hierarchy: TYPE_HIERARCHY = { "Recipe": ["Item"], "Movie": ["Item"], "Product": ["Item"], "Restaurant": ["Item"], "Event": ["Item"], "Podcast": ["Item"] } When adding a new item type (in my case question for schema.org faqs), when setting an equal hierarchy for "Question" to inherit from "Item", it 100% will choose a tool from "Item" opposed to the tool specifically added and defined for "Question". The only way to ensure that when type is detected as "Question" that the correct tool selected is by making "Question" inherit "Question" in the router hierarchy at which point there's no more fallback options given there's no more hierarchy. *(I realize that faq's are not items but things, but given the TODO on the type hierarchy and the scope of work (create an faq handler) I didn't want to rework the entire system to a schema.org <http://schema.org> correct implementation).* Given the need for a specific tool, is the intent to setup unique types with unique inheritance or follow the tool override pattern so for the new types override search/details/compare/ensemble? — Reply to this email directly, view it on GitHub <#322>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABICKCVJCCUUAT37BLQFY433OLQC3AVCNFSM6AAAAACEHRE2EOVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZYG43DANZQGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ensodx-jbokkers]

I've probably chosen the most difficult type to fit into a model given the way we interface with the system and it works great although I know fully what you mean. Happy to jump on a Teams/coffee to be a sounding board if it helps...