Kutup NQ

How The Runtime Works

Open NQ App

Purpose

Conversation UI, evidence-first backend

The interface is chat-like, but the runtime is not a generic chatbot. It is a staged technical workflow designed to keep answers inspectable, bounded by evidence, and stable enough for engineering and operational use.

Primary mode
Dataset-first retrieval
Language
Prompt in, answer out
On failure
Local fallback, never silent

Stage 1

Intent & Routing

The browser validates scope, normalizes the query, detects language, extracts terms, and may attach frontend ML signals. This keeps the backend payload small and targeted.

  • English and Turkish are first-class inputs.
  • Frontend ML assists ranking when available, but the system works without it.
  • Unsupported prompts are rejected before retrieval.

Stage 2

Execution Flow

1

Query preparation

The browser runs a 21 KB WebAssembly ML kernel: a trained naive-Bayes classifier routes intent (bilingual), hashed n-gram embeddings score local relevance, and a calibrated logistic model scores evidence quality. It builds a compact request with normalized text, intent hints, language context, and ML signals — no model download, works offline, instant on phones.

2

Dataset retrieval

The backend searches versioned local datasets first. Scoring favors the user's language for relevance.

3

Context enrichment

If the query is weakly matched or asks for broader context, NQ adds Wikipedia and curated industrial RSS.

  • Wikipedia fills neutral background gaps.
  • RSS is limited to approved industrial, manufacturing, and IIoT sources.
4

Evidence packet

The strongest dataset, Wikipedia, and RSS excerpts are compacted into a single reference packet. The answer layer only sees that packet. Every answer carries an Evidence Quality profile — coverage, specificity, freshness, source diversity, and calibrated confidence — so you can see how much of the question the evidence actually covers.

5

Synthesis

The LLM synthesizes the answer from the evidence packet. Helper models pre-analyze source relevance. If the remote path is unavailable, NQ returns a local evidence summary.

6

Inspectable delivery

The response arrives with runtime metadata: evidence, tools used, model status, and rate limits — all inspectable.

Stage 3

Evidence Sources

Local datasets

Versioned JSON datasets for industrial automation, protocols, process control, SQL, and ML fundamentals.

Wikipedia

Neutral background context when local datasets mention a concept but don't fully unpack it.

Approved RSS feeds

Restricted to operational sources: Automation World, ISA Interchange, MachineMetrics, Robohub, and select manufacturing blogs.

Fallback summaries

If the remote LLM is unavailable, the system formats a local response from retrieved evidence instead of failing silently.

RSS discovery hubs are not used directly. Only concrete feed endpoints enter the runtime list.

Stage 4

Runtime Visibility

  • The thread exposes which tools were involved: datasets, Wikipedia, RSS, and the answer layer.
  • Model status is inspectable, including verification outcome and fallback use.
  • Evidence cards stay tied to the answer.
  • Rate-limit info is visible when quotas become relevant.

Stage 5

Safeguards

  • Requests are validated and rate-limited before retrieval begins.
  • The answer layer stays inside provided references.
  • Remote failure triggers a local fallback instead of a dead end.
  • Runtime status is subordinate but available — failures are diagnosable without cluttering the thread.
A conversational workspace on the surface. A constrained, inspectable retrieval pipeline underneath.