---
title: "Intake Configuration"
source: "https://docs.vertesiahq.com/content/intake-policies"
markdown: "https://docs.vertesiahq.com/llms/content/intake-policies.md"
---

# Intake Configuration

Intake configuration controls how uploaded content is classified, converted, extracted, verified, rendered, and embedded. Configure sensible defaults once for the project, then override only the settings that differ for a content type.

For example:

- contracts can be converted to complete markdown and have selected terms extracted
- purchase orders can use IDP to produce verified structured fields without converting every page
- scanned forms can use page images for extraction and a review model for difficult handwriting
- media types can disable transcription or selected embedding kinds

## Configuration hierarchy

Vertesia resolves intake settings from most specific to least specific:

1. explicit settings supplied for one processing run
2. the document's content type policy
3. the project's default intake policy
4. platform defaults

An unset field inherits the next level. A content type does not need to repeat the complete project policy.

If intake assigns a content type while processing a document, the policy is resolved again so the newly assigned type controls conversion, extraction, IDP, output, and embeddings in the same run.

## Project intake settings

Open **Settings > Project > Intake** to configure project-wide behavior.

The **Intake processing** section controls:

| Setting | Purpose |
|---|---|
| **Automatic processing** | Runs standard intake for new uploads. When disabled, uploads remain unprocessed until intake is enabled and they are reprocessed. |
| **Content type assignment** | Selects an existing active content type during intake. |
| **Default content type** | Used when no content type matches. If unset, Vertesia uses `GenericDocument`. |
| **Property extraction** | Extracts properties defined by the resolved content type schema. |
| **Table of contents** | Generates document sections for prepared text. An optional size limit skips this step for very large documents. |

The **Default intake policy** below those controls uses the same structured editor as content types. It defines the baseline conversion, extraction, IDP, output, and embedding behavior for the project.

## Content type policies

Open **Content > Types**, select a type, and open its **Intake** tab. The editor is organized by processing stage:

| Tab | Configures |
|---|---|
| **Overview** | Processing mode, type-identification guidance, page location, table of contents, and the preferred object view. |
| **Conversion** | Whether and how the source becomes text or markdown, including instructions and page selection. |
| **Extraction** | Structured property extraction, evidence source, page selection, and visual evidence limits. |
| **Grounding** | IDP citations, OCR or vision behavior, extraction models, complexity escalation, and review. |
| **Output** | Markdown rendering from properties and per-type embedding switches. |
| **JSON** | The complete policy for advanced settings, with schema validation and autocomplete. |

Use **Examples** to start from a common policy and then adjust it. The form and JSON tabs edit the same policy; JSON is a fallback for advanced configuration, not a separate mode.

## Conversion

The conversion policy determines whether the original source becomes document text.

| Field | Purpose |
|---|---|
| `text_conversion.enabled` | Enables conversion or transcription. Defaults to enabled. |
| `text_conversion.method` | `auto`, `basic`, `llm`, or `custom`. |
| `text_conversion.output_format` | `markdown` or `text`. |
| `text_conversion.instructions` | Describes what the converter should preserve or omit. |
| `text_conversion.scope` | Uses all pages or pages selected by the locate pass. |
| `text_conversion.page_ranges` | Static inclusive page ranges; negative positions count from the end. |

Use `basic` for mechanical text extraction and `llm` for [Markdown Conversion](/semantic/getting-started) when page layout, tables, and reading order matter.

Disabling conversion is useful for extraction-first documents. Intake can still create useful document text by rendering the extracted properties with an output template.

## Property extraction

Extraction shapes document properties using the content type's schema.

| Field | Purpose |
|---|---|
| `extraction.enabled` | Enables or disables property extraction. |
| `extraction.source` | Uses `auto`, `text`, `vision`, or `mixed` evidence. |
| `extraction.instructions` | Adds type-specific extraction guidance. |
| `extraction.scope` / `page_ranges` | Limits extraction to relevant pages. |
| `extraction.max_pages` | Caps the pages considered by standard extraction. |
| `extraction.vision` | Controls the allowed image detail levels and evidence budget. |
| `extraction.grounding` | Enables [IDP](/content/grounded-extraction) with citations and verification. |

