AI and Machine Learning Document Intelligence premium

Composed document model

Composed document model means an Azure AI Document Intelligence model that combines several custom document models behind one model identifier so different document types can be analyzed together. Teams use it to route invoices, purchase orders, forms, claims, and other document layouts to specialized extraction models without forcing applications to choose manually. In Azure work, operators usually see it in portal settings, deployment output, metrics, logs, and runbooks. The practical question is who owns it, what scope it affects, and what evidence proves it is working.

Back to glossary browser Open Microsoft Learn source
Aliases
No aliases mapped yet
Difficulty
Intermediate
CLI mappings
3
Last verified
2026-05-12

Microsoft Learn

A composed document model groups multiple Azure AI Document Intelligence custom models under one model ID so the service can select the appropriate model for analysis.

Microsoft Learn: Document Intelligence composed custom models2026-05-12

Technical context

Technically, Composed document model is a composed model resource created from existing custom models or document types and invoked through a single analyze request. Engineers verify it with service configuration, IDs, logs, metrics, request records, and deployment evidence. Important configuration includes included models, document type labels, training data quality, model versioning, resource endpoint, authentication, region, and application routing logic. Production reviews should capture owner, scope, region, identity, limits, recent changes, and diagnostics before changing behavior.

Why it matters

Composed document model matters because document automation can extract wrong fields at scale if model composition, confidence thresholds, or review routing are weak. The business impact is rarely abstract: users see slower workflows, missing data, failed automation, audit gaps, support delays, or unexpected cost when the term is misunderstood. A strong glossary entry gives architects, developers, security reviewers, and operators the same language for design reviews and incident handoffs. It connects Azure configuration to measurable objectives, ownership, rollback paths, and evidence, so teams treat it as an operational control rather than a portal label. That discipline helps teams make safer changes under pressure.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

You see Composed document model in Document Intelligence models, compose operations, classifier workflows, and extraction results when confirming component model IDs, document type routing, fields, and confidence values for release, audit, or incident evidence.

Signal 02

You see Composed document model during troubleshooting when documents route to the wrong extractor or fields disappear and operators must connect portal state, CLI output, logs, metrics, owners, and rollback notes.

Signal 03

You see Composed document model in architecture reviews when teams decide how multiple trained models serve one intake process, how evidence is gathered, and how it affects security, reliability, operations, cost, and performance.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

  • Route several invoice templates through one composed model ID.
  • Investigate low-confidence extraction for a new vendor layout.
  • Document model membership before retiring an older custom model.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

Procurement document routing

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

A Datum Manufacturing received different purchase-order layouts from suppliers and needed one intake workflow for accounts payable.

Business/Technical Objectives
  • Process five supplier layouts through one endpoint
  • Reduce manual document sorting by 60 percent
  • Route low-confidence fields to review
  • Maintain model-version evidence for audit
Solution Using Composed document model

Architects trained separate custom Document Intelligence models for high-volume supplier layouts, then created a composed document model exposed through one model ID. Purchase orders landed in Blob Storage and Event Grid triggered a Function to submit analysis requests. Results included selected document type, extracted fields, confidence, and bounding regions. Low-confidence totals or missing vendor IDs went to a review queue. Model IDs, training datasets, and approval records were stored with each workflow version so accounts payable could trace every extraction. The runbook captured owner, environment, approval link, rollback condition, and the exact Azure evidence operators had to collect before and after each change. A dashboard tracked adoption, exceptions, and operational signals so support, security, and finance teams could review outcomes without relying on informal notes.

Results & Business Impact
  • Manual sorting dropped 72 percent
  • Five supplier layouts used one application endpoint
  • Low-confidence reviews caught 18 percent of risky extractions
  • Audit reports included model version and training evidence
Key Takeaway for Glossary Readers

A composed document model simplifies applications while keeping specialized extraction quality for different document layouts.

Case study 02

Insurance claims packet intake

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Woodgrove Mutual handled claim packets containing police reports, repair estimates, and medical forms that required different extraction logic.

