AI and Machine Learning Document Intelligence premium

Document Intelligence layout model

Document Intelligence layout model is a prebuilt Document Intelligence model that extracts text, tables, selection marks, structure, and layout information without custom training. In Azure, it helps teams understand document structure, bootstrap custom model work, support search indexing, and extract tables or text when field-specific training is unnecessary. Plainly, it is a named part of the platform that operators can point to when they need ownership, evidence, and a safe change path. A useful glossary entry should explain where it appears, what it controls, what depends on it, and which signal proves it is healthy.

Back to glossary browser Open Microsoft Learn source
Aliases
layout model, prebuilt layout model, document layout analysis, layout analysis model
Difficulty
fundamentals
CLI mappings
5
Last verified
2026-05-13

Microsoft Learn

The Document Intelligence layout model is a prebuilt model that extracts document text, tables, selection marks, structure, and layout information without custom training.

Microsoft Learn: Document Intelligence layout model2026-05-13

Technical context

Technically, Document Intelligence layout model appears in prebuilt-layout model calls, Document Intelligence Studio tests, analyze result JSON, pages, tables, lines, words, selection marks, and bounding regions and interacts with Azure AI Document Intelligence, Azure AI Search, Azure Storage, and Azure AI services account. Configuration is reviewed through model ID prebuilt-layout, page selection, input format, and API version, while operators validate live state through extracted text, table structures, selection marks, and page layout. Scope determines which permissions, logs, API calls, commands, and dependencies matter.

Why it matters

Document Intelligence layout model matters because a small Azure design choice can shape customer experience, security posture, operational visibility, and incident recovery. When it is shallowly documented, teams may troubleshoot the wrong DNS record, AI endpoint, model, storage container, policy assignment, deployment stack, or monitoring signal while the real dependency remains hidden. In enterprise Azure work, the value is shared language: application, platform, security, data, finance, and operations teams can discuss the same object without guessing. That reduces incident time, improves audit quality, clarifies ownership, and makes production changes safer because failure modes and graph relationships are visible before change.

Where you see it

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

Signal 01

In analyze output, the layout model appears as pages, paragraphs, tables, lines, words, selection marks, spans, and bounding regions during production review when operators need repeatable evidence.

Signal 02

In search pipelines, it appears when extracted text and tables from PDFs are indexed for retrieval or knowledge mining during production review when operators need repeatable evidence.

Signal 03

In custom model projects, it appears as the structural foundation used to label forms and understand document regions before training during production review when operators need repeatable evidence.

When this becomes relevant

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

  • Extract tables and text from PDFs without training a model.
  • Index document structure for enterprise search.
  • Prepare labeling work for a custom model project.

Real-world case studies

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

Case study 01

Document Intelligence layout model in action for records management

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

Scenario

StoneRiver Archives, a records management organization, needed to address archivists needed searchable tables and text from decades of scanned municipal reports. The architecture team used Document Intelligence layout model as the control point for a measurable production improvement.

Business/Technical Objectives
  • Extract document structure without training first
  • Index tables and headings for search
  • Keep manual transcription under 10 percent of documents
Solution Using Document Intelligence layout model

The team used the prebuilt layout model to analyze scanned reports and return text, tables, lines, and selection marks. Results were normalized into searchable fields and indexed in Azure AI Search. Documents with poor OCR confidence or broken tables moved to manual review, while successful output retained source-page references for audit. The team validated Document Intelligence layout model in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders.

Results & Business Impact
  • Searchable archive coverage reached 91 percent
  • Manual transcription was limited to 8 percent of documents
  • Researchers found table data without opening original PDFs
Key Takeaway for Glossary Readers

The layout model is a strong starting point when structure matters more than a custom field schema.

Case study 02

Document Intelligence layout model in action for civil engineering

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

Scenario

BrightLine Engineering, a civil engineering organization, needed to address project teams could not quickly review specification PDFs with dense tables and checklists. The architecture team used Document Intelligence layout model as the control point for a measurable production improvement.

