Built Technologies 在 AWS 上构建 AI 驱动的文档智能解决方案，为房地产金融全生命周期的智能体提供支持

房地产领域的文档处理复杂且高度依赖人工，影响着大规模的关键业务决策，因此是自动化的绝佳切入点。Built Technologies 是一家房地产金融软件提供商，处理着超过 5000 亿美元的房地产项目。该公司在 Amazon Bedrock 和 AWS 智能文档处理（IDP）加速器上部署了一个 AI 驱动的文档处理引擎。该引擎现已成为贯穿房地产全生命周期的智能体产品的基础。在这篇文章中，我们将分享房地产领域对 AI 驱动的文档智能的需求，并深入探讨其架构实现。

房地产金融的运行依赖文档：提款包、贷款协议、发票、保险凭证、检查报告以及数十种其他文件。每份文件都包含贷方和利益相关方需要审查、验证并采取行动的信息。这些文档通常篇幅较长、格式不统一、领域性强，难以用传统自动化手段处理。

对 Built 而言，文档智能不是后台工具，而是一项横向的 AI 能力，它坐落在贯穿房地产金融全生命周期的新一代智能体产品的最底层。无论智能体是在审查建筑提款、分析贷款协议、验证保险覆盖范围、总结发行备忘录，还是在识别投资组合中的例外情况，都需要相同的核心能力：能够结合上下文、准确且可追溯地理解文档。

为了构建这一基础，Built 与 AWS 生成式 AI 创新中心（GenAIIC）、AWS 合作伙伴 AND Digital 以及 AWS 客户团队合作，打造了一个可扩展的 AI 驱动的文档处理引擎。

其成果是一个可复用的文档智能方案，能够对复杂房地产金融文档进行分类、拆分、提取、评估和推理。它将过去需要数天的工作流缩短到分钟级，支持数百种文档类型，并为技术团队和行业专家提供了共同构建和改进文档处理器的共享环境。

为什么房地产金融需要 AI 驱动的文档智能

房地产金融文档密集、碎片化且高度依赖上下文。单笔交易或单个资产就可能涉及数百乃至数千页文档，这些文档由不同参与方在资产生命周期的不同阶段、以不同格式生成。

有些文档是标准化的，比如 ACORD 25 保险凭证 或政府表格。其他文档则变化极大，如发行备忘录、贷款协议、评估报告、基于 Excel 的财务模型以及计划和规格说明。许多文档包含嵌套表格、扫描页、嵌入式图像、不一致的标签、法律语言、手写批注以及借方或贷方特有的术语。

Built 现有的文档处理能力已帮助公司从人工操作转向对多种文档类型的自动提取。团队建立了 26 个处理器，利用光学字符识别（OCR）和传统机器学习（ML）进行提取、拆分和分类。对于那些字段明确、布局可预测的狭义用例，这种方法行之有效。

但随着 Built Technologies 在房地产全生命周期中扩展其 AI 路线图，团队需要更灵活、更智能的解决方案。他们需要一个能支持 250 种以上文档类型、处理数百万份文档，并驱动能够对文档进行推理而不仅仅是提取文本的智能体的解决方案。

Built 面临几项挑战：

• 文档数量和多样性：Built 处理超过 250 种文档类型，涵盖建筑贷款、房地产金融、资产管理、合规和投资组合等工作流。单份文档可能超过 500 页。
• 复杂且不一致的文档结构：许多文档包含嵌套表格、嵌入式图像、扫描页、自定义布局和非标准术语。
• 依赖上下文的提取：重要信息往往是隐含的，分散在多个章节中，或以领域特定语言表达，而不是呈现为清晰标记的字段。
• 高置信度要求：Built 要求在分类和提取工作流中达到 95% 以上的置信度，以支持金融和合规敏感流程的生产级使用。
• 规模与可扩展性：Built 需要一种不仅能支持单一产品工作流，而且能支持当年陆续推出的众多智能体 AI 产品的解决方案。

目标是将文档理解打造成 Built 产品生态系统中一个可复用的 AI 能力。

从基于 OCR 的提取到智能体式文档理解

传统 OCR 和基于机器学习的文档提取通常通过识别文本并将其匹配到预期字段、标签、布局或先前模板来工作。这对于结构化文档可能有效，但当任务需要判断、上下文或领域推理时，它就受到了局限。例如，查找贷款金额、发票号码或保单到期日可能相对是直接提取任务，这些字段通常明确、有标签且位于可预测的文本附近。然而，在贷款协议中寻找保证条款则不同。

