EXA Answer Filter

Pilot

CZ, SK

Know whether your AI's insurance answer is backed by the insurer's documents.

It takes a question and an answer someone else already wrote, and returns OK, WARN or FAIL with a faithfulness and a confidence score. It never writes the answer, it only judges one. Pilot, on Czech and Slovak insurer documents.

Pilot. It runs, and it is not yet a self-serve product.

Talk to us about delivering this Connect it to your AI

Where it runs today: your team reads it in the Emable workspace, signed in and your own systems call it over the REST API.

What changes

Who inside your organisation is better off, and what they can show for it.

AI product lead at an insurer
Every draft your assistant writes comes back OK, WARN or FAIL before it reaches a screen. You route WARN and FAIL to a person and let OK through.
check_answer returns trust_state as OK, WARN or FAIL, with faithfulness_score and confidence_score. Source: capability output schema in the emable capability catalogue.
Compliance lead at an adviser network
A verdict names the documents the answer rests on. A review starts from those sources instead of from an opinion about the model.
The response carries a source list, and the verdict reflects the insurer documents indexed at the time of the call.
Head of the contact centre at an insurer
An answer typed by a person goes through the same check as an answer written by the model. The filter does not care who wrote it.
Only question and answer are required inputs. Insurer, sources, country and product line are optional. Source: capability input schema in the emable capability catalogue.
Engineering lead who owns the retrieval stack
You pass the sources your own retrieval returned alongside the answer. You get back whether the answer stayed inside them.
The input accepts up to 50 source strings with the answer, plus insurer and product line. Source: capability input schema.
Head of advice at a Czech or Slovak distributor
The check is bounded to the markets it covers. A Slovak answer is judged against Slovak documents, and an uncovered market is refused rather than guessed.
Countries CZ and SK, and coverage follows the indexed insurer corpus. Source: manifest countries and limitations, the emable capability catalogue.

Two ways to get it

Have it delivered, or let your own AI call it.

As a service

Send us a batch of answers your assistant or your advisers already wrote. We judge each one against the indexed insurer documents. You get the verdict per answer, the sources behind it, and the places where the answer left them. We then agree which documents the corpus should hold for your market and your product lines. We wire the check into the point in your answer path where it belongs, before the reply leaves. This is a pilot on Czech and Slovak insurer documents, so write to us first about your market, your product lines and your document set. If your market is not covered, we will say so instead of running the check.

Tell us what you need

One message, no form. We answer with what it would take.

Through your own AI

Not yet, and the page says so plainly. The tool is declared as check_answer with its full input schema. Its runner is a stub. emable-api does not serve /v1/exa/check, so an MCP client receives not_executable_via_mcp and is charged nothing. The questions above are what it is built to answer once it opens, not what it answers today. If you need a wired check on an already-written answer now, validate_answer does execute and judges against the Czech legislation and ethics matrix. That is a different check, so read what each one covers before you swap them. Write to us and we will tell you when the filter opens.

Connector: https://api.emable.ai/mcp
Tools it adds: check_answer

Ask for access How the connector works

What your AI can answer

Connect it once, and your assistant answers these.

Questions in your own words, each one landing on a published tool. Ask us and we answer the same ones for you.

1Is this answer actually supported by the insurer's documents, or did the model fill in the gap? (check_answer)?check_answer
2Can we show this answer to a client, or does a person need to read it first? (check_answer)?check_answer
3Why did this answer fail the check? (check_answer)?check_answer
4Which documents does this answer rest on? (check_answer)?check_answer
5How sure is the check itself about this verdict? (check_answer)?check_answer
6Does this answer hold up in Slovakia, not only in Czechia? (check_answer)?check_answer
7Does it still hold when I say which insurer and which product line it is about? (check_answer)?check_answer
8Our retrieval returned these sources. Did the answer stay inside them? (check_answer)?check_answer
9Of these two drafts of the same answer, which one is better grounded? (check_answer)?check_answer
10We changed the retrieval prompt. Do the same ten answers score better now? (check_answer)?check_answer

EXA Answer Filter answers these through the tools above. A question outside them is refused, not guessed.

What it rests on

The evidence, and the edges.

Evidence