Business/Technical Objectives
  • Route three document families automatically
  • Shorten claim intake by two business days
  • Preserve confidence evidence for adjusters
  • Prevent sensitive documents from entering broad logs
Solution Using Composed document model

The AI team trained custom models for each claim document family and combined them into a composed model. The intake application submitted each uploaded document to the composed model and used the returned document type to populate the claim workspace. Extracted fields and confidence scores were stored in a secure database, while full documents stayed in private Blob Storage. Application Insights logged operation IDs and performance metrics but excluded document text. Adjusters received review tasks when confidence thresholds failed. The runbook captured owner, environment, approval link, rollback condition, and the exact Azure evidence operators had to collect before and after each change. A dashboard tracked adoption, exceptions, and operational signals so support, security, and finance teams could review outcomes without relying on informal notes.

Results & Business Impact
  • Claim intake time fell from four days to one
  • Automatic routing handled 81 percent of documents
  • Sensitive document text stayed out of telemetry
  • Adjuster review focused on low-confidence fields
Key Takeaway for Glossary Readers

Composed document models help regulated workflows automate routing without removing human review from uncertain extractions.

Case study 03

Public records form modernization

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Cityline Records modernized paper permit forms but had old and new templates circulating during a two-year transition.

Business/Technical Objectives
  • Support old and new templates together
  • Avoid forcing clerks to select a model
  • Track extraction accuracy by template
  • Reduce backlog from mailed forms
Solution Using Composed document model

Developers trained separate custom models for legacy and modern permit templates, then published a composed model used by the records portal. Uploaded forms were analyzed through one endpoint, and the selected document type determined which validation rules ran next. Confidence metrics, bounding regions, and reviewer corrections fed a monthly accuracy report. When a template changed, the team added a new component model rather than rewriting the portal. Clerks could override extraction results with an audit trail. The runbook captured owner, environment, approval link, rollback condition, and the exact Azure evidence operators had to collect before and after each change. A dashboard tracked adoption, exceptions, and operational signals so support, security, and finance teams could review outcomes without relying on informal notes. The team reviewed results after the pilot and kept the design in the standard platform checklist for future deployments.

Results & Business Impact
  • Backlog from mailed forms dropped 39 percent
  • Clerks no longer selected models manually
  • Template accuracy was measured monthly
  • New template onboarding avoided portal rewrites
Key Takeaway for Glossary Readers

Composed document models are practical when document diversity is real but applications need a stable analysis contract.

Why use Azure CLI for this?

Use CLI and SDK evidence to confirm the Azure AI resource, endpoint, model identifiers, storage, and operation results before changing document workflows.

CLI use cases

  • Confirm the Document Intelligence resource and endpoint used by an application.
  • Review model identifiers and analyze results during extraction-quality incidents.
  • Validate storage, identity, and diagnostic settings before production document intake.

Before you run CLI

  • Confirm the active tenant, subscription, resource group, workspace, account, or region before running commands.
  • Use least-privileged access and avoid storing secrets, prompts, certificates, tokens, or personal data in command output.
  • Know whether the command is read-only, mutating, cost-impacting, security-impacting, or destructive before production use.

What output tells you

  • Output confirms whether the live Azure configuration exists at the expected scope and matches the approved design.
  • Returned IDs, settings, metrics, timestamps, or logs help separate configuration drift from application behavior.
  • Differences between expected and actual state create evidence for rollback, escalation, audit, or owner follow-up.

Mapped Azure CLI commands

Document Intelligence operations

adjacent
az cognitiveservices account list --resource-group <resource-group>
az cognitiveservices accountdiscoverAI and Machine Learning
read-only Microsoft docs
az cognitiveservices account show --name <account-name> --resource-group <resource-group>
az cognitiveservices accountdiscoverAI and Machine Learning
read-only Microsoft docs
az cognitiveservices account create --name <account-name> --resource-group <resource-group> --kind <kind> --sku S0 --location <region>
az cognitiveservices accountprovisionAI and Machine Learning
cost-impacting Microsoft docs
az cognitiveservices account keys list --name <account-name> --resource-group <resource-group>
az cognitiveservices account keysdiscoverAI and Machine Learning
security-impacting Microsoft docs
az cognitiveservices account delete --name <account-name> --resource-group <resource-group>
az cognitiveservices accountremoveAI and Machine Learning
destructive Microsoft docs