保证条款通常不会出现在一个明确标着“保证条款”的简单表格中。它们可能分布在冗长协议的多个章节，可能嵌入在法律语言里，通过引用其他章节来定义，或者以借款人义务、限制、报告要求、财务门槛、违约触发条件和补救措施等形式表达。用关键词搜索“保证条款”可能找不到实质内容。传统提取模型或许能找到这个词，但无法理解其背后的义务。

智能体式文档工作流可以以不同的方式处理问题。该系统不是仅从文本中提取字段，而是可以结合上下文来解读文档。它能识别相关章节，对定义和义务进行推理，区分需求和例外情况，提取结构化输出，并提供支持性证据供审查。

对于一份贷款协议，智能体工作流可以执行以下操作：

1. 识别文档类型和相关的协议结构。
2. 定位与借款人义务、财务报告、限制、违约和补救措施相关的章节。
3. 推断哪些条款构成保证条款，即使它们没有被明确标记。
4. 提取保证条款名称、要求、阈值、频率、有效期、责任方和违约后果。
5. 提供回溯到源文档的引用，供人工审核。
6. 将模糊或低置信度的结果路由给领域专家。
7. 捕获修正并将其反馈到 schema、提示和评估工作流中。

这就是 Built 所需的转变：从文档提取迈向文档理解。同样的模式适用于整个房地产金融领域。智能体需要理解保险覆盖是否满足要求、提款包是否包含所需文件、评估报告是否支持承保假设、发行备忘录是否包含关键风险指标，或者投资组合文件是否包含需要关注的例外情况。在每种情况下，文档不仅是文本来源，更是业务上下文的来源。

为 Built Technologies 智能体 AI 路线图打造的横向解决方案

Built 将新的文档智能解决方案设计为一项横向能力，而非单一用途的方案。首个生产用例聚焦于商业建筑贷款提款包，即借款人在建筑项目期间为请求资金支付而提交的一系列文档。提款包是一个理想的试验场，因为它们规模大、形式多样、时间敏感且运营重要性高。

然而，该解决方案的初衷是广泛支持房地产金融。相同的分类、拆分、提取、评估和人工审核能力可以被多个智能体和工作流复用，包括：

• 提款审查智能体：对包裹内容进行分类，识别缺失文件，提取发票和留置权放弃数据，并标记例外情况。
• 贷款协议智能体：识别保证条款、报告义务、财务阈值、借款人限制和违约条款。
• 保险智能体：验证保险凭证、保单声明、赔偿限额、批单、除外责任和到期日。
• 承保智能体：总结发行备忘录、评估报告、租户名单、预算和财务模型。
• 资产管理智能体：监控持续的报告包，识别变化，并揭示资产组合层面的风险。
• 合规智能体：检查所需的表格、许可、检查报告和监管文件。

这些智能体每个都依赖相同的基础能力：将非结构化、不一致、大批量的文档转化为结构化、已验证且可解释的智能。

通过将文档处理变成一个共享的解决方案能力，Built 能够加速其 AI 路线图的推进，而无需为每个产品重建提取管道。新的智能体可以复用同样的基础设施进行数据摄取、分类、schema 管理、提取、评估和审核。

架构深入剖析：智能文档处理加速器与 Amazon Bedrock

Built 与 AWS GenAIIC 和 AND Digital 合作，以 AWS 智能文档处理（IDP）加速器为基础构建了该解决方案。该方案使用 Amazon Bedrock 实现生成式 AI 驱动的分类、拆分、schema 生成、提取、评估和文档推理。

该方案使用由 AWS Step Functions 编排的多阶段管道。每份文档都会经过一系列既定阶段：OCR、分类和拆分、提取、评估以及可选的规则验证。每个阶段都由一个独立的 AWS Lambda 函数驱动。本节将使用一个代表性示例来演示该管道：一份 150 页的商业建筑提款包，它作为一个单独的 PDF 文件，里面包含发票、留置权放弃书、保险凭证和一份封面函，且没有特定的顺序。