Choose `text` for clean digital content, `vision` when the page image is authoritative, and `mixed` when both text and layout matter. `auto` selects the available evidence for the source.

## Locate relevant pages

Long documents can use a locate pass before conversion or extraction. The pass maps the document and selects pages relevant to the content type, avoiding the cost and prompt size of sending every page to later model calls.

```json
{
  "locate": {
    "instructions": "Find commercial terms, payment schedules, and signature pages.",
    "detail": 16,
    "min_pages": 8
  },
  "text_conversion": {
    "scope": "located"
  },
  "extraction": {
    "scope": "located"
  }
}
```

Use static `page_ranges` when the document layout is fixed. Static ranges take precedence over a located scope.

## IDP for structured documents

Enable grounding when extracted values need citations, verification, and an operational verdict:

```json
{
  "text_conversion": {
    "enabled": false
  },
  "extraction": {
    "enabled": true,
    "source": "mixed",
    "grounding": {
      "enabled": true,
      "use_vision": true,
      "review": {
        "enabled": true
      }
    }
  },
  "rendering_template": "# Order {{properties.order_number}}\n\n**Vendor:** {{properties.vendor_name}}\n**Total:** {{properties.total_amount}}"
}
```

This setup extracts verified properties and creates concise markdown from those properties. Configure extraction, hard-content, and review models in the **Grounding** tab when they should differ from the inherited defaults.

See [Intelligent Document Processing](/content/grounded-extraction) for verification tiers, reviewer behavior, output artifacts, and document processing events.

## Markdown conversion with extraction

Enable conversion and extraction together when users need the complete document narrative and selected structured fields:

```json
{
  "text_conversion": {
    "enabled": true,
    "method": "llm",
    "output_format": "markdown"
  },
  "extraction": {
    "enabled": true,
    "source": "text"
  },
  "embeddings": {
    "text": true,
    "properties": true
  }
}
```

## Rendering and embeddings

`rendering_template` is a Handlebars template evaluated against extracted properties. It produces canonical markdown when a document has no converted or manually authored text.

```handlebars
# Invoice {{properties.invoice_number}}

**Vendor:** {{properties.vendor_name}}
**Due:** {{properties.due_date}}
**Total:** {{properties.currency}} {{properties.total_amount}}
```

If no template is configured, intake can generate a default property rendering. Converted, transcribed, or manually edited text is not overwritten by property rendering.

The `embeddings` policy controls `text`, `properties`, and `image` embeddings for the type. A type can disable an embedding enabled by the project, but it cannot enable an embedding kind that the project has not configured.

## Type identification

Identification guidance helps automatic type assignment distinguish similar documents:

```json
{
  "identification": {
    "guidance": "European furniture import invoices with EUR amounts, incoterms, and VAT.",
    "distinguish_from": "Credit notes and domestic invoices use different content types."
  }
}
```

Only **active** content types participate in automatic assignment. Keep a type in **draft** while its schema and policy are being prepared.

## Configure with the SDK

Update a content type policy:

```ts
await client.store.types.update(typeId, {
    intake: {
        text_conversion: { enabled: false },
        extraction: {
            enabled: true,
            source: 'mixed',
            grounding: {
                enabled: true,
                use_vision: true,
                review: { enabled: true },
            },
        },
    },
});
```

Update project defaults:

```ts
await client.projects.updateConfiguration(projectId, {
    intake: {
        enabled: true,
        generate_content_type: true,
        generate_properties: true,
        default_policy: {
            text_conversion: { enabled: true, method: 'auto' },
            extraction: { enabled: true, source: 'auto' },
        },
    },
});
```

When updating an existing policy, include the other values you want to preserve in the submitted object.

## Reprocessing and events

Reprocessing a document through standard intake resolves the current project and content type policies again. Use this after changing a type, schema, conversion strategy, or IDP configuration.

Event Bus subscriptions are optional. They are useful after intake, for example to start a process when IDP emits `document_processed` with `good_to_go`, or to send `needs_review` outcomes to a webhook or human task. See [Event Subscriptions](/events/subscriptions#idp-document-events).