# How to Add and Configure Custom Classification Models for Domain-Specific Document Types in AWS IDP

> Learn how to add custom classification models for specific documents in AWS IDP. Train models in SageMaker or Bedrock and configure them easily.

- Repository: [aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws)
- Tags: how-to-guide
- Published: 2026-02-25

---

**You can add custom classification models to the AWS Intelligent Document Processing (IDP) solution by training a domain-specific model in Amazon SageMaker or Amazon Bedrock, then referencing its ARN or model ID in the IDP configuration file using the `customClassificationModelArn` or `customClassificationModelId` fields.**

The AWS IDP solution provides a flexible framework for processing documents at scale, but generic classification models often struggle with specialized domains like banking statements, insurance forms, or legal contracts. By configuring **custom classification models for domain-specific document types**, you can replace default models with ones trained on your specific document taxonomy, ensuring higher accuracy and automated routing.

## Understanding Classification Backends

The IDP solution supports three primary backends for document classification, each requiring different configuration parameters:

- **`bedrock`** – Uses Amazon Bedrock foundation models (Claude, Nova, Titan) via model IDs
- **`udop`** – Uses Amazon SageMaker endpoints running the UDOP (Universal Document Processing) model
- **`bda`** – Uses Bedrock Data Automation (Pattern 1 only)

Your choice of backend determines which configuration field you must populate: `customClassificationModelId` for Bedrock or `customClassificationModelArn` for SageMaker endpoints.

## Step 1: Train and Deploy Your Domain-Specific Model

Before configuring the IDP stack, you must have a deployed model ready in your AWS account.

For **Amazon Bedrock**, note the model ID (e.g., `anthropic.claude-3-sonnet-20240229` or your custom provisioned model ARN).

For **SageMaker UDOP**, deploy your fine-tuned model to a SageMaker endpoint and record the full ARN:

```bash
arn:aws:sagemaker:us-east-1:123456789012:endpoint/finance-doc-classifier

```

No code changes are required in the IDP repository at this stage; the model lives entirely within your AWS account infrastructure.

## Step 2: Configure the Custom Model in IDP

The IDP solution reads classification settings from a YAML configuration file. You must edit this file to point to your custom model using the appropriate fields documented in [`docs/configuration.md`](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/blob/main/docs/configuration.md).

### Pattern 2: Bedrock Configuration Example

For Pattern 2 stacks using Amazon Bedrock, set `classificationMethod` to `bedrock` and provide the model ID:

```yaml
classification:
  classificationMethod: bedrock
  customClassificationModelId: "anthropic.claude-3-sonnet-20240229"

```

You can find sample configurations in [`config_library/pattern-2/bank-statement-sample/config.yaml`](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/blob/main/config_library/pattern-2/bank-statement-sample/config.yaml), which demonstrates the structure of the `classification` block.

### Pattern 3: SageMaker UDOP Configuration Example

For Pattern 3 stacks using SageMaker endpoints, set `classificationMethod` to `udop` and provide the endpoint ARN:

```yaml
classification:
  classificationMethod: udop
  customClassificationModelArn: "arn:aws:sagemaker:us-east-1:123456789012:endpoint/finance-doc-classifier"

```

The `customClassificationModelArn` field must contain the full SageMaker endpoint ARN, not just the endpoint name.

## Step 3: Deploy or Update the IDP Stack

Once your configuration file contains the custom model reference, apply it to your IDP stack.

### New Deployment

Use the `idp-cli` tool to deploy a new stack with your custom configuration:

```bash
idp-cli deploy \
  --stack-name my-idp-stack \
  --pattern pattern-2 \
  --custom-config ./my-config.yaml \
  --wait

```

Documentation for the CLI is available in [`docs/idp-cli.md`](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/blob/main/docs/idp-cli.md).

### Update Existing Stack

To update a running stack without full redeployment, invoke the **UpdateConfiguration** Lambda function directly. This Lambda, located at [`src/lambda/update_configuration/index.py`](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/blob/main/src/lambda/update_configuration/index.py), validates the custom model fields and writes them to the DynamoDB **Configuration** table:

```bash
aws lambda invoke \
  --function-name UpdateConfigurationFunction \
  --payload '{"stackName":"my-idp-stack","customConfigPath":"s3://my-bucket/my-config.yaml"}' \
  response.json

```

All Lambda workers (OCR, classification, extraction) read from this DynamoDB table, so the new model takes effect immediately across the pipeline.

## Verification and Testing

After deployment, verify that your custom classification model is active by running a test batch:

```bash
idp-cli run-inference \
  --stack-name my-idp-stack \
  --input-s3-uri s3://my-bucket/test-documents/

```

Check the `ClassificationResult` payload in the output. It should contain your domain-specific classes (e.g., "BankStatement", "InsuranceClaim") rather than generic categories. The IDP UI automatically reflects these new classes because the classification Lambda writes results to DynamoDB immediately after inference.

## Summary

- **Train and deploy** your domain-specific model in SageMaker or Bedrock before configuring the IDP stack.
- **Edit the configuration YAML** to set `classificationMethod` (`bedrock`, `udop`, or `bda`) and provide the model identifier in `customClassificationModelId` or `customClassificationModelArn`.
- **Deploy via `idp-cli`** or update existing stacks using the `UpdateConfigurationFunction` Lambda to write settings to the DynamoDB Configuration table.
- **Verify** by running `idp-cli run-inference` and inspecting the `ClassificationResult` for your custom document classes.

## Frequently Asked Questions

### What is the difference between `customClassificationModelArn` and `customClassificationModelId`?

The `customClassificationModelArn` field accepts a full Amazon Resource Name (ARN) for Amazon SageMaker endpoints (e.g., `arn:aws:sagemaker:us-east-1:123456789012:endpoint/my-classifier`), while `customClassificationModelId` accepts a model identifier string for Amazon Bedrock (e.g., `anthropic.claude-3-sonnet-20240229`). Use the ARN field for Pattern 3 (SageMaker UDOP) and the ID field for Pattern 2 (Bedrock).

### Can I switch from a default model to a custom model without redeploying the entire stack?

Yes. You can update the configuration dynamically by invoking the `UpdateConfigurationFunction` Lambda, which is implemented in [`src/lambda/update_configuration/index.py`](https://github.com/aws-solutions-library-samples/accelerated-intelligent-document-processing-on-aws/blob/main/src/lambda/update_configuration/index.py). This Lambda reads your updated YAML configuration from Amazon S3, validates the custom model fields, and writes the new settings to the DynamoDB Configuration table. All running Lambda workers automatically pick up these changes on their next execution.

### Which IDP pattern should I use for custom classification models?

Pattern 2 supports both Amazon Bedrock and Amazon SageMaker custom models, making it the most flexible choice for domain-specific classification. Pattern 3 exclusively uses SageMaker UDOP endpoints and requires the `customClassificationModelArn` field. Pattern 1 only supports Bedrock Data Automation (BDA) and does not accept custom model ARNs or IDs for classification. Choose Pattern 2 if you need Bedrock foundation models or want flexibility between backends.