Composed document model - Azure Glossary

Understand the concept

In plain English

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.

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.

Official wording and source

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.

Open Microsoft Learn

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.

Exam context

Compare with

Azure AI Vision Azure AI services

Where it is used

Where you see it

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.
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.
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.

Common situations

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.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 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.

Goals

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

Approach 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.

Potential outcomes

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

What to learn

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

Scenario 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.

Goals

Route three document families automatically
Shorten claim intake by two business days
Preserve confidence evidence for adjusters
Prevent sensitive documents from entering broad logs

Approach 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.

Potential outcomes

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

What to learn

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

Scenario 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.

Goals

Support old and new templates together
Avoid forcing clerks to select a model
Track extraction accuracy by template
Reduce backlog from mailed forms

Approach 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.

Potential outcomes

Backlog from mailed forms dropped 39 percent
Clerks no longer selected models manually
Template accuracy was measured monthly
New template onboarding avoided portal rewrites

What to learn

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

Azure CLI

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

Useful for

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 a command

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 the 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 commands

Document Intelligence operations

adjacent

az cognitiveservices account list --resource-group <resource-group>

az cognitiveservices accountdiscoverAI and Machine Learning

az cognitiveservices account show --name <account-name> --resource-group <resource-group>

az cognitiveservices accountdiscoverAI and Machine Learning

az cognitiveservices account create --name <account-name> --resource-group <resource-group> --kind <kind> --sku S0 --location <region>

az cognitiveservices accountprovisionAI and Machine Learning

az cognitiveservices account keys list --name <account-name> --resource-group <resource-group>

az cognitiveservices account keysdiscoverAI and Machine Learning

az cognitiveservices account delete --name <account-name> --resource-group <resource-group>

az cognitiveservices accountremoveAI and Machine Learning

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.