Get in touch
Home OverviewVawlt Features Trust All productsEight products, one data layer
Get in touch See how routing works

Products › Vawlt

Private by architecture,
not by policy.

Purpose-trained AI, served on hardware we control

27 of 33 AI tasks are answered by models that never leave our own servers — each one separately trained for its single job. The six that go outside were measured as beyond what our own models do faithfully, and the catalogue says exactly which.

Book a demo See how routing works

Every task declares where it runs and what it does with personal data.

Demo video goes here Drop the file at assets/vawlt-demo.mp4 — 16:9, 1920×1080, H.264. Autoplays muted on loop; keep it under roughly 8 MB and 30 seconds.

A task picked from the catalogue, run end to end, with the model and latency shown.

Ask for a job.
Never for a model.

You send a task name and raw input. The engine picks the model, applies that task's privacy policy, calls it, validates the answer where the legal values are known, logs the cost against you, and returns one standard envelope. You never choose or configure a model.

  • A fixed catalogue, not a general model. 35 tasks defined, 33 served, 2 withheld. An unknown task name is a hard error rather than a best guess.
  • One model in memory, not thirty. A task-specific adapter is selected per request against a single resident model, so 27 specialised tasks cost roughly the memory of one.
  • Keep your existing client code. An OpenAI-compatible contract runs the same pipeline — change the base URL, the key, and put a task name in the model field. Standard sampling parameters are accepted and ignored rather than rejected.
  • The same input gives the same answer. Local calls run deterministically with the inference cache off. That was found the hard way: with caching on, 4 of 10 sampled tasks changed their output depending on what came before.
  • The catalogue cannot go stale. Everything that answers "what tasks exist" — the manual, the live endpoint, the console picker, even the examples inside an error message — derives from one function, and a test fails if it drifts.
Task catalogue — where each job runs
Question grounded in a transcriptIn-houseas sent
Job description from a briefIn-houseas sent
Goal with measurable KPIsIn-houseas sent
Clean contact fields from messy textIn-houseas sent
Anonymous 360 feedback summaryRouted outredacted
Performance review draftRouted outas sent
Development roadmapWithheld—
27 in-house · 6 routed out · 2 withheld. Live at the catalogue endpoint, per task, with the privacy policy attached

Five things happen
to every request.

In this order, on every call. None of them is optional, and each one is recorded.

Request in
task name
Privacy policy
per task
Model picked
adapter
Answer checked
closed set
Logged

What Vawlt does

Personal data, handled per task rather than in one sweep+
Each task declares one of two policies. Redacted — names, emails, phones, salaries and similar are replaced with typed placeholders before the model is called. As sent — the input reaches the model unchanged, because the entity data is the input; you cannot normalise a contact or summarise a deal without the names. Every response reports which happened on that call. Detection covers 14 categories, including a purpose-built salary detector that catches currency-anchored amounts, shorthand like 50k, 12 lakh or 5 crore, and bare numbers sitting near pay words. The privacy audit trail records the types of entity found and how many — never the values.
Answers checked before you get them+
Ten tasks declare a closed set of legal answers — a six-label classifier, a fourteen-action planner. After the model answers, the engine checks it and returns an error rather than passing an illegal value to your code. Nine of the ten are currently callable. Empty lists pass, because "no action needed" is a correct answer. For the CRM question-answering task there is a further guard: any person, company or email the underlying record does not support is replaced in place, leaving the rest of the answer intact.
Overload refused fast, and errors that mean something+
The in-house models are served by a single slot, so concurrent requests queue. Past a configured depth the engine returns "busy, come back in N seconds" rather than accepting the request and making you wait — with the delay computed from live queue depth against a rolling average of real service time. "You sent too much" and "we are full right now" are two distinct codes with two distinct meanings, and a saturation refusal consumes none of your allowance. One module renders every engine error for every surface, so you cannot be told "withheld" on one and "unknown task" on another.
Keys, limits and cost attribution per application+
An administrator mints a key per calling application. The raw key is returned exactly once and cannot be recovered, because only its hash is stored; keys can be listed as non-reversible fingerprints and deactivated. Rate limiting runs at 60 requests per minute per application as an abuse guard rather than a quota, shared across both request contracts, and a rejected request is not counted — so hammering does not extend the block. Cost is attributed per application, not per user or seat.
Every request logged, and a health check that tells the truth+
One row per request: the task, which model answered, tokens in and out, latency, calling application, outcome, and on a failure the error code and the upstream response body verbatim. The health endpoint checks the database, how many task adapters actually loaded against how many should have, and the queue backend. A hard dependency down returns an error; a soft problem returns success with a named warning rather than a green light. A partial adapter load is caught, because the expected count derives the same way the launcher loads them.
Quality measured on cases written to break it+
299 held-out evaluation cases across 28 tasks, deliberately written off-distribution — raw email chains, OCR noise, code-switched language, rambling four-times-length input — so they measure whether a task generalises rather than whether it matches its own templates. Three scoring tiers: deterministic structural checks, automatic grounding checks that flag invented numbers and names, and an independent model judging against the exact written rule. 87 of the 299 are a reserved holdout no promotion gate ever sees. A task with no cases reports "not evaluated" rather than a passing silence.