宏观来看，管道的工作方式如下。上传到 Amazon Simple Storage Service (Amazon S3) 输入桶的文档会发出一个 Amazon EventBridge 事件。一个 Queue Sender Lambda 函数在 Amazon DynamoDB 跟踪表中记录该事件，并将消息放入 Amazon Simple Queue Service (Amazon SQS) 队列。一个 Queue Processor Lambda 函数通过 DynamoDB 原子计数器管理并发，并在有可用容量时为文档启动一个 AWS Step Functions 执行。然后，状态机按顺序运行处理阶段：先是 OCR，然后是分类和拆分，接着是提取，之后是评估，最后一个处理结果步骤。

提取在一个 Step Functions Map 状态下进行，正是这种机制让解决方案能并行处理已分类的章节。当 150 页的提款包被拆分成其构成的文档时，每个部分都会收到自己的提取调用，并与其他部分同时运行。总处理时间取决于耗时最长的单个部分，而不是所有部分之和。这也是过去数天的工作流现在能在数分钟内完成的原因之一。结果会写入 S3 输出桶，而 AWS AppSync 则通过 GraphQL 订阅向用户界面提供实时状态更新。

文档摄取与审查体验

AND Digital 构建了一个基于 React 的定制 UI，并通过 Amazon Cognito 进行身份验证。该 UI 为用户提供了一个集中的地方来上传文档、管理处理器、定义 schema、审查提取结果、比较版本和检查置信度分数。

定制 UI 很重要，因为 Built 需要该方案同时支持技术用户和业务领域的专家。文档智能不能只由工程团队管理。最了解文档的人往往是贷款专家、运营团队、合规专员、产品经理和面向客户的团队。

当用户上传一个提款包时，文档会通过预签名 URL 存储到 Amazon S3，而 Amazon EventBridge 的上传事件会启动管道。并发层（DynamoDB 原子计数器与 SQS 队列配对）将 Step Functions 的执行速率保持在 Amazon Bedrock 和 Amazon Textract 的服务限额内。正是这一点，使得同一套路径可以无需更改地处理单次临时上传和 5 万份文档的批处理运行。

OCR 与结构提取

当文档进入管道后，AWS Lambda 会触发 Amazon Textract 提取文本、表格、表单、签名和结构层次。Textract 提供下游生成式 AI 工作流用于分类和提取所依赖的文档结构。对于大型文档，系统会逐页处理，这使得并行处理成为可能，但也需要在大规模下谨慎管理并发和节流。

OCR 阶段将其输出规范化为一个一致的结构，供后续阶段使用，记录每页原始文本、解析后的文本和页面图像在 Amazon S3 中的位置：

