Documents - Korint

Document types

Each document is fully customizable using a template, with access to all data available in Korint’s entities: policies, customers, assets, invoices, payments and brokerage firms. Furthermore, you decide when a document should be available:

Use a Korint business event to trigger the generation of your document - for example generate a contract when the policy is confirmed, or generate a quote document when the policy is quoted.
Mark documents as required for signature, and Korint will verify its presence before sending a signature link to the customer.
Mark documents as common documents, and they will be available immediately after the policy is created - for example a general terms and conditions document.
Customer documents such as a driver’s license will be uploaded manually during a funnel.
Policy documents, like the quote or contract, can also be uploaded by the broker and set up as required for signature.

AI Document Classification

Korint can automatically classify uploaded documents using AI. When a document is uploaded, the platform analyzes its content using AI models and suggests a category. This reduces manual work for brokers and speeds up document processing, ensuring that documents are categorized consistently and accurately across the platform.

How It Works

The classification process follows a structured flow designed to maximize accuracy through independent verification:

Document upload — A document is uploaded to a policy or brokerage firm through one of the supported interfaces.
AI analysis — The system sends the document to an AI model for analysis. The model examines the document content and suggests a category (for example, “kbis”, “carte-grise”, or “rib”).
Judge verification — One or more independent judge models verify the initial classification. Each judge evaluates whether the suggested category is correct and provides its own reasoning.
Consensus evaluation — The system checks whether all judges agree with the suggested category.
Automatic acceptance — If all judges agree (consensus), the category is automatically applied to the document. The classification status is set to auto_accepted.
Pending review — If judges disagree (no consensus), the document is flagged for human review. The classification status is set to pending_review, and the AI’s suggestion is stored for reference.

When consensus is reached, the document category is set automatically without requiring broker intervention. When there is no consensus, the AI’s suggestion is stored but the broker must manually confirm or correct the category.

Classification Interfaces

AI classification can be enabled per interface type, each configurable independently:

Policyholder Dashboard (policyholderDashboard): Documents uploaded by policyholders during funnels. This is the most common interface for AI classification, as policyholders frequently upload identity documents, vehicle registration cards, and other supporting documents.
Brokerage Firm Documents (brokerageFirmDocuments): Documents managed at the brokerage firm level. This interface uses tenant-level configuration rather than product-level configuration, since brokerage firm documents are not tied to a specific product.
Non-Delegated Documents (nonDelegatedDocuments): Documents in non-delegated workflows where the broker handles document collection outside of the standard policyholder funnel.

Configuration

AI classification is configured at two levels depending on the interface type: Product level — For the policyholder dashboard and non-delegated document interfaces, classification is configured within the product configuration. Each product can independently enable or disable classification and configure which AI models to use as judges. This allows different products to have different classification behaviors based on their document requirements. Tenant level — For brokerage firm documents, classification is configured at the tenant level. This tenant-wide configuration applies to all brokerage firm document uploads across the tenant, regardless of which product they may relate to. Configuration includes:

enabled — Master switch for AI classification at the product or tenant level
interfaces — Per-interface configuration, each with its own enabled flag, prompt slugs (managed via Basalt), and judge models
judges — Array of judge configurations, each specifying a model type (fast or quality) and an enabled flag

Example product configuration

aiClassification: {
  enabled: true,
  interfaces: {
    policyholderDashboard: {
      enabled: true,
      systemPromptSlug: 'classify-document-v1',
      judgePromptSlug: 'judge-classification-v1',
      judges: [
        { model: 'fast', enabled: true },
        { model: 'quality', enabled: true },
      ],
    },
  },
}

The fast model prioritizes speed and is suitable for high-volume document processing. The quality model prioritizes accuracy and is recommended for documents where misclassification has a higher business impact. Using both models as judges provides a balance between speed and accuracy through consensus verification.

Human Review and Corrections

When AI classification requires review (no consensus among judges) or when a broker disagrees with an auto-accepted classification, the broker can intervene through the document management interface:

Confirming a suggestion — When a document is in pending_review status, the broker can confirm the AI’s suggested category. This applies the category and records the manual categorization event.
Correcting a classification — When a document was auto-accepted with an incorrect category, the broker can correct it. The system records both the original AI classification and the broker’s correction, maintaining a full audit trail.
Manual categorization — The broker can also set a category on documents that were not processed by AI, following the same workflow as before the AI classification feature was introduced.

Corrections and manual categorizations are logged as events, creating a feedback loop that can be used to improve AI classification accuracy over time. Each correction event preserves the original AI suggestion alongside the broker’s chosen category, ensuring complete traceability of how document categories evolve.

