How Niso works
Niso is an interaction-based presence (IBP) — a model of online presence where the page is generated dynamically from user interaction context rather than served from a fixed template. This page covers the query pipeline, system architecture, and the constraints that govern rendering.
System model
Each user interaction triggers a governed pipeline that produces a declarative page state, instantiated using the brand's own pre-registered component library. No code is generated at runtime.
Interaction surface
Output
Session
Components
Brand control
Niso (IBP)
The page itself
Full visual page state — cards, grids, comparisons, forms
Stateful multi-turn; intent accumulates across the session
Approved Brand Components
Full control, fully tailored to the brand
Chatbot / AI widget
Sidebar overlay, separate from the page
Text thread
Stateless or short-term
Generated or generic
CSS / prompt
Query pipeline
Every user message passes through six sequential stages before anything renders.
Stage
01
Query interpretation
The raw input is parsed for intent, entities, cardinality (single item vs. collection), session context, and disambiguation signals. Output is a structured intent object used by all downstream stages.
02
Hybrid search
Retrieval runs three passes in parallel over owner-authorized sources: semantic (vector similarity), facet/filter (structured attributes), and keyword (BM25-style). Results are fused, re-ranked, and capped to authorized sources only.
03
Answer construction
A grounded answer is generated from retrieved content. Every claim carries a source_id, evidence_id, and freshness value. No value enters a component binding without a traceable source.
04
Enrichments
Supplementary objects are added alongside the core answer: related items, comparisons, upsell candidates, promotions, contextual content. Each enrichment is independently governed and can be ranked, capped, or disabled by the site owner.
05
Layout composition
Component intents, visual hierarchy, and responsive grid structure are assembled. Layout choices are constrained by brand tokens, design tokens, and accessibility rules — not free-form generation.
06
Component render
A declarative page-state document is produced and handed to the rendering layer, which instantiates components from the owner's registered library. No novel UI, no generated code — known, schema-validated parts only.
What happens
Information layer
Owner-authorized source grounding
Source policy + freshness validation
Structured metadata with source and evidence IDs
Business goals applied as ranking weights
Natural-language and structured brand guidance
Pre-approved component registry — no generated code
Brand token + design token enforcement
Accessibility constraint checking
Action gateway — permission validated before execution
State bundle stored with source, policy, and component versions
With Niso
Built-in guarantees
These aren't configurable options — they're always on. Every interaction, every page state, every action.
01
Your content, only
Every response draws exclusively from your approved sources. Nothing outside what you've authorized can appear on your site.
02
Every action is safe
Add to cart, bookings, form submissions — every action is validated against current permissions before it executes. No stale states, no unauthorized flows.
03
Component schema
Niso only renders your own component library — the ones you built and tailored to your brand. Nothing generic, nothing generated on the fly.
04
Accessible by design
Accessibility is applied during composition, not checked afterwards. Every page state that reaches your users meets your standards.