A task that fails testing
gets pulled, not shipped.

An engine is only trustworthy if it can be honest about its own parts. Three mechanisms make that possible.

Withheld, not quietly broken

A task that fails quality testing is added to a configuration list. It returns "exists but temporarily unavailable" and disappears from the catalogue, while its trained adapter stays untouched. Deliberately distinct from the error an unknown task gets. In use for two tasks today.

Nothing promoted without a human

A retrained candidate is evaluated against held-out cases and then waits for a person to approve or reject it. Promotion is atomic, and a candidate evaluated against a baseline that has since moved is refused as stale rather than silently rolling back a newer model.

"Approved" never means "serving" unless it is

Because adapters load at startup, an approved model is reported as staged and pending restart rather than claimed as live. The admin console holds no API key, and none may be added to it.

And what it is not, plainly. Not a chatbot — single-turn only, no conversation history, no system prompt from the caller, no streaming. Not general-purpose — a fixed catalogue, where an unknown task name is a hard error. It does not learn from use: corrections are captured and scrubbed as future training data, but the retraining step is deliberately switched off, so nothing improves on its own today. The knowledge base indexes documents but is not wired into any of the 33 tasks. Text in, text out — no video, no audio, no per-request file parsing. No confidence score is returned. 29 of the 33 tasks pass personal data through to the model, deliberately, because for those tasks the entity is the input. And there is no self-service: keys are minted by an administrator.

Sales CRMSentiment, contact extraction, deal summaries and grounded answers — nine of the engine's tasks. Business Management SystemFive lanes, one chain of records — quotation, order, delivery, invoice, collected.

Frequently asked questions

Does our data leave TalbotIQ's servers when Vawlt runs an AI task?+
For 27 of the 33 tasks, no: they are answered by models that never leave TalbotIQ's own servers, each one trained separately for its single job. Six tasks go to outside models because they were measured as beyond what the in-house models do faithfully, and the catalogue states exactly which ones.
How does Vawlt handle names, salaries and other personal data in the text we send?+
Each task declares one of two policies. Under 'redacted', names, emails, phones, salaries and similar are replaced with typed placeholders before the model is called; under 'as sent', the input reaches the model unchanged, because for that task the entity data is the input. Every response reports which policy applied on that call.
Can we use Vawlt as a chatbot or general-purpose AI assistant?+
No. Vawlt is single-turn only, with no conversation history, no system prompt from the caller and no streaming. It runs a fixed catalogue of tasks, and an unknown task name is a hard error.
Does Vawlt check the AI's output before it reaches our system?+
For the ten tasks that declare a closed set of legal answers, such as a six-label classifier and a fourteen-action planner, the engine checks the model's answer and returns an error rather than passing an illegal value to your code. Nine of the ten are currently callable.
Does Vawlt learn from or train on the data we send it?+
Not today. Corrections are captured and scrubbed as future training data, but the retraining step is deliberately switched off, so nothing improves on its own.
How do we get access to Vawlt - is there self-service sign-up or an API key portal?+
There is no self-service: an administrator mints a key per calling application. The raw key is returned exactly once and cannot be recovered because only its hash is stored, and keys can be listed as non-reversible fingerprints and deactivated.

Published 7 September 2026 · Updated 9 September 2026 · Written by the TalbotIQ team

Ready to see it?

Tell us which product you're evaluating and what your data-handling requirements are, and we'll walk you through exactly where each request goes.

hello@talbotiq.com
0 / 250
Request demo

Want to know where your data goes?

Book a 30-minute session and we'll open the catalogue with you — task by task, in-house or out, redacted or as sent.

Book a demo Talk to us

Malaysia-based team · Response within one business day · No obligation