Status: pilot, exposure public, one read-only tool named check_answer. Source: the emable capability catalogue.
Verdict shape: trust_state OK, WARN or FAIL, plus faithfulness_score, confidence_score, verdict_text and a source list. Source: capability output schema.
Inputs: question and answer required. Insurer, up to 50 sources, country CZ or SK, and product line optional. Source: capability input schema.
Coverage: the insurer product documents indexed by the EXA methodology assistant, today Czech and Slovak insurers. Reliability follows that corpus, not a fixed snapshot. Source: manifest sources and limitations.
Freshness: the verdict reflects the insurer documents indexed at the time of the call.
Charging: one answer judged within the account quota, zero credits. A trial is one judged answer.
Not enough verified runs yet. Public statistics appear only after 20 verified runs across 5 different accounts.
Not callable from an MCP client today. The runner returns not_executable_via_mcp and charges nothing. Source: the connector manifest.

The verdict reflects the insurer documents indexed at the time of the call.

What it does not do

A filter, not an assistant. It never generates an answer, only judges one.
Coverage follows the indexed insurer corpus, today Czech and Slovak insurers.
A passing verdict is a grounding signal, not compliance approval. For a MiFID-style compliance verdict use validate_answer.
Pilot. There is no self-serve run on this page, and no call from your own AI client yet.
It judges the text you send. It reads no core system and no client record.
In a trial: one judged answer.

Verified usage

Not enough verified runs yet

Public statistics appear only after 20 verified runs across 5 different accounts.

The contract, for the people who will wire it

Status, permissions, tools, schemas and where it runs. The same values the API returns, so nothing here can drift from what your client will actually get.

Status, access and price

Status: Pilot
public
Provider: emable
Manifest version: v1.0.0
Countries: CZ, SK
Data class: derived
Access: read
Permissions: account:read
exa:validate
Charging unit: One answer judged within the account quotaPricing model: included. No separate charge per run.Credits are the platform's metering unit, not a price. We quote the engagement.

Tools and schemas

Check answer

read

check_answer

Judges one written answer against the insurer documents it claims to rest on. Does not answer questions itself.

Returns

A trust state (OK, WARN or FAIL) with faithfulness and confidence scores.

Detailed guidance for this tool is not published yet.

Input schema

{
  "type": "object",
  "properties": {
    "question": {
      "type": "string",
      "minLength": 3,
      "maxLength": 5000
    },
    "answer": {
      "type": "string",
      "minLength": 1,
      "maxLength": 20000
    },
    "insurer": {
      "type": "string",
      "maxLength": 120
    },
    "sources": {
      "type": "array",
      "items": {
        "type": "string",
        "maxLength": 2000
      },
      "maxItems": 50
    },
    "country": {
      "type": "string",
      "enum": [
        "CZ",
        "SK"
      ]
    },
    "insurance_type": {
      "type": "string",
      "maxLength": 60
    }
  },
  "required": [
    "question",
    "answer"
  ],
  "additionalProperties": false
}

Output schema

{
  "type": "object",
  "properties": {
    "trust_state": {
      "type": "string",
      "enum": [
        "OK",
        "WARN",
        "FAIL"
      ]
    },
    "faithfulness_score": {
      "type": "number"
    },
    "confidence_score": {
      "type": "number"
    },
    "verdict_text": {
      "type": "string"
    },
    "sources": {
      "type": "array",
      "items": {
        "type": "string"
      }
    }
  },
  "required": [
    "trust_state"
  ],
  "additionalProperties": false
}

Surfaces and connectors

specialist web

rest

No standalone MCP URL is deployed for this capability yet.

Specialist workspace, sign in required

Sources, limits and support

Sources

The insurer product documents indexed by the EXA methodology assistant.

Limitations

A filter, not an assistant: it never generates an answer, only judges one.

Coverage follows the indexed insurer corpus, today Czech and Slovak insurers.

A passing verdict is a grounding signal, not compliance approval. For a MiFID-style compliance verdict use afa__validate_answer.

Dependencies

The EXA methodology gateway and its insurer document index

Documentation Contact support

Tell us what you want answered, and we will tell you what it takes.

Write to us about EXA Answer Filter See the other capabilities