AI Document Extraction

Beyond classification, Korint can automatically extract structured data from uploaded documents using AI. Once a document is categorized, the platform analyzes its content and pulls out predefined fields — such as names, dates, registration numbers, or company identifiers. This eliminates manual data entry for brokers and reduces errors caused by mistyped information.

How It Works

The extraction process is tightly coupled with document classification and runs automatically:

Document categorization — A document receives a category, either through AI classification (auto-accepted) or through manual categorization by a broker.
Extraction trigger — As soon as the category is set, the platform checks whether extraction fields are configured for that category in the product or tenant configuration. If no fields are configured, extraction is skipped.
AI analysis — The document image is sent to an AI model (AWS Bedrock) along with the list of fields to extract. The model examines the document and returns structured key-value pairs.
Result storage — Extracted fields are stored alongside the document, making them instantly available to brokers through the document management interface.

Extraction applies to both policyholder documents (identity cards, vehicle registrations, bank statements) and brokerage firm documents (KBIS, IBAN, professional certificates).

Extraction is triggered automatically when a document’s category is set or changed. If a document is reclassified to a different category, a new extraction runs with the field definitions corresponding to the new category.

Extraction Status

Each extraction goes through one of the following statuses:

Status	Description
`PENDING`	Extraction is in progress. The AI model is analyzing the document.
`DONE`	Extraction completed successfully. Fields are available for review.
`FAILED`	Extraction encountered an error. The broker can retry the extraction.
`SKIPPED`	No extraction fields are configured for this document category, or extraction is disabled.

Supported Field Types

Extraction fields are typed, allowing the AI model to return values in the expected format:

Type	Description	Example
`STRING`	Free-form text	Company name, first name, IBAN
`DATE`	Date value	Date of birth, license issue date
`NUMBER`	Numeric value	Fiscal power, bonus/malus coefficient

Configuration

Extraction is configured at two levels: Product level — Extraction fields are defined per document category within the product configuration. Each category in policyholderDocuments can include an extractionFields array specifying which fields to extract from that document type. Tenant level — For brokerage firm documents, extraction fields are configured in the tenant configuration under brokerageFirmDocuments. A global toggle (ai.extraction.enabled) controls whether extraction is active for the tenant.

Example: policyholder document extraction fields

policyholderDocuments: [
  {
    category: 'permis-conduire',
    extractionFields: [
      { key: 'firstName', type: 'STRING', label: 'First name' },
      { key: 'lastName', type: 'STRING', label: 'Last name' },
      { key: 'birthDate', type: 'DATE', label: 'Date of birth' },
      { key: 'licenseDate', type: 'DATE', label: 'License issue date' },
    ],
  },
  {
    category: 'certificat-immatriculation',
    extractionFields: [
      { key: 'firstName', type: 'STRING', label: 'First name' },
      { key: 'lastName', type: 'STRING', label: 'Last name' },
      { key: 'registrationNumber', type: 'STRING', label: 'Registration number' },
      { key: 'brand', type: 'STRING', label: 'Brand' },
      { key: 'model', type: 'STRING', label: 'Model' },
      { key: 'fiscalPower', type: 'NUMBER', label: 'Fiscal power' },
    ],
  },
  {
    category: 'kbis',
    extractionFields: [
      { key: 'companyName', type: 'STRING', label: 'Company name' },
      { key: 'companySiret', type: 'STRING', label: 'SIRET' },
      { key: 'companySiren', type: 'STRING', label: 'SIREN' },
      { key: 'companyNafLabel', type: 'STRING', label: 'NAF code label' },
      { key: 'companyCreationDate', type: 'STRING', label: 'Creation date' },
    ],
  },
]

Categories without extractionFields (or with an empty array) will have extraction skipped for that document type.

Recto/Verso (Side-Aware Extraction)

Some documents — such as identity cards or vehicle registration certificates — have distinct information on each side. Korint supports side-aware extraction, where each extraction field can be associated with a specific side of the document: recto (front), verso (back), or both.

How It Works

Side detection during classification — When AI classification runs, it also detects which side of the document was uploaded. This information is stored in the classification metadata alongside the category.
Field filtering — When extraction is triggered, the platform checks the detected side and filters the extraction fields accordingly. Only fields relevant to the detected side are sent to the AI model.
Compliance awareness — Side filtering also applies to compliance rules. Required fields and field validation rules are evaluated only against the fields that are expected to appear on the detected side.

If no side is detected (e.g., single-page documents or documents without side configuration), all fields are extracted as usual.

Configuration

