C3 AI Document AI Overview
Platform requirements
Document AI requires C3 AI Platform version 8.10 or later. The target application that owns the documents must be running on platform 8.10+ to mint the presignedUrl values that Document AI uses for file transport. Earlier platform versions aren't supported.
Document AI is the shared document-intelligence service of the C3 Agentic AI Platform. It turns unstructured files, such as PDF reports, contracts, and presentations, into governed application context: searchable passages and structured metadata your application can use. Your application submits files through a REST API. Document AI parses, chunks, and embeds the content, then writes the results into your application's retriever, where agents and search features can use them. Process documents once as a shared platform service, and put the results to work wherever your application already runs.
Document AI runs as its own application on your cluster and has no user interface. You interact with it through its REST API or by asking the Agentix assistant to ingest files for you. Document AI isn't the system of record for your documents and keeps no search index of its own. Your application keeps ownership of the files and the processed results, without standing up a parallel document or search stack. Document AI retains only processing intermediates in its own storage, such as run results and the cached parsing output that makes repeat submissions faster.
When to use Document AI
Use Document AI when:
- You want an agent or search feature in your application to answer questions grounded in your documents. Document AI produces the embedded passages that retrieval-augmented generation depends on.
- You want to extract structured metadata from documents, such as document type, category, or effective date, without writing extraction code.
- You want to pull typed entities out of documents, such as organizations, contract terms, or measurements, and land them in your application's data model.
- You want to catalog a large document set by metadata alone, without the cost of chunking and embedding every page.
- Your documents carry meaning in their layout: Document AI reads each page visually, so tables, figures, and scanned or heavily formatted pages come through as searchable content, not lost text.
- You want processing in one request, off your application's compute: a strategy bundles the whole pipeline, runs it as a separate service that scales with demand, and reports token usage and cost per batch.
Document AI isn't a document store, a file viewer, or a new search product: it doesn't duplicate your applications' data, identity, or governance. Your application remains the system of record for the files themselves. Document AI also isn't intended for structured data sources such as database tables or CSV files; use the platform's data integration capabilities for those.
How Document AI processes documents
- Your application submits files with a single REST call. Document AI creates one job for the request and one run per file.
- Each run applies a named processing strategy. The default strategy converts the file to PDF if needed and reads each page with a vision language model. It then splits the content into chunks, extracts any tags and entities you configured, and embeds each chunk.
- When you supply a retriever ID, Document AI writes the results back into your application. It creates one
Genai.Vector.SourcePassagerecord per chunk, oneGenai.SourceFilerecord per document, and any extracted tags and entities. - You monitor progress through job and run status calls. Each run reports its pipeline logs, token usage, and estimated cost.
Processing is asynchronous. A single small file typically completes in under a minute, batches process in parallel, and processing capacity scales automatically with load. Re-submitting an unchanged file costs less time and money than a fresh submission, because Document AI reuses its earlier parsing results instead of parsing the file again.
Key concepts
- Strategy: A named recipe that defines how Document AI processes a document. Document AI ships two strategies,
passage_levelanddocument_level, and also runs a custom strategy you supply inline with a request. - Job: One processing request. A job groups the runs created from a single submission and derives its status from them.
- Run: The processing of one file. A run moves through a fixed lifecycle from
PENDINGtoPERSISTEDorFAILED. - Ingestion settings: Optional per-request configuration that controls what a strategy extracts, such as the tag schema and entity types. Each strategy defines which settings it accepts.
- Target application: The application that owns the documents and receives the results. Document AI calls this the source app. Every processing request names one.
- Retriever: The vector index in your target application that receives the embedded passages, conventionally
default-pg. The retriever's embedding model must match the model configured on the Document AI instance. - Persistence: The step that writes completed results into the target application. Persistence runs automatically when you supply a retriever ID at submission, or on demand through a separate call.
Processing strategies
| Strategy | What it does | Use it for |
|---|---|---|
passage_level | Parses every page, chunks the content, extracts configured tags and entities, and embeds each chunk. Detects the document's section hierarchy to improve retrieval context. | Making documents searchable for retrieval-augmented generation. |
document_level | Extracts document-level tags and entities from a limited set of pages. Produces no chunks and no embeddings, so cost stays flat regardless of document length. | Cataloging or filtering large document sets by metadata. |
You can also supply a custom strategy. A custom strategy is a Python function that composes the same building blocks the built-in strategies use, such as parse, chunk, extract, and embed. You pass it inline as the script field on each request instead of a strategy name, so it runs on the existing service with no registration step and no redeployment. To author one, see Develop Custom Strategies.
Supported documents
Document AI processes PDF files natively. It converts common office formats, such as Word and PowerPoint documents, to PDF before processing. Corrupt files fail immediately with a clear error, and PDF files that require a password fail with an explanatory message.
Each file must pass a size gate, 1 GiB by default, at submission time. Files over the limit are rejected up front and reported back in the submission response.
Within that ceiling, Document AI assigns each file to a size-tier fleet so a small file never queues behind a large one:
| Tier | Default size range | Fleet behavior |
|---|---|---|
| Small | Up to 50 MB | Always on; minimum of one pod by default. |
| Medium | Up to 200 MB | Scales from zero when work arrives; idle at zero. |
| Large | Up to 1 GiB | Scales from zero when work arrives; idle at zero. |
Ways to use Document AI
- REST API: Submit, monitor, and persist processing jobs from any application on the cluster. This is the primary interface and supports all Document AI capabilities.
- Agentix assistant: Ask the assistant to ingest files in plain language, for example "Ingest report.pdf into the default-pg retriever." The assistant submits the job, monitors it, and reports the outcome. Files attached in chat are supported.
To process your first document in about ten minutes, see Quick Start - Process Your First Document. To learn the REST workflow end to end, see Document AI REST API Developer Guide.
Administration
Document AI is deployed one time per cluster as a central service that all applications share. An administrator deploys it as its own application. Processing capacity is three size-tier fleets (small, medium, and large); each fleet scales from the depth of its own work queue. The small fleet stays available; the medium and large fleets scale from zero and return to zero when idle.
All language model and embedding calls route through the C3 Agentic AI Platform's centralized model gateway: the single point of governance every platform service shares. The processing service itself stores no model provider credentials.
Every authenticated user automatically receives the DocumentAi.User role, which covers all document processing endpoints, so no per-user grants are required. The usage dashboard, which reports token consumption and cost across the service, requires the separate DocumentAi.Admin role.
An administrator configures the embedding model and the language models the service uses at deployment time. Any retriever that receives Document AI results must use the same embedding model and dimensions. A mismatch surfaces later as persistence or search errors, not at submission time.
Administrators can tune the following runtime settings:
| Setting | Default | Description |
|---|---|---|
maxRetries | 3 | Retry attempts before a run is marked FAILED. |
processingTimeout | 120 minutes | Time before an unresponsive run is considered stuck and retried. |
maxFileSizeBytes | 1 GiB | Per-file size gate applied at submission. |
smallMaxBytes | 50 MB | Upper bound for the small tier. Files at or below this size use the small fleet. |
mediumMaxBytes | 200 MB | Upper bound for the medium tier. Files above smallMaxBytes and at or below this use medium pods. |
largeMaxBytes | 1 GiB | Upper bound for the large tier and the maximum supported file size. Files above this are rejected. |
Concurrency and scaling bounds are also configurable at deployment time.