Conversation

1) Open Setup (phones) · 2) Tap Load Model · 3) Chat fully on-device via CPU-WASM or WebGPU.
Architecture: LLM ↔ SPARQL closed loop

The pipeline runs entirely client-side via Qualia's native inference stack (gguf_bridge → CPU-WASM or WebGPU decode). No third-party llama.cpp bindings. P64/GGUF only — not LiteRT-LM. On phones prefer SmolLM2-360M.

[ Human Input ]
       │
       ▼
┌──────────────────────┐
│ Local P64 / WASM LLM │ ◄── System prompt with QualiaDB ontologies
└──────────┬───────────┘
           │ Emits SPARQL query or JSON-LD
           ▼
┌──────────────────────┐
│  SPARQL Engine       │ ◄── QualiaDB :4242 | Wikidata | Both
└──────────┬───────────┘
           │ Returns semantic bindings
           ▼
┌──────────────────────┐
│  SmolLM2 / Llama 3   │ ──► Natural language answer + JSON-LD node
└──────────────────────┘

If the SPARQL query fails validation, the error is fed back to the model for self-correction (up to 3 retries). Token streaming uses inferWasmAsyncMeasured; CPU-WASM runs in a dedicated worker with packed SIMD128 Q8 kernels, while WebGPU yields around asynchronous device work.

COI note: The COI service worker at the top of this page injects Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp headers on reload, enabling SharedArrayBuffer for multi-threaded WASM inference.