Each extraction field can optionally include a sides array specifying which sides of the document it appears on:

Example: side-aware extraction fields

policyholderDocuments: [
  {
    category: 'carte-identite',
    extractionFields: [
      { key: 'firstName', type: 'STRING', sides: ['recto'] },
      { key: 'lastName', type: 'STRING', sides: ['recto'] },
      { key: 'birthDate', type: 'DATE', sides: ['recto'] },
      { key: 'expirationDate', type: 'DATE', sides: ['verso'] },
      { key: 'documentNumber', type: 'STRING', sides: ['recto', 'verso'] },
    ],
  },
]

A field with sides: ['recto'] is only extracted when the front side is detected.
A field with sides: ['verso'] is only extracted when the back side is detected.
A field with sides: ['recto', 'verso'] (or without sides) is extracted regardless of the detected side.

Example: AI extraction toggle

ai: {
  extraction: {
    enabled: true,
    promptSlug: 'extract-insurance-document-fields',
  },
}

The promptSlug references a prompt template managed through Basalt. This prompt is sent to the AI model along with the document image and the field definitions.

Human Review and Corrections

Extracted values are presented to brokers as a pre-filled summary alongside the document. Brokers can review, correct, or validate each field:

Field correction (FIELD_CORRECTION) — The broker provides a corrected value for an incorrectly extracted field. Both the original AI value and the broker’s correction are recorded.
Field validation (FIELD_VALIDATION) — The broker confirms that the extracted value is correct. This positive signal helps track extraction accuracy.
Document rejection (DOCUMENT_REJECTION) — The broker indicates that the document is not suitable for extraction (e.g., unreadable, wrong document type). This is useful for flagging quality issues.

All feedback is persisted with the user ID and timestamp, creating an audit trail that can be used to measure and improve extraction accuracy over time.

Retrying Failed Extractions

When an extraction fails (due to a transient error, AI service unavailability, or an unreadable document), brokers can retry the extraction from the document management interface. The retry uses the same document and category but performs a fresh AI analysis.

AI Document Compliance

After a document is classified and extracted, Korint can automatically verify that it meets compliance requirements using a configurable set of rules. Compliance checking combines deterministic validations (field presence, value constraints) with AI-powered analysis (readability, prompt-based checks) to determine whether a document is fit for use.

How It Works

Compliance checking runs automatically after extraction completes:

Trigger — When a document’s category is set and extraction finishes, the platform looks up the compliance rules configured for that document category.
Rule evaluation — Each configured rule is evaluated in sequence. Rules can check document quality, required field presence, AI-based content analysis, or extracted field values.
Status determination — If all rules pass, the document is marked COMPLIANT. If any rule fails, the document is marked NON_COMPLIANT. The individual rule results are stored for detailed reporting.
Side-aware filtering — When a document has a detected side (recto or verso), compliance rules that reference extraction fields are automatically filtered to only check fields relevant to the detected side.

Compliance is evaluated for both policyholder documents and brokerage firm documents. Policyholder compliance rules are configured at the product level, while brokerage firm compliance rules are configured at the tenant level.

Compliance Status

Each document’s compliance goes through one of the following statuses:

Status	Description
`PENDING`	Compliance check is in progress.
`COMPLIANT`	All compliance rules passed. The document meets requirements.
`NON_COMPLIANT`	One or more compliance rules failed. The document needs attention.
`FAILED`	The compliance check encountered an error (e.g., AI service unavailable).
`SKIPPED`	No compliance rules are configured for this document category, or compliance is disabled.

Rule Types

Compliance rules are evaluated per document category. Each rule type serves a different purpose:

Readable

Checks whether the document is legible by inspecting quality flags set during AI classification. If the classification detected quality issues such as poor_image_quality, blurry, partially_visible, or corrupted_document, the rule fails.

{ type: 'READABLE' }

Required Fields

Verifies that specific extracted fields are present and non-empty. This rule references field keys from the extraction configuration. If the document has a detected side, only fields relevant to that side are checked.

{
  type: 'REQUIRED_FIELDS',
  requiredFields: ['firstName', 'lastName', 'birthDate'],
}

Prompt

Sends the document image to an AI model along with a custom prompt for analysis. The AI returns a pass/fail verdict with reasoning. This is useful for compliance checks that cannot be expressed as simple field validations — for example, verifying that a signature is present, that a stamp is visible, or that the document matches expected formatting.

{
  type: 'PROMPT',
  promptSlug: 'check-document-authenticity-v1',
}

The promptSlug references a prompt template managed through Basalt.

Field Validation

