Projects

Projects are the central configuration unit in DocAI Fabric. Each project defines how a specific type of document flow is processed, including what document types to expect, what data to extract, and how the processing pipeline runs.

Project Structure

A project contains:

• Document Classes: The types of documents this project handles
• Extraction Fields: What data to extract from each document class
• Workflow Configuration: The processing pipeline settings
• Settings: OCR, classification, and extraction parameters

All of this is edited in the project's draft. Production runs a published version of it, so configuration changes only reach production once the project is published. See Versions and Publishing.

Creating a Project

1. Navigate to the main dashboard
2. Click New Project
3. Enter a project name and description
4. Configure your first document class

When to Create a New Project vs. Add to an Existing One

A project represents a single document processing pipeline. The key question is: do these documents arrive together or separately?

Use the Same Project When

• Different document types appear mixed together in the same uploaded files or batches (e.g., invoices and receipts scanned in one PDF)
• The documents share the same processing workflow (same review process, same export destination, same team)
• You need the system to split and classify documents automatically from combined uploads

Example

An accounts payable team receives mixed scans containing invoices, credit notes, and purchase orders. These all belong in one project with three document classes, with splitting and classification enabled.

Create a Separate Project When

• The document types come from completely different sources or workflows and will never appear in the same upload
• Different teams or departments handle them independently
• They have different review processes, export destinations, or quality requirements
• You want independent settings (confidence thresholds, OCR options, etc.) for each document flow

Example

One team processes bank statements, another processes tax invoices. These are separate document flows with different reviewers and different downstream systems. Each should be its own project.

Rule of Thumb

If documents arrive in the same envelope (physical or digital), they belong in the same project. If they arrive through different channels, separate projects are cleaner.

Document Classes

Document classes define the categories of documents your project processes. For example, an accounts payable project might have:

• Invoice
• Purchase Order
• Receipt
• Credit Note

What Makes a Distinct Document Type?

A document type is typically defined by two things:

1. The set of fields to extract: If two documents require different extraction fields, they are different document types.
2. The set of validation rules to apply: If different business rules apply (different required fields, different format validations, different cross-field checks), they are different types.

Same fields + same rules = same type. Even visually different documents are the same class if they share the same fields and validation logic. Variations within a type can be captured as field values rather than separate classes.

Example

A "Standard Invoice" and a "Proforma Invoice" both have invoice number, vendor, date, line items, and total. They follow the same validation rules. Instead of two classes, use one "Invoice" class and add a field like "Invoice Subtype" to distinguish them.

Different fields or different rules = different type. If two documents need fundamentally different data extracted or different validation logic, they should be separate classes.

Example

An "Invoice" needs vendor, line items, and totals. A "Packing Slip" needs item descriptions, quantities, and tracking numbers. Different fields → different document classes.

Quick Reference

Scenario	Recommendation
Same fields, same rules, different layout	One class: the AI handles layout variation
Same fields, same rules, different issuer	One class: add an "Issuer" field
Same core fields, a few extra fields for some variants	One class: make the extra fields optional
Fundamentally different fields	Separate classes
Same fields but different validation rules	Separate classes
Regional variants (US invoice vs. EU invoice)	Usually one class, unless field sets diverge significantly

Avoid Over-Classification

Creating too many classes increases classification errors and adds configuration overhead. Start with broader categories and split only when the field sets truly diverge.

Too granular: "Vendor A Invoice", "Vendor B Invoice", "Vendor C Invoice"
Better: "Invoice" with a "Vendor Name" extraction field

Managing Classes

Classes are edited in two dialogs, both working on the project's draft:

• Document Classes is the full editor: name, description (what the classifier reads), hotkey, classification guidelines, and class discovery. Open it from the Classify activity on the Workflow page (Manage classes) or from the Transaction Viewer's data panel (the gear menu, Document Classes). Each class row has Duplicate and Delete icons; expand a row to edit it; Add class creates one.
• Extraction Fields is where you work on a class's fields. Its class list on the left also carries the class-level actions: hover a class for Duplicate and Delete, and use Add class at the bottom of the list to create one by name (set its description afterwards in Document Classes). Open it from the Extract activity or from the same gear menu in the viewer.

Deleting a class shows what goes with it before you confirm: its fields, memory examples, and the rules that would be deleted or narrowed. Documents already classified as that class are not touched; they show as Unknown.

Duplicating a Class

When a new document type is mostly like one you already have (a Credit Note next to an Invoice, a Sea Waybill next to a Bill of Lading), start from a copy instead of building it field by field. Duplicate is on each class in both dialogs above; give the copy a name and confirm. The dialog tells you beforehand how many fields and rules the copy will get.

The copy gets:

• the class's extraction fields, including groups, tables, layout, choice options and extraction settings
• the per-class extraction guidelines and split fields
• a copy of every field-level and document-level validation rule bound to the class, scoped to the new class