Architecture context

Technically, Composed document model is a composed model resource created from existing custom models or document types and invoked through a single analyze request. Engineers verify it with service configuration, IDs, logs, metrics, request records, and deployment evidence. Important configuration includes included models, document type labels, training data quality, model versioning, resource endpoint, authentication, region, and application routing logic. Production reviews should capture owner, scope, region, identity, limits, recent changes, and diagnostics before changing behavior.

Security

Security for Composed document model starts with understanding document content, training datasets, model access, endpoint keys or identities, storage locations, extracted fields, logs, and downstream workflow permissions. Review identities, roles, secrets, network paths, data classification, logs, and who can change the setting. Prefer least privilege, private access when available, managed identity or protected credentials, and audit evidence. Watch for broad permissions, sensitive data in logs, shared keys, public endpoints, stale owners, and exceptions without expiry. Production use should include an approved owner, access boundary, alert routing, and a revocation process operators can execute during an incident. Security reviewers should tie every exception to risk acceptance and expiry.

Cost

Cost for Composed document model comes from analysis transactions, training effort, storage for documents, review labor, retries, downstream workflow execution, and maintaining unnecessary component models. Direct costs may be obvious, but indirect costs can appear as retries, duplicate processing, idle capacity, data movement, investigation time, or support effort. Review budgets, tags, usage metrics, quota, retention, SKU, and forecasts before enabling or scaling it. Connect spend to business-unit ownership and expected workload value. Define normal usage, alert thresholds, cleanup rules, and exception approval before the feature becomes a hidden default across environments. Finance teams need evidence that the cost aligns to real demand, not leftover experiments.

Reliability

Reliability for Composed document model depends on component model availability, document classification accuracy, confidence thresholds, fallback review queues, model versioning, and API operation handling. Operators should know the expected failure mode, dependency chain, recovery target, and whether retries, failover, reprocessing, or manual approval are required. Monitor health, latency, quota, backlog, error rates, stale state, and downstream failures. Test behavior during maintenance, regional incidents, expired credentials, schema changes, and burst traffic. Runbooks should explain how to validate current state, preserve evidence, reduce blast radius, and restore service without duplicate work or data loss. Reliability reviews should include the human handoff path, not only platform health.

Performance

Performance for Composed document model is about analysis latency, document size, page count, model routing accuracy, API throughput, regional endpoint placement, and review queue delay. Measure signals that reflect user or workload experience, such as latency, throughput, request units, node startup time, model response time, queue depth, cache behavior, or throttled operations. Avoid tuning one setting in isolation when identity, network path, partitioning, model size, region, or downstream capacity may be the real bottleneck. Compare baseline and peak results after changes, then document which limit would be reached first as demand grows. Keep tests close to production patterns. That evidence helps teams scale intentionally instead of guessing during incidents.

Operations

Operationally, Composed document model needs clear ownership, naming, tagging, change records, and repeatable verification. Teams should know where it appears, which commands or queries prove state, which dashboard shows health, and what is safe to change during business hours. Keep examples, approvals, rollback notes, and exception records with the service runbook rather than personal notes. For production changes, capture before-and-after evidence, including resource IDs, region, tenant, policy assignment, deployment version, and linked services. Review stale resources and permissions regularly. Escalation contacts should stay current as teams reorganize. This prevents tribal knowledge from becoming the only support path. It also helps new operators support the service with confidence.

Common mistakes

  • Composing weak component models and expecting routing to fix poor training data.
  • Ignoring confidence thresholds and sending low-quality extractions directly downstream.
  • Changing model IDs without updating workflow routing and approval runbooks.