We are currently building something exciting and will be launching soon. Registration is temporarily closed. Launching soon — registration temporarily closed.

INDICATORS REFERENCE

Insurance Intelligence Indicators

Insurance Intelligence covers 200 indicators across 4 signal groups. Each signal has a stable slug and code for programmatic access. Representative signals are shown publicly; the complete reference is available to customers.

200
Indicators
4
Signal Groups
40
Languages
50
Avg / Group
4 results

Showing 4 representative indicators of 200. The complete taxonomy is available to customers.

Request access
# Indicator Slug code Signal Group
001 auto collision auto_collision claim_type.auto_collision Claim Type
002 fraud staged accident fraud_staged_accident claim_fraud.fraud_staged_accident Claim Fraud
003 status filed status_filed claim_process.status_filed Claim Process
004 injury minor injury_minor claim_details.injury_minor Claim Details

Browse by Signal Group

Alternatively, explore indicators grouped by their parent signal group:

1

Claim Type

claim_type
50 Indicators

The complete signal list for this signal group is available to customers. Request access to view it.

2

Claim Fraud

claim_fraud
60 Indicators

The complete signal list for this signal group is available to customers. Request access to view it.

3

Claim Process

claim_process
40 Indicators

The complete signal list for this signal group is available to customers. Request access to view it.

4

Claim Details

claim_details
50 Indicators

The complete signal list for this signal group is available to customers. Request access to view it.

Reading Insurance Intelligence output

What you can safely infer from a result - and what you must not.

Intended task

Classify claim narratives into documented claim types and fraud-pattern signal groups - for routing and SIU review.

Input requirements

  • text - the only field analyzed; up to 4,096 Unicode code points. Over the limit is rejected with input_too_long, never truncated.
  • language - must be a language this analyzer supports. Unsupported codes are rejected with 400 unsupported_language, never analyzed as a different language.
  • analyzers - include "insurance"; up to 2 analyzers per request, one billed run each.
  • No context beyond text - no user IDs, history, profiles, or attachments are read or inferred.
  • Analyzes the narrative text only - policy terms, claim history, and evidence files are not inputs.

Ordinary positive

“My parked car was hit overnight. The other driver left a note with their plate number and insurer.”

claim_type_auto very high
claim_third_party_claimant high

Safe inference: The narrative classifies as an auto claim with a third-party element - route it to the auto queue with subrogation flagged.

Confusing negative · Quotation

“The claimant's own witness said "we agreed to split the payout" - see the attached statement.”

What happens: Fraud-pattern signals can fire on the quoted statement. The signal flags that the language matches a documented fraud pattern - it does not weigh whose words they are or whether the statement is credible.

Why it's tricky: Claim files are full of quoted speech - witness statements, adjuster notes, reported conversations. A fraud-pattern signal on a narrative is a review trigger, never a finding: route it to your SIU, and let investigators weigh the evidence.

What you can safely infer

  • Which documented claim types and fraud-pattern groups the narrative matched.
  • That the same narrative on the same pinned configuration classifies identically - the receipt supports dispute review.

What you must not infer

  • ✕That fraud occurred or that the claimant lied - fraud signals route review, they do not determine wrongdoing.
  • ✕Coverage, liability, or payout decisions - those stay with your adjusters and policy terms.
  • ✕That a claim with no fraud signal is verified legitimate - a missing signal is "not detected," never "cleared."

Boundary: Fraud signals are not proof of wrongdoing. They flag language consistent with documented fraud patterns so a reviewer looks - the determination stays with your SIU and your process.

Using Indicators in API Responses

When you call /v1/analyze, the response includes matched indicators with signal-match scores. Each signal is identified by its code and includes a level field (“category” or “label”). A score expresses signal-match strength under a particular analyzer configuration. It is not a probability that the signal or a downstream action is correct. Validate action thresholds on representative labeled data.

{
    "language": "en",
    "language_source": "declared",
    "signals": [
        {
            "analyzer": "insurance",
            "code": "claim_fraud",
            "label": "Claim Fraud",
            "score": 0.93,
            "level": "category"
        },
        {
            "analyzer": "insurance",
            "code": "fraud_staged_accident",
            "label": "Staged or deliberate auto accident",
            "score": 0.91,
            "level": "label",
            "parent": "claim_fraud"
        },
        {
            "analyzer": "insurance",
            "code": "fraud_swoop_squat",
            "label": "Swoop and squat or forced collision scheme",
            "score": 0.88,
            "level": "label",
            "parent": "claim_fraud"
        }
    ],
    "meta": {
        "analyzers": [
            {
                "name": "insurance",
                "status": "completed",
                "applicability": "analyzable",
                "assessment": "signals_detected",
                "signal_count": 3,
                "billed": true
            }
        ]
    },
    "usage": {
        "analyzer_runs": 1
    },
    "verification": {
        "configuration": "sqcfg_GFAWTERR",
        "fingerprint": "fp_8a72...19f",
        "input_commitment": "ic_31bd...a42",
        "signature": "sig_ed25519_4c1f...e2a",
        "key_id": "edk_af4f218e"
    }
}