Business/Technical Objectives
  • Extract checklist and table structure from specifications
  • Reduce document review time by 35 percent
  • Avoid custom training for one-off project documents
Solution Using Document Intelligence layout model

Engineers submitted specification PDFs to the layout model and parsed tables, headings, and selection marks into a review dashboard. The system highlighted missing checklist items and linked extracted text back to source pages. Because documents varied by project, the team avoided custom training and relied on layout extraction plus rule-based validation. The team validated Document Intelligence layout model in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Document Intelligence layout model in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Results & Business Impact
  • Specification review time dropped 38 percent
  • Missing checklist items were flagged before bid review
  • No model-training backlog was created for one-off documents
Key Takeaway for Glossary Readers

Layout extraction is practical when teams need document structure but not a long-lived custom model.

Case study 03

Document Intelligence layout model in action for education technology

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

Scenario

VistaLearn Publishing, a education technology organization, needed to address curriculum teams needed to convert worksheets into searchable learning content. The architecture team used Document Intelligence layout model as the control point for a measurable production improvement.

Business/Technical Objectives
  • Extract text and tables from worksheets
  • Preserve page and region context
  • Improve content tagging speed by 40 percent
Solution Using Document Intelligence layout model

The platform analyzed worksheets with the layout model, stored page-aware text and table output, and sent normalized content to a tagging workflow. Editors reviewed only ambiguous sections, while source-page references made it easy to verify extracted passages. The data was indexed for search and curriculum recommendations. The team validated Document Intelligence layout model in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Document Intelligence layout model in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Results & Business Impact
  • Content tagging speed improved 44 percent
  • Editors retained source-page context for quality checks
  • Search relevance improved for table-heavy worksheets
Key Takeaway for Glossary Readers

The layout model turns unstructured pages into structured building blocks for search, review, and content workflows.

Why use Azure CLI for this?

CLI checks for Document Intelligence layout model are useful because they turn portal assumptions into repeatable evidence. Start with read-only commands that show scope, state, owner, permissions, destinations, configuration, metrics, operation status, or drift evidence. Run mutating, security-impacting, or cost-impacting commands only after approval, because the wrong scope can affect production availability, spend, access, or document processing.

CLI use cases

  • Extract tables and text from PDFs without training a model.
  • Index document structure for enterprise search.
  • Prepare labeling work for a custom model project.

Before you run CLI

  • Run az account show, confirm tenant and subscription, and verify the signed-in operator has approved read access for the exact Azure scope.
  • Confirm resource group, resource name, endpoint, environment, owner, data classification, and change record before collecting evidence or modifying production configuration.
  • Prefer read-only commands first; review any command that changes DNS records, AI resources, keys, private networking, model configuration, policy compliance, or deployment state before running it.

What output tells you

  • Whether the target DNS zone, Document Intelligence resource, model, operation, field extraction path, policy result, deployment stack, or monitored resource exists at the expected scope.
  • Which state, endpoint, record set, model ID, operation result, field confidence, identity assignment, diagnostic route, policy compliance result, or drift signal is visible to the operator.
  • Whether the issue is wrong scope, stale DNS, missing access, expired keys, unsupported model choice, throttling, weak training data, private endpoint misrouting, or configuration drift.

Mapped Azure CLI commands

Document Intelligence layout model operational checks

direct
az cognitiveservices account show --name <account> --resource-group <resource-group>
az cognitiveservices accountdiscoverAI and Machine Learning
read-only Microsoft docs
az rest --method GET --url <operation-location-url>
az restdiscoverAI and Machine Learning
read-only Microsoft docs
az monitor metrics list --resource <document-intelligence-resource-id> --metric Transactions
az monitor metricsdiscoverAI and Machine Learning
read-only Microsoft docs
az monitor diagnostic-settings list --resource <document-intelligence-resource-id>
az monitor diagnostic-settingsdiscoverAI and Machine Learning
read-only Microsoft docs
az role assignment list --scope <document-intelligence-resource-id> --output table
az role assignmentdiscoverAI and Machine Learning
read-only Microsoft docs

