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 template references, 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 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.
Validity awareness — Side filtering also applies to validity 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 centrally managed prompt template. 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 Validity

After a document is classified and extracted, Korint can automatically verify that it meets validity requirements using a configurable set of rules. Validity 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

Validity checking runs automatically after extraction completes:

Trigger — When a document’s category is set and extraction finishes, the platform looks up the validity 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 VALID. If any rule fails, the document is marked INVALID. The individual rule results are stored for detailed reporting.
Side-aware filtering — When a document has a detected side (recto or verso), validity rules that reference extraction fields are automatically filtered to only check fields relevant to the detected side.

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

Validity Status

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

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

Rule Types

Validity 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 validity 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 centrally managed prompt template.

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

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

Example: policyholder document validity

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'] },
    ],
    validity: [
      { 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 validity toggle

ai: {
  validity: {
    enabled: true,
  },
}

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

Manual Override

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

Override to valid — The broker marks an invalid document as valid, bypassing the failed rules.
Override to invalid — The broker marks a valid document as invalid, 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 validity decisions. Override events are also persisted as AI feedback, enabling analysis of how often automated validity decisions are overridden and in which direction.

AI Document Prefill

Once a document has been classified and its fields extracted, Korint can automatically populate the matching custom fields on the policy, customer, asset, or brokerage firm. Document Prefill closes the loop between AI extraction and the funnel forms: instead of asking policyholders or brokers to retype the same information that already appears on their KBIS, identity card, or driver’s license, the platform fills the fields for them and asks for confirmation. Prefill applies to both policyholder funnels (customer, asset, and policy custom fields populated from documents uploaded during onboarding) and brokerage firm signup funnels (broker custom fields populated from KBIS, ORIAS attestation, IBAN, etc.).

How It Works

Prefill runs automatically after extraction completes on an eligible document upload:

Eligibility gate — Prefill is restricted to funnel uploads (the policyholder discovery funnel and the brokerage firm signup funnel). Documents added later from the management UI never trigger prefill, so brokers can attach supporting evidence without overwriting fields the customer already corrected.
Extraction lookup — The platform reads the structured fields produced by AI extraction for the uploaded document.
Field matching — Each custom field declares which document categories it can be sourced from (extractionSources) and, optionally, which specific extracted key to read (extractionFieldKey). The prefill service walks the configured custom fields and matches them against the available extracted values.
Value coercion — Date and datetime fields are normalized to ISO 8601 (YYYY-MM-DD) before being written, so the frontend never has to guess between regional date formats. Values that cannot be parsed safely are skipped rather than written as garbage.
Write or suggest — For each matched field, the service either fills the field (if it was empty) or records a suggestion (if the field already had a value that differs from the extracted one). Suggestions are surfaced in the funnel UI so the user can choose whether to accept the new value.
Provenance tracking — Every prefill writes a domain event tagged with origin: 'ai.prefill' and the per-field provenance (custom field key, source extraction key, value written, previous value). This audit trail is what makes the operation reversible.

Prefill never overwrites a non-empty field silently. If the document carries a value that conflicts with what is already on the policy, customer, or brokerage firm, the user sees a suggestion they can explicitly accept or dismiss.

Field Outcomes

Each prefill attempt sorts every candidate field into one of three buckets:

Outcome	Description
`filledFields`	The field was empty and has been populated with the extracted value.
`suggestedFields`	The field already had a value, and the extracted value differs. The user is shown the suggestion alongside the current value.
`skippedFields`	The field could not be filled. Skip reasons include `MULTI_CUSTOMER_DISABLED` (the source document doesn’t unambiguously map to a single customer), `NO_EXTRACTION` (no extracted value matched), and `INVALID_DATE_FORMAT` (the value couldn’t be parsed as a date).

Configuration

Prefill is configured in two places: at the field level (which extraction sources feed which custom field) and at the funnel level (whether prefill is offered by default, or whether the user must opt in).

Wiring custom fields to extraction sources

Each custom field that should be auto-filled declares the document categories it can be sourced from and an optional field-level toggle:

Example: brokerage firm custom fields with extraction sources

brokerageFirmCustomFields: [
  {
    key: 'iban',
    type: CustomFieldType.IBAN,
    extractionSources: ['iban-cabinet'],
    autoFill: { enabled: true },
  },
  {
    key: 'siret',
    type: CustomFieldType.STRING,
    extractionSources: ['kbis', 'attestation-orias'],
    extractionFieldKey: 'siret',
    autoFill: { enabled: true },
  },
  {
    key: 'brokerDirectorFirstName',
    type: CustomFieldType.STRING,
    extractionSources: ['identite-recto'],
    extractionFieldKey: 'firstName',
    autoFill: { enabled: true },
  },
]

extractionSources — Document categories whose extraction output can populate this field. When several categories are listed (e.g. ['kbis', 'attestation-orias']), the first uploaded document carrying the matching key wins.
extractionFieldKey — The exact key from the extraction output to copy. When omitted, prefill defaults to matching by custom field key.
autoFill.enabled — Per-field switch to opt this custom field into prefill.

Funnel default choice

Each tenant can decide whether the funnel defaults to uploading documents up front (prefill kicks in immediately) or defaults to deferring documents to later (prefill is offered as an opt-in step):

Example: documentPrefill tenant configuration

documentPrefill: {
  policyholderDefaultChoice: DocumentPrefillDefaultChoice.UPLOAD,
  brokerageFirmDefaultChoice: DocumentPrefillDefaultChoice.UPLOAD,
}

UPLOAD — The funnel surfaces document upload at the start, so prefill happens before the user fills any field manually.
LATER — Document upload is deferred to a later step. Users can still upload during the funnel to trigger prefill, but the default flow keeps form entry first.

Reverting Prefill

Because every prefill is recorded as a versioned event, deleting the source document automatically reverts the values that came from it. The revert logic walks the prefill provenance, compares the value currently on the entity to the value originally written, and:

Reverts the field if the current value still matches the prefilled value — the user never edited it.
Preserves the field if the user has since changed it — their edit takes precedence and is left untouched.

This guarantees that removing an incorrectly classified document never silently overwrites the user’s manual corrections.

Human Review and Confirmation

Prefilled values are not silent: the funnel UI marks fields that were populated by prefill with an indicator, so the user can see at a glance which values came from a document and which they typed themselves. For fields that were already filled before the document arrived, the suggested value is surfaced as a side-by-side proposal — the user accepts, dismisses, or edits. Acceptance is recorded as an explicit confirmation, feeding the same AI feedback loop used by classification and extraction.

Concepts

Documentation Index

​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 Validity

​How It Works

​Validity Status

​Rule Types

​Readable

​Required Fields

​Prompt

​Field Validation

​Configuration

​Manual Override

​AI Document Prefill

​How It Works

​Field Outcomes

​Configuration

​Wiring custom fields to extraction sources

​Funnel default choice

​Reverting Prefill

​Human Review and Confirmation

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 Validity

How It Works

Validity Status

Rule Types

Readable

Required Fields

Prompt

Field Validation

Configuration

Manual Override

AI Document Prefill

How It Works

Field Outcomes

Configuration

Wiring custom fields to extraction sources

Funnel default choice

Reverting Prefill

Human Review and Confirmation