Technical Documentation
HoverBot Technical Overview
Architecture, components, data flow, and targets for production chatbot deployments, with every item labelled by maturity.
System architecture at a glance
HoverBot uses a policy-first architecture: requests pass compliance and safety gates before model inference, then flow through validation and analytics loops.
How to read the labels on this page
- Available
- Shipped and in use on every workspace. You can enable it today without talking to us.
- Pilot
- Working on design-partner workspaces. Enabled per tenant by the HoverBot team, may change before general release.
- Planned
- On the roadmap. Not in the product yet, so do not buy on the assumption it will arrive by a given date.
- Target
- A number HoverBot is built and tuned to reach. Not yet confirmed on a production customer cohort.
Components
| Function | Component | Status |
|---|---|---|
| Language model | OpenAI models via API, one tier for generation | Available |
| Embeddings and retrieval | OpenAI text embeddings stored in pgvector inside PostgreSQL, cosine similarity, top-k passages per query | Available |
| PII detection and masking | Self-hosted Microsoft Presidio analyzer, applied before text leaves the deployment | Available |
| Guardrails | Per-workspace classifiers trained on that workspace's labelled examples, plus topic rules | Available |
| Human handoff | Confidence-based escalation, threshold configurable per skill | Available |
| Session state | Redis, 24 hour expiry | Available |
| Channels | Web widget and WhatsApp Business in use; LINE, Telegram, Messenger and Slack adapters exist and run on pilot workspaces | Pilot |
| Multi-tier model routing | Selecting a cheaper or stronger model per request by confidence | Planned |
| Model fine-tuning on customer data | Not offered and not planned | None |
Hosting: one AWS region, Asia Pacific (Singapore). Subprocessors are listed in the trust center.
Architecture pipeline
Layer 1
Ingress
Auth, rate limit, policy gate
Layer 2
PII / Safety
Entity detection, redaction
Layer 3
Retrieval
Context ranking, prompt build
Layer 4
Generation
Prompt build, model call
Layer 5
Validation
Compliance, escalation
Layer 6
Audit Loop
Logging, analytics, optimization
Architecture layers
Layer 1
Ingress and policy gate
Requests enter through channel adapters, rate limiting, tenant policy checks, and auth controls.
Layer 2
PII and safety preprocessing
Sensitive entities are detected and redacted before retrieval and generation when policies are enabled.
Layer 3
Retrieval and context assembly
Grounded documents are selected and scored using intent and confidence-aware routing.
Layer 4
Generation
The prompt is assembled from the retrieved passages and the conversation state, then sent to the language model.
Layer 5
Validation and escalation
Responses pass compliance checks and can escalate to humans on low confidence or safety triggers.
Layer 6
Audit and analytics loop
All critical events are logged to support incident response and weekly optimization cycles.
Data flow
- User message -> channel adapter -> tenant auth and policy checks
- PII classifier -> redaction policy -> safe payload assembly
- Retriever -> ranked context pack -> prompt builder
- Prompt builder -> language model -> response candidate
- Response validator -> compliance checks -> escalation if needed
- Audit log + analytics events -> weekly optimization backlog
Operational targets Target
| Target | Objective | Notes |
|---|---|---|
| End-user response latency (p95) | < 2.5s | Not yet measured on a production cohort. Varies by channel network and retrieval depth. |
| Production availability | 99.9% monthly target | Objective, not a measured uptime figure. The status page records incidents. SLA terms by contract. |
| Sustained request throughput | 120 req/s target | Single region today. Not load-tested at this level on production. |
| Retriever hit rate (top-3) | > 88% | To be measured on labelled validation sets built from pilot conversations. Not yet published. |
| PII masking precision / recall | 0.97 / 0.94 target | Entity-level target. Depends on the detector's recognisers per language; not yet published per language. |
| Low-confidence auto escalation rate | 8-15% | The band HoverBot tunes thresholds toward. Above it, deflection suffers; below it, accuracy does. |
Every row is a target. None has been confirmed on a production customer cohort yet; the benchmark methodology page says how a target becomes a measured figure.
Modeling and control notes
- Retrieval-augmented generation is used for grounded domain responses.
- Confidence-based handoff to a human is the main quality control; the threshold is configurable per skill.
- Deterministic fallback and escalation paths are used for sensitive intents.
- Unanswered and low-confidence conversations are surfaced in the dashboard so knowledge gaps can be closed each week.
Models, data and evaluation
What runs today Available
- One OpenAI model handles generation for every request. There is no per-request tier selection yet.
- Retrieval-augmented generation grounds responses in the workspace's own knowledge base. Passages are retrieved by embedding similarity and included in the prompt.
- Sensitive intents (payments, fraud, PII-adjacent queries) follow deterministic rules: a scripted response or direct escalation, with no model call.
- HoverBot does not train or fine-tune language models on customer data. Conversations are sent to the provider's API for inference only, under terms that exclude API data from provider training.
- The only per-workspace training is of guardrail classifiers, on examples that workspace labels itself.
How quality is checked today Pilot
- Unanswered questions and low-confidence turns are surfaced per workspace so the team can read them and fix the knowledge base.
- Response accuracy on pilot workspaces is scored by a human reviewer against the cited source passage, on a sample. Sample sizes are small and results are not yet published.
- Guardrail behaviour is checked by replaying a workspace's labelled examples after each classifier training run.
Planned Planned
- A grounding check that compares each generated claim with the retrieved passages and reports a hallucination rate. Target once live: under 5% on documented topics.
- Labelled evaluation sets built from pilot conversations, refreshed each release, replayed before a rollout.
- Per-request model routing by confidence, to send easy turns to a cheaper model.
- Published benchmark figures with sample sizes, replacing the targets on this page.
Definitions and provenance for every published range are in the benchmark methodology white paper.
No benchmark snapshot yet
An earlier version of this page showed a table of measured accuracy, retrieval and latency figures. Those were targets presented as measurements and have been removed. Measured figures will appear here with their sample sizes once a pilot workspace closes a full measurement window.