Architecture context

Document Intelligence layout model belongs to AI and Machine Learning architecture decisions where identity, monitoring, cost ownership, reliability, and production support need shared evidence.

Security

Security for Document Intelligence layout model starts with least privilege, trusted configuration, and evidence that access matches workload risk. Review raw document handling, result storage access, sensitive text exposure, private endpoint use, and diagnostic redaction before approving production use. A common failure is assuming that a successful deployment, resolved name, model output, or dashboard proves the configuration is safe. Use Microsoft Entra groups, managed identities, RBAC, private connectivity, diagnostic logging, source-controlled definitions, and approval records where applicable. Keep exceptions ticketed, time-bounded, and owned. For regulated workloads, align the term with classification, retention, break-glass, and incident-response procedures. Remove broad access, stale keys, public endpoints, unreviewed contributors, and undocumented exception paths before Document Intelligence layout model becomes an incident path.

Cost

Cost for Document Intelligence layout model appears through service transactions, analyzed pages, storage use, diagnostic retention, private networking, policy remediation, deployment reruns, support time, and the downstream work triggered by bad configuration. Review pages analyzed, search indexing volume, manual table extraction savings, failed scan rework, and retention cost before expanding production use. Some costs are direct, such as page analysis, retained logs, storage operations, or duplicated resources; others are indirect, such as failed releases, repeated troubleshooting, emergency rework, and audit remediation. Tag related resources, monitor usage, and separate exploratory work from production. A cost review should connect spend to a real owner and measurable value.

Reliability

Reliability for Document Intelligence layout model depends on repeatable configuration, tested dependencies, and clear failure signals. Watch document quality, OCR readability, table structure complexity, page ordering, and fallback review because drift often appears later as unresolved names, failed document processing, missing model results, blocked private endpoints, false compliance evidence, or slow recovery. Use lower environments, source-controlled definitions where possible, deployment validation, monitoring, and rollback notes before changing production. Operators should know which endpoint, DNS path, model, storage dependency, policy, or downstream application fails first and which metric or log proves the failure. The goal is predictable recovery: detect Document Intelligence layout model drift, preserve service, restore safely, and explain the incident without guessing.

Performance

Performance for Document Intelligence layout model depends on workload shape, service limits, data volume, network path, API behavior, diagnostic destination, policy evaluation, and the monitoring path used to confirm success. Review page count, image resolution, table complexity, result size, and downstream parsing time before increasing capacity or retrying blindly. The better fix might be correcting DNS TTLs, reducing document size, choosing the right model, improving training data, tuning request concurrency, or repairing drift at the source. Measure under representative production conditions. Operators should connect symptoms to evidence: latency, throttling, backlog, failed operations, stale records, low confidence, or noncompliance. Good performance work ties Document Intelligence layout model measurements to user impact and avoids hiding design issues behind larger resources.

Operations

Operations for Document Intelligence layout model should focus on ownership, observability, and safe repeatability. Standardize names, tags, owner groups, environment labels, diagnostic destinations, runbook links, approval records, and change windows so support teams do not reverse-engineer the platform during incidents. Use read-only CLI, API, policy, diagnostic, or portal checks first, then compare live state with intended configuration. For production, connect alerts, audit events, cost records, graph links, and release notes to the same term. The support question should be simple: who owns it, what changed, and what proves the current state?. Capture owner, scope, evidence, and recovery procedure before changing Document Intelligence layout model in a production environment.

Common mistakes

  • Changing production before checking the exact Azure scope, owner, dependency, data sensitivity, and rollback or recovery procedure.
  • Treating a portal screenshot as enough evidence when CLI output, activity logs, diagnostics, API responses, and source-controlled configuration are repeatable.
  • Assuming a familiar name proves the correct resource when tenants, subscriptions, DNS zones, AI resources, models, storage containers, and policies can look similar.