{ "metadata

Document processing in real estate is complex and highly manual, impacting critical business decisions at scale, making it ripe for automation. Built Technologies, a real estate finance software provider, processes over $500B in real estate projects. The company deployed an AI-powered document processing engine on Amazon Bedrock and the AWS Intelligent Document Processing (IDP) Accelerator. That engine now serves as the foundation for agentic products across the real estate lifecycle. In this post, we share the need for AI-powered document intelligence in real estate and an architectural deep dive to build it.

Real estate finance runs on documents: draw packages, loan agreements, invoices, insurance certificates, inspection reports, and dozens more. Each contains information that lenders and stakeholders need to review, validate, and act on. These documents are often long, inconsistent, domain-specific, and difficult to process with traditional automation.

For Built, document intelligence is not a back-office utility. It’s a horizontal AI capability that sits at the foundation of a new generation of agentic products launching across the real estate finance lifecycle. Whether an agent is reviewing a construction draw, analyzing a loan agreement, validating insurance coverage, summarizing an offering memorandum, or identifying exceptions in a portfolio, it needs the same core capability: the ability to understand documents with context, accuracy, and traceability.

To build that foundation, Built partnered with the AWS Generative AI Innovation Center (GenAIIC), AWS Partner AND Digital, and AWS account teams to create a scalable, AI-powered document processing engine.

The result is a reusable document intelligence solution that can classify, split, extract, evaluate, and reason over complex real estate finance documents. It reduces workflows that previously took days to minutes, supports hundreds of document types, and gives technical teams and industry experts a shared environment for building and improving document processors.

Why real estate finance needs AI-powered document intelligence

Real estate finance is document-heavy, fragmented, and highly contextual. A single transaction or asset can involve hundreds or thousands of pages of documentation produced by different parties, in different formats, at different stages of the asset lifecycle.

Some documents are standardized, such as ACORD 25 certificates or government forms. Others are highly variable, such as offering memorandums, loan agreements, appraisals, Excel-based financial models, and plans and specifications. Many contain nested tables, scanned pages, embedded images, inconsistent labels, legal language, handwritten annotations, and borrower- or lender-specific terminology.

Built’s existing document-processing capabilities helped the company move from manual work to automated extraction across many document types. The team had established 26 processors for extraction, splitting, and classification using optical character recognition (OCR) and traditional machine learning (ML). That approach worked for narrower use cases where the fields were explicit, and layouts were predictable.

But as Built Technologies expanded its AI roadmap across the real estate lifecycle, the team needed something more flexible and more intelligent. They needed a solution that could support more than 250 document types, handle millions of documents, and power agents that could reason over documents rather than simply extract text from them.

Built faced several challenges:

• Document volume and variety : Built processes more than 250 document types across construction lending, real estate finance, asset management, compliance, and portfolio workflows among others. Individual documents can exceed 500 pages.
• Complex, inconsistent document structures : Many documents contain nested tables, embedded imagery, scanned pages, custom layouts, and non-standard terminology.
• Context-dependent extraction : Important information is often implied, distributed across multiple sections, or expressed in domain-specific language rather than presented as a clearly labeled field.
• High confidence requirements : Built required over 95 percent confidence in classification and extraction workflows to support production use in financial and compliance-sensitive processes.
• Scale and extensibility : Built needed a solution that could support not only one product workflow, but many agentic AI products launching throughout the year.

The goal was to make document understanding a reusable AI capability across Built’s product ecosystem.

From OCR-based extraction to agentic document understanding

Traditional OCR and machine learning-based document extraction generally works by identifying text and matching it to expected fields, labels, layouts, or prior templates. This can be effective for structured documents, but it’s limited when the task requires judgment, context, or domain reasoning. For example, finding a loan amount, invoice number, or policy expiration date may be a relatively direct extraction task. The field is usually explicit, labeled, and located near predictable text. However, finding covenants in a loan agreement is different.

Covenants are often not presented in a straightforward table labeled “Covenants.” They might appear across multiple sections of a long agreement. They may be embedded in legal language, defined through references to other sections, or expressed as borrower obligations, restrictions, reporting requirements, financial thresholds, default triggers, or remedies. A keyword search for “covenant” might miss the substance. A traditional extraction model may find the word but fail to understand the obligation.

An agentic document workflow can approach the problem differently. Instead of only extracting fields from text, the system can interpret the document in context. It can identify relevant sections, reason over definitions and obligations, distinguish between requirements and exceptions, extract structured outputs, and provide supporting evidence for review.

For a loan agreement, an agentic workflow could:

1. Identify the document type and relevant agreement structure.
2. Locate sections related to borrower obligations, financial reporting, restrictions, defaults, and remedies.
3. Infer which clauses represent covenants, even when they are not explicitly labeled.
4. Extract the covenant name, requirement, threshold, frequency, effective period, responsible party, and consequence of breach.
5. Provide references back to the source document for human review.
6. Route ambiguous or low-confidence results to a subject matter expert.
7. Capture corrections and feed them back into schema, prompt, and evaluation workflows.

This is the shift Built needed: from document extraction to document understanding. That same pattern applies across real estate finance. Agents need to understand whether insurance coverage satisfies requirements, whether a draw package contains the required documentation, whether an appraisal supports underwriting assumptions, whether an offering memorandum contains key risk indicators, or whether a portfolio document includes exceptions that require attention. In each case, the document is not only a source of text. It is a source of business context.

A horizontal solution for the Built Technologies agentic AI roadmap

Built designed the new document intelligence solution as a horizontal capability rather than a single-purpose solution. The first production use case focused on commercial construction loan draw packages, where borrowers submit collections of documents to request fund disbursements during construction projects. Draw packages are a strong proving ground because they are large, variable, time-sensitive, and operationally important.

However, the solution was intentionally designed to support real estate finance at large. The same classification, splitting, extraction, evaluation, and human-review capabilities can be reused across multiple agents and workflows, including:

• Draw review agents that classify package contents, identify missing documents, extract invoice and lien waiver data, and flag exceptions.
• Loan agreement agents that identify covenants, reporting obligations, financial thresholds, borrower restrictions, and default provisions.
• Insurance agents that validate certificates of insurance, policy declarations, coverage limits, endorsements, exclusions, and expiration dates.
• Underwriting agents that summarize offering memorandums, appraisals, rent rolls, budgets, and financial models.
• Asset management agents that monitor ongoing reporting packages, identify changes, and surface portfolio-level risks.
• Compliance agents that inspect required forms, permits, inspection reports, and regulatory documentation.

Each of these agents depends on the same foundational ability: turning unstructured, inconsistent, high-volume documents into structured, validated, explainable intelligence.

By making document processing a shared solution capability, Built can accelerate its AI roadmap without rebuilding extraction pipelines for every product. New agents can reuse the same infrastructure for ingestion, classification, schema management, extraction, evaluation, and review.

Architecture deep dive: Intelligent Document Processing Accelerator and Amazon Bedrock

Built partnered with AWS GenAIIC and AND Digital to build the solution using the AWS Intelligent Document Processing (IDP) Accelerator as the foundation. The solution uses Amazon Bedrock for generative AI-powered classification, splitting, schema generation, extraction, assessment, and document reasoning.

The solution uses a multi-stage pipeline orchestrated by AWS Step Functions. Each document moves through a defined sequence of stages: OCR, classification and splitting, extraction, assessment, and optional rule validation. Each stage is powered by a discrete AWS Lambda function. This section walks through that pipeline using a representative example: a 150-page commercial construction draw package that arrives as a single PDF containing invoices, lien waivers, insurance certificates, and a cover letter in no particular order.

At a high level, the pipeline works as follows. A document uploaded to an Amazon Simple Storage Service (Amazon S3) input bucket emits an Amazon EventBridge event. A Queue Sender Lambda function records the event in an Amazon DynamoDB tracking table and places a message on an Amazon Simple Queue Service (Amazon SQS) queue. A Queue Processor Lambda function manages concurrency through a DynamoDB atomic counter and, when capacity is available, starts an AWS Step Functions execution for the document. The state machine then runs the processing stages in order: OCR, then classification and splitting, then extraction, then assessment, and finally a process-results step.

Extraction runs inside a Step Functions Map state, which is the mechanism that lets the solution process classified sections in parallel. When the 150-page draw package is split into its constituent documents, each section receives its own extraction invocation that runs concurrently with the others. Total processing time is bounded by the longest individual section rather than the sum of all sections. This is one of the reasons workflows that previously took days now finish in minutes. Results are written to an S3 output bucket, and AWS AppSync delivers real-time status updates to the user interface through GraphQL subscriptions.

Document ingestion and review experience

AND Digital built a custom React-based UI authenticated through Amazon Cognito. The UI gives users a central place to upload documents, manage processors, define schemas, review extraction results, compare versions, and inspect confidence scores.

The custom UI was important because Built needed the solution to support both technical users and business subject matter experts. Document intelligence can’t be managed only by engineering teams. The people who understand the documents best are often lending experts, operations teams, compliance specialists, product managers, and customer-facing teams.

When a user uploads a draw package, the document is stored in Amazon S3 through pre-signed URLs, and the Amazon EventBridge upload event sets the pipeline in motion. The concurrency layer (the DynamoDB atomic counter paired with the SQS queue) keeps the rate of Step Functions executions within Amazon Bedrock and Amazon Textract service limits. This is what allows the same path to handle both a single ad hoc upload and a 50,000-document batch run without changes.

OCR and structural extraction

When documents enter the pipeline, AWS Lambda triggers Amazon Textract to extract text, tables, forms, signatures, and structural hierarchy. Textract provides the document structure that the downstream generative AI workflows rely on for classification and extraction. For large documents, the system processes pages individually, which allows parallelization but requires careful concurrency and throttle management at scale.

The OCR stage normalizes its output into a consistent structure that later stages consume, recording the location of the raw text, parsed text, and page image for every page in Amazon S3:

{
  "metadata": {
    "input_bucket": "<BUCKET>",
    "object_key": "<KEY>",
    "num_pages": "<NUMBER>"
  },
  "pages": {
    "1": {
      "rawTextUri": "<S3_URI>",
      "parsedTextUri": "<S3_URI>",
      "imageUri": "<S3_URI>"
    }
  }
}

The solution can also use Amazon Bedrock as an alternative OCR backend for documents where a vision-capable model reads the page more reliably than traditional OCR, such as low-quality scans or dense handwritten annotations. The OCR backend is a configuration choice rather than a code change, so teams can select Textract or Bedrock per processor.

Intelligent classification and splitting

After OCR processing, the classification workflow uses Amazon Bedrock to determine document types and identify boundaries within combined PDFs. This is especially important in real estate finance, where a single package may contain many documents in unpredictable order. Instead of requiring a separate document splitter with rigid page limitations, the solution identifies the constituent documents inside large packages and preserves their relationship to the broader transaction.

Classification is driven by a configurable prompt that lists the available document types and a set of examples. A prompt cache delimiter separates the static instructions from the document text so the static portion can be reused across requests:

classification:
  task_prompt: |
    Classify this document into the following categories:
    {CLASS_NAMES_AND_DESCRIPTIONS}
    <few_shot_examples>
    {FEW_SHOT_EXAMPLES}
    </few_shot_examples>
    <<CACHEPOINT>>
    <document_content>
    {DOCUMENT_TEXT}
    </document_content>

The <<CACHEPOINT>> marker is what makes this efficient at Built’s scale. Everything before the cache delimiter such as the class definitions and examples is identical for every document a processor handles, so Amazon Bedrock caches it and reuses it across requests. Only the document text after the marker changes from one invocation to the next. For a draw-package processor that defines a dozen or more document classes with examples, this avoids reprocessing the same instructions on every page of every package.

The document splitting stage produces a structured result that maps page ranges to document types. For the example draw package, the output groups the pages into labeled sections:

{
  "sections": [
    { "id": "group-001", "class": "CoverLetter", "pages": [1] },
    { "id": "group-002", "class": "Invoice", "pages": [2, 3, 4, 5, 6] },
    { "id": "group-003", "class": "LienWaiver", "pages": [7, 8] },
    { "id": "group-004", "class": "InsuranceCertificate", "pages": [9, 10] }
  ]
}

Each section group becomes an independent task in the Step Functions Map state, and extraction runs against the schema specific to that document type.

Dynamic schema generation and extraction

A key capability of the solution is dynamic schema generation. Users can upload examples of a new document type, and Amazon Bedrock generates a proposed extraction schema: the fields, structures, and outputs that should be captured from that document. Subject matter experts can then refine the schema, test it against examples, compare outputs across model versions, and create new processor versions.

Internally, each document type is defined by a JSON Schema, and the description written for each field becomes part of the extraction prompt. This is where much of the solution’s accuracy comes from: a field description that includes where the value typically appears and what it is called guides the model far more effectively than a field name alone. A lien waiver schema, for example, captures the waiver type, contractor, project, applicable period, amount, and any exceptions:

classes:
  - $id: LienWaiver
    x-aws-idp-document-type: LienWaiver
    type: object
    description: >
      A lien waiver in which a contractor or supplier waives the right
      to file a mechanic's lien against the property for payment received.
    properties:
      WaiverType:
        type: string
        description: >
          The type of waiver: Conditional, Unconditional, Partial, or
          Final. Look for these terms in the heading at the top.
      ContractorName:
        type: string
        description: >
          The contractor or subcontractor signing the waiver. Usually in
          the 'From' or 'Claimant' field, or above the signature line.
      ProjectName:
        type: string
        description: >
          The project name or address. Look for 'Project', 'Job Name',
          or 'Property' labels.
      ThroughDate:
        type: string
        description: >
          The date through which the waiver applies. May be labeled
          'Through Date', 'Period Ending', or 'For Work Through'.
      AmountWaived:
        type: string
        description: >
          The dollar amount being waived, typically near the waiver
          statement.
      ExceptionItems:
        type: array
        description: Any exceptions or exclusions listed in the waiver.
        items:
          type: object
          properties:
            Description: { type: string }
            Amount: { type: string }

The x-aws-idp-document-type annotation links the schema to the classification output. When classification labels pages 7 and 8 as a LienWaiver, the extraction stage loads this schema and builds a prompt from the field descriptions and the OCR text for those pages. Where additional grounding helps, teams can attach few-shot examples to a class (a sample document paired with its expected attributes) to demonstrate the output they want for an unusual layout.

This schema-driven approach is also what makes supporting more than 250 document types practical. Rather than hand-authoring every schema, teams use the Accelerator’s discovery capability to generate a first draft from sample documents: upload one or more examples, and Amazon Bedrock proposes a schema with field names, types, and descriptions for an expert to refine. For bulk onboarding, the solution can cluster a large collection of sample documents by similarity and propose a schema for each cluster.

Because the schema, prompts, and model are all parameters in the configuration, Built can apply a flexible model strategy. For straightforward documents such as standard invoices or insurance certificates, teams may select smaller, faster models such as Amazon Nova Lite. For documents that require deeper reasoning or more complex layout interpretation, such as loan agreements or offering memorandums, they may select larger models such as Anthropic Claude available through Amazon Bedrock. The solution uses the right model for the right document and workflow instead of forcing every use case through a single extraction approach.

Confidence scoring, human review, and feedback loops

Each extraction result includes confidence scoring at the field level. Built requires over 95 percent confidence in key production workflows, and results below the required threshold are routed to human reviewers.

Confidence scores come from a dedicated assessment stage rather than from the extraction call itself. After extraction, a separate Amazon Bedrock invocation compares the extracted values against the source document and the OCR text and produces, for each field, a confidence score between 0 and 1, a short explanation, and the location of the supporting evidence on the page. For the lien waiver in the example package, the assessment might return:

{
  "WaiverType": {
    "confidence": 0.95,
    "confidence_reason": "Heading reads 'CONDITIONAL WAIVER AND RELEASE ON PROGRESS PAYMENT'",
    "geometry": [{ "boundingBox": { "top": 0.05, "left": 0.2, "width": 0.6, "height": 0.04 }, "page": 7 }]
  },
  "AmountWaived": {
    "confidence": 0.72,
    "confidence_reason": "Several dollar amounts on the page; value near the waiver statement chosen, but a handwritten notation is partially illegible",
    "geometry": [{ "boundingBox": { "top": 0.45, "left": 0.3, "width": 0.2, "height": 0.03 }, "page": 7 }]
  }
}

In this example, the waiver type clears the threshold but the waived amount doesn’t, so the document is sent to review. Reviewers work in a split-pane interface: the original page image in the left pane, with bounding-box overlays drawn from the assessment geometry highlighting where each value was found, and the extracted fields in the right pane, color-coded so that values below the confidence threshold stand out. Reviewers correct classifications, update extracted values, and mark sections complete. Role-based access keeps this orderly at scale. Reviewers handle the documents in their queue, while administrators manage configurations and users.

Importantly, those corrections do n’t stop at the individual document. They feed back into the solution’s evaluation baseline datasets, so the same reviewer effort that fixes one package also improves the schemas, prompts, and examples used for the next one. This human-in-the-loop process lets Built scale automation while preserving expert oversight where it matters most.

Reasoning over documents

Extraction answers the question of what a document contains. Many real estate finance workflows also need to answer whether a document satisfies a requirement. This is the difference between pulling a coverage limit off an insurance certificate and determining whether that coverage meets the terms of the loan agreement. The solution supports this through a rule-validation workflow that evaluates documents against business rules in two steps.

First, a fact-extraction step sends the relevant document sections to Amazon Bedrock and gathers the facts that bear on a given policy area, along with references back to where each fact was found. Second, an orchestration step reasons over that curated evidence and returns a determination (compliant, non-compliant, or insufficient evidence) with citations to the supporting sections. The rules themselves are expressed as plain questions grouped into policy classes, which keeps them in language that subject matter experts can own:

policy_classes:
  - policy_type: "loan_covenants"
    questions:
      - "Does the document specify a debt service coverage ratio requirement?"
      - "Is there a minimum net worth maintenance clause?"
      - "Are there restrictions on additional indebtedness?"
  - policy_type: "insurance_requirements"
    questions:
      - "Does the coverage meet the minimum limits in the loan agreement?"
      - "Is the lender listed as an additional insured or loss payee?"

Separating fact-finding from judgment is what makes this reliable on long, dense documents. The fact-extraction step concentrates the model’s attention on locating relevant clauses across a hundred-page agreement. The orchestration step can then weigh the evidence without being distracted by the rest of the document. This is the same agentic pattern described earlier identifying relevant sections, reasoning over obligations, and providing evidence for review.

Why collaborative schemas and evaluations are critical

For agentic document processing to work in production, teams need more than prompts. They need shared definitions of what should be extracted, what a correct answer looks like, how accuracy is measured, and how changes are tested before deployment.

This is especially important in real estate finance because many extraction tasks are domain-specific. A generic model may understand the words in a loan agreement, appraisal, or insurance certificate, but Built’s teams need outputs that align with the business meaning of those documents.

The solution gives technical and non-technical teams a shared workspace for:

• Schema design : Defining the fields, nested structures, and outputs that agents need.
• Extraction testing : Running documents through processors and comparing outputs.
• Evaluation workflows : Measuring accuracy against labeled examples and expected answers.
• Version management : Tracking changes to schemas, prompts, and model configurations.
• Human feedback : Capturing reviewer corrections and using them to improve future performance.

This collaboration is what makes the system scalable. Industry experts can shape the document understanding layer without requiring every change to become an engineering project. Engineering teams can operationalize those definitions through versioned schemas, evaluations, model orchestration, and deployment workflows.

The result is a document intelligence solution that improves over time and can support a broad portfolio of AI agents.

Results and impact

Built’s AI-powered document intelligence solution creates a foundation for faster, more accurate, and scalable real estate finance workflows.

Key outcomes include:

• From days to minutes : Classification and extraction workflows that previously took 3–9 days can now be completed in minutes per package.
• Support for complex documents : The solution can process multi-hundred-page packages, nested tables, embedded images, scanned content, and non-standard layouts that are difficult for OCR-based systems.
• Scale across document types : The architecture is designed to support more than 250 document types across real estate finance workflows. Production workload is being scaled to 20 million documents per month, 300,000 documents per week, over 50,000 batch processing runs.
• Horizontal reuse across agents : The same document intelligence capabilities can power multiple agentic AI products across construction lending, insurance, underwriting, asset management, compliance, and portfolio intelligence.
• Production-scale throughput : The team validated the pipeline through large batch processing runs and production-scale testing, including resolving Amazon Textract throttling limits when processing large documents at high concurrency.
• Evaluation-driven quality : Built’s integration with evaluation workflows allows teams to test schema changes, compare model behavior, and maintain confidence thresholds before deploying changes into production.
• Human-in-the-loop trust : Low-confidence or ambiguous outputs are routed to reviewers, preserving expert oversight while reducing manual effort.

Conclusion

The collaboration between Built Technologies, AWS GenAIIC, and AND Digital demonstrates how generative AI can transform document-intensive workflows across real estate finance.

By using the AWS Intelligent Document Processing Accelerator and Amazon Bedrock, Built developed a reusable document intelligence solution that demonstrates how real estate finance companies can modernize document processing workflows. For Built, this capability is foundational to its AI strategy. Document intelligence is the horizontal layer that allows agents to understand real estate finance workflows, surface exceptions, accelerate decisions, and turn unstructured documents into trusted business actions.

To learn more about using Amazon Bedrock for document processing, see Document processing with generative AI on AWS.

To learn more about the GenAIIC program, see the AWS Generative AI Innovation Center.

To explore AND Digital’s AWS partnership capabilities, see AND Digital’s AWS alliance.

Built is an AI-powered financial operations platform for the real estate and construction industries. By connecting capital providers, owners & developers, and builders, Built automates workflows, accelerates the flow of money and information, and unlocks insights for smarter decisions. More than 300 of the top financial institutions and thousands of owners and builders trust Built to manage hundreds of billions in real estate and construction activity, so you spend less time on process and more time on progress. Learn more at getbuilt.com.

---

About the authors

Dipanshu Jain

Dipanshu is a Sr. AI Strategist at the AWS Generative AI Innovation Center, where he works with executives and builders driving customer engagements at the intersection of AI strategy and implementation. He works across healthcare, insurance, and enterprise SaaS, partnering with customers and AWS Partners to take solutions from prototype to production.

Vincil Bishop, PhD

Vincil is a Senior Deep Learning Architect at AWS GenAIIC, where he provides technical leadership on intelligent document processing, foundation model implementation, and production generative AI architectures.

Thomas Schlegel

Thomas is VP of Engineering at Built Technologies, where he leads engineering initiatives focused on AI, automation, and product innovation across real estate finance.

Kiley Poole

Kiley is a Senior Engineering Manager at Built Technologies where he manages engineering initiatives focused on AI, automation, and product innovation across real estate finance.

Steve Van De Steene

Steve is Director of Product Management at AND Digital, where he helps organizations adopt AI-enabled products and solutions.

Nick Federovitch

Nick is the Enterprise Account Manager for Built Technologies at AWS providing thought leadership and aligning programs and technical resources to support Built’s AI usage.

Kyle Mabry

Kyle is the designated Sr. Solutions Architect for Built Technologies, leading the ECRT Industry TFC and delivering technical sessions to enable Built on AWS AI.