Validates extracted field values against configurable operators. This enables automated checks such as “the license issue date must not be older than 10 years” or “the fiscal power must be between 1 and 50”.

{
  type: 'FIELD_VALIDATION',
  validations: [
    {
      fieldKey: 'licenseDate',
      operator: 'DATE_IS_NOT_OLDER_THAN',
      reference: { ref: 'NOW' },
      duration: { amount: 15, unit: 'YEAR' },
      errorMessage: 'Driver license is expired (older than 15 years)',
    },
    {
      fieldKey: 'fiscalPower',
      operator: 'NUMBER_BETWEEN',
      numericMin: 1,
      numericMax: 50,
      errorMessage: 'Fiscal power is out of expected range',
    },
  ],
}

Supported operators:

Operator	Type	Description
`DATE_IS_AFTER`	Date	Field date must be after a reference date
`DATE_IS_BEFORE`	Date	Field date must be before a reference date
`DATE_IS_NOT_OLDER_THAN`	Date	Field date must not be older than a duration from a reference
`DATE_IS_NOT_NEWER_THAN`	Date	Field date must not be newer than a duration from a reference
`STRING_MATCHES`	String	Field value must match a regex pattern
`STRING_EQUALS`	String	Field value must equal an expected value (case insensitive)
`STRING_NOT_EMPTY`	String	Field value must not be empty
`NUMBER_GT`	Number	Field value must be greater than a threshold
`NUMBER_LT`	Number	Field value must be less than a threshold
`NUMBER_BETWEEN`	Number	Field value must be within a range

Date operators support flexible references:

NOW — Compare against the current date
FIELD — Compare against another extracted field’s value
LITERAL — Compare against a fixed date value

Configuration

Compliance rules are configured per document category, alongside extraction fields:

Example: policyholder document compliance

policyholderDocuments: [
  {
    category: 'permis-conduire',
    extractionFields: [
      { key: 'firstName', type: 'STRING', sides: ['recto'] },
      { key: 'lastName', type: 'STRING', sides: ['recto'] },
      { key: 'birthDate', type: 'DATE', sides: ['recto'] },
      { key: 'licenseDate', type: 'DATE', sides: ['verso'] },
    ],
    compliance: [
      { type: 'READABLE' },
      {
        type: 'REQUIRED_FIELDS',
        requiredFields: ['firstName', 'lastName'],
      },
      {
        type: 'FIELD_VALIDATION',
        validations: [
          {
            fieldKey: 'licenseDate',
            operator: 'DATE_IS_NOT_OLDER_THAN',
            reference: { ref: 'NOW' },
            duration: { amount: 15, unit: 'YEAR' },
            errorMessage: 'Driver license is expired',
          },
        ],
      },
    ],
  },
]

Example: AI compliance toggle

ai: {
  compliance: {
    enabled: true,
  },
}

Compliance must be explicitly enabled in the AI configuration at the product or tenant level.

Manual Override

Brokers can manually override the compliance status of a document when they disagree with the automated assessment. This is useful when a document is flagged as non-compliant but the broker determines it is acceptable, or vice versa.

Override to compliant — The broker marks a non-compliant document as compliant, bypassing the failed rules.
Override to non-compliant — The broker marks a compliant document as non-compliant, flagging it for further action.
Revert to original — If the broker overrides and later changes their mind, reverting to the original AI-determined status clears the override entirely.

Each override records an audit trail including the user who performed the override, the timestamp, the previous status, and the original AI-determined status. This ensures full traceability of compliance decisions. Override events are also persisted as AI feedback, enabling analysis of how often automated compliance decisions are overridden and in which direction.

Concepts

​Document types

​AI Document Classification

​How It Works

​Classification Interfaces

​Configuration

​Human Review and Corrections

​AI Document Extraction

​How It Works

​Extraction Status

​Supported Field Types

​Configuration

​Recto/Verso (Side-Aware Extraction)

​How It Works

​Configuration

​Human Review and Corrections

​Retrying Failed Extractions

​AI Document Compliance

​How It Works

​Compliance Status

​Rule Types

​Readable

​Required Fields

​Prompt

​Field Validation

​Configuration

​Manual Override

Document types

AI Document Classification

How It Works

Classification Interfaces

Configuration

Human Review and Corrections

AI Document Extraction

How It Works

Extraction Status

Supported Field Types

Configuration

Recto/Verso (Side-Aware Extraction)

How It Works

Configuration

Human Review and Corrections

Retrying Failed Extractions

AI Document Compliance

How It Works

Compliance Status

Rule Types

Readable

Required Fields

Prompt

Field Validation

Configuration

Manual Override