Skip to main content

​
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:
  1. Document upload — A document is uploaded to a policy or brokerage firm through one of the supported interfaces.
  2. 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”).
  3. 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.
  4. Consensus evaluation — The system checks whether all judges agree with the suggested category.
  5. Automatic acceptance — If all judges agree (consensus), the category is automatically applied to the document. The classification status is set to auto_accepted.
  6. 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
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.

​
Events

The document classification lifecycle emits events that provide a complete audit trail of how documents are categorized. These events are only emitted for documents associated with a policy. POLICY_DOCUMENT_AUTO_CLASSIFIED — Emitted when AI classifies a document. This event is emitted regardless of whether consensus was reached. It includes the documentId, the suggested category, the classificationStatus (auto_accepted or pending_review), and a traceId for debugging and tracking. POLICY_DOCUMENT_MANUALLY_CATEGORIZED — Emitted when a broker manually sets a document category. This covers both the case where a broker categorizes a document that was never sent through AI classification and the case where a broker sets a category on a document flagged for review. It includes the documentId, the new category, and the previousCategory (if any). POLICY_DOCUMENT_RECLASSIFIED — Emitted when a broker corrects an AI classification that was previously auto-accepted. This event captures the correction explicitly, including the documentId, the originalCategory assigned by AI, the newCategory chosen by the broker, and the traceId linking back to the original classification.
Classification events are only emitted for documents associated with a policy. Documents uploaded at the brokerage firm level without a policy association are classified but do not generate policy events.

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