One assistant, many engines: how nataLlm routes your question

Ask nataLlm about a company’s latest 10-K, a crypto flow, or a chart pattern, and you get an answer signed by one assistant: nataLlm. What you never see is that three different questions just took three different paths through the system. nataLlm is NataPulse’s single proprietary assistant interface — one endpoint, one name, one response contract — and behind it sits a routing pipeline that classifies the task, picks a model profile, dispatches to one of seven specialized engines, checks the evidence, and composes the reply. The seams are deliberately invisible. That is not a limitation of the product; it is the design.

One name, one contract

Every nataLlm answer arrives in the same envelope: the assistant’s name, the answer text, the list of sources it actually used, a derived confidence value, a source count, and an opaque request identifier. Nothing else. The response never names a model, a provider, or an engine — by construction, not by convention. An anti-leak scrubber runs over the final text so that internal identifiers cannot reach the user even if an underlying component mentions one, and the assistant’s own instructions require it to present and sign itself only as nataLlm.

This is the whole contract. A client integrating nataLlm today can rely on exactly those fields being there tomorrow, regardless of what changes underneath.

Inside the pipeline

The path from question to answer has distinct, testable stages.

First, a task classifier reads the query. It is deterministic and zero-cost — keyword and entity heuristics, not a model call — so classification is fast, predictable, and reproducible. It extracts the entity (“Apple” resolves to AAPL; an unknown name simply yields no entity rather than a guess) and assigns a task type: general knowledge, fundamental analysis, SEC filings, technical/market reads, quantitative, crypto and on-chain, deep research, or coding.

Second, a model selector maps that task type to a model profile — a named configuration carrying generation parameters tuned for the job. A long SEC filing gets a long-context profile with conservative temperature; a quantitative question gets a stricter, lower-temperature one.

Third, an engine router dispatches the query to one of seven specialized engines: general, fundamental analysis, SEC filings, technical, crypto/on-chain, deep research, and coding. Each engine knows which evidence to gather — NataPulse’s curated internal data first, then, where permitted, live web retrieval — and how to frame its domain.

Finally, an answer composer writes the reply from the assembled context, and an evidence gate decides whether that reply is grounded enough to ship.

The evidence gate: refusing beats inventing

The gate is where nataLlm’s research posture becomes enforceable behavior rather than a promise. Confidence is derived from the evidence — citations found, internal data hits, web sources retrieved — not asserted by a model. For task types whose entire value is grounding in real data (fundamental, technical, SEC, crypto/on-chain, deep research, quantitative), zero evidence means a declared limit: nataLlm states plainly that it does not have sufficient data and will not invent, instead of producing a fluent guess. Users can also restrict a query to NataPulse data only, and the same rule applies to that narrower scope.

The gate also re-checks the final answer for forbidden internal terms — a second, independent layer on top of the composer’s scrubbing.

As with everything on NataPulse, the output is research evidence, not trade instructions. nataLlm summarizes what the data shows and cites where it came from; it does not tell anyone what to buy or sell.

Opacity as a design principle

Most AI products advertise which model powers them. nataLlm does the opposite, on purpose. Because no model, provider, or engine name is ever part of the product surface, the internals can change without breaking anything a user or an integration depends on. An engine can be rewritten, a model swapped for a better one, a retrieval strategy replaced — and the contract holds: same envelope, same fields, same assistant.

When the feature is disabled, the endpoint returns a plain 404 — its existence is not revealed. The interface either works fully or does not exist.

Eleven profiles, continuous tuning

The mechanism that makes swapping practical is the model-profile layer. nataLlm ships with eleven operator-editable profiles — covering routing, fundamental analysis, long-context SEC work, technical reads, deep research, quantitative math, crypto/on-chain, two coding profiles, final writing, and verification — each mapping a job to a concrete model configuration. Operators can retune the active profiles without a deploy: the database-backed configuration takes precedence, with environment and checked-in defaults as fallbacks.

The practical effect is that quality improves continuously behind a stable interface. When a better model appears for one task, one profile changes; users notice better answers, and nothing else. That trade — deliberate opacity in exchange for freedom to improve — is the core bet of nataLlm’s architecture: the assistant is the product, and everything behind it is replaceable.