It does not get documents, memory examples, classification rules or transaction-level rules: those span classes, so any that mention the source are listed after the copy for you to extend by hand. The source class is left exactly as it was, and the copy is independent from then on: editing a field or a rule in one does not change the other.

Give the copy a real name and update its description right away. Both are part of the classification prompt, and two classes with the same description compete for the same documents. Then remove or add the fields that differ.

Class Fields

Each document class has its own set of extraction fields:

{
  "class_name": "Invoice",
  "fields": [
    {
      "name": "Invoice Number",
      "type": "text",
      "required": true,
      "description": "Unique invoice identifier"
    },
    {
      "name": "Total Amount",
      "type": "number",
      "required": true,
      "description": "Total amount due"
    }
  ]
}

Field Types

A field's type describes the shape of the data, not its format. There are four:

Type	Description	Example
text	A single value. This is the default, and it is the right type for dates, numbers and currency amounts too.	Invoice number, invoice date, total amount
choice	A value picked from a fixed list of options. Can allow one or several.	Payment terms, a yes/no checkbox, a status
group	Related single-value fields that appear once, shown together as a section.	A Supplier group holding Name, Address and Tax ID
repeating_group	A table or list whose rows repeat.	Invoice line items

Dates, numbers and currency are text fields

There is no separate date or currency type. A date or an amount is extracted as text and then put into the form you want by a normalization rule, which is also what lets one project accept 15/01/2026 and Jan 15, 2026 and store both the same way. See Business Rules.

Writing Effective Field Descriptions

The field description is the single most important factor for extraction quality. It guides the AI on what to look for and where.

Good description practices:

• Be specific: "The unique invoice identifier, usually starting with 'INV-'"
• Include location hints: "Usually found in the top-right corner of the first page"
• Mention expected format: "Date in format MM/DD/YYYY"
• Clarify ambiguity: "The total amount due including tax, not the subtotal"

Required vs Optional Fields

• Required: Field must have a value; missing values are flagged for review
• Optional: Field may be empty; no warning if not found

Use required fields for critical data that must always be present (e.g., invoice number, total amount). Use optional fields for data that may not exist on every document (e.g., PO number, discount).

Repeating Groups (Tables)

For extracting tabular data with multiple rows, define a repeating group with sub-fields:

• Item Description (text)
• Quantity (integer)
• Unit Price (currency)
• Line Total (currency)

Each row in the table becomes one entry in the group. Describe the table structure clearly so the AI knows what to look for.

Extraction Confidence

Each extracted value includes a confidence score:

• High (> 0.8): Value clearly found in document
• Medium (0.5-0.8): Probable match, may need verification
• Low (< 0.5): Uncertain extraction, should be reviewed

Values with low confidence are highlighted in the Transaction Viewer for easy review.

Choosing the Right Processing Mode

When creating a project, configure the processing stages to match your document flow.

Split + Classification + Extraction

Use when: Uploaded files may contain multiple documents of different types mixed together.

• Split detects document boundaries within multi-page files
• Classification identifies each document's type
• Extraction pulls data based on the classified type

Example: A batch scanner produces PDFs containing a mix of invoices, receipts, and delivery notes.

Classification + Extraction (No Split)

Use when: Each uploaded file contains exactly one document, but documents may be of different types.

• Each file is treated as one document (no boundary detection)
• Classification determines the document type
• Extraction uses the classified type's field definitions

Example: Users upload individual PDFs; each is one document, but could be an invoice, a contract, or a receipt.

Extraction Only (No Split, No Classification)

Use when: All documents are the same known type and each file contains exactly one document.

• Each file is one document, all assigned to a single class
• Extraction runs using the single configured document class's fields

Example: A process that only ever receives invoices, one per file.

Decision Flowchart

Ask yourself three questions to pick the right mode:

1. Can a single file contain multiple documents? → Enable Split
2. Do you process more than one type of document? → Enable Classification
3. What data do you need to extract? → Extraction is always enabled: this is the core value

Project Settings

Project settings control the behavior of each processing step. Settings follow an inheritance chain:

Project Settings → Workflow Activity Config → Runtime Overrides

This means you can set defaults at the project level and override them per-workflow or per-transaction.

Key Settings

Setting	Description	Default
OCR Engine	Which OCR engine reads the pages. Which engines a deployment offers varies; see OCR.	None (no OCR) until one is chosen
Classification Model	The model the Classify step uses.	The tenant's default model
Extraction Model	The model the Extract step uses.	The tenant's default model
Confidence Threshold	Below this, a result is flagged for review rather than accepted. Split, classification and extraction each have their own.	0.7

Models are not hard-coded: the deployment's model catalog decides which are available and which is the default, and a step can override it. See Models.