AWS’s Adjudicated Query pattern gives Amazon Quick a tightly defined role in lease compliance auditing: translate a question into an approved tool call, then explain the results. A Lambda-hosted Model Context Protocol (MCP) server connects that conversational interface to a deterministic rules engine, which performs the compliance evaluation. AWS presents the design as a way to produce complete, defensible answers across a lease portfolio, alongside a deployable AWS Cloud Development Kit sample. AWS’s reference architecture describes how those responsibilities fit together.
The central architectural decision is where authority sits. The agent cannot write arbitrary queries, change the population being assessed, or make final compliance determinations. Those constraints make the scope of an answer something the system can account for, rather than something a reader must infer from the agent’s prose.
Why a compliance answer needs a coverage record
A search that returns relevant lease clauses answers a different question from a sweep that accounts for every eligible lease. The distinction matters when the question concerns the size of a compliance problem across a portfolio. As The Chenab Times’ account of the design explains, retrieval can return a ranked sample without establishing exhaustive coverage; generated SQL can introduce predicates that silently narrow the population.
AWS’s proposed answer combines two properties. Completeness means every record is accounted for. Defensibility means a finding can be examined through the rules, methods, and dates used to reach it. In this design, an explanation from a language model is only the presentation layer over that evidence.
This is a deliberate restriction on agent autonomy. The architectural benefit is that conversational flexibility does not determine the evaluation method or which records enter an official result.
From Amazon Quick to the rules engine
The reference architecture routes requests from Amazon Quick through an Amazon API Gateway HTTP API to AWS Lambda. API Gateway uses a JSON Web Token authorizer backed by Amazon Cognito; Cognito supplies OAuth tokens through a client credentials flow. Lambda hosts both the MCP server and the rules engine.
AWS specifies JSON-RPC 2.0 over Streamable HTTP for the MCP server, with Server-Sent Events framing for responses required by the Amazon Quick client. That transport detail matters when implementing the sample: the conversational client and server must agree on how tool responses arrive.
Amazon Aurora Serverless v2, using Postgres and pgvector, holds the rulebook, lease records, extraction status, determinations, and runs in one relational store. The application accesses Aurora through the RDS Data API. Amazon Quick Sight connects to Aurora through a VPC connection and renders the full findings table, with filters for sweep and severity band. These are components of the AWS reference design, rather than an independently measured production deployment.
The shared store connects the conversational summary to the detailed review surface. Chat can present counts and selected findings while the dashboard exposes the full results. Reviewers therefore have a route from a compact answer to the underlying determinations without treating the chat transcript as the entire audit record.
Six tools with different evidentiary roles
The MCP server exposes exactly six tools. Their differences are central to the design: an exhaustive sweep, a hypothetical rule change, and a semantic search produce different kinds of answers.
| Tool | Operation | Meaning of the result |
|---|---|---|
| <code>sweep_compliance</code> | Evaluates the population against rules in force on a stated date | Official sweep; accounts for every lease in a computed receipt and writes findings |
| <code>simulate_rule_change</code> | Tests one proposed rule value against the approved baseline | Exploratory directional counts; records nothing |
| <code>explore_clauses</code> | Retrieves the top K results by semantic similarity within a filtered population | Interpretive ranked sample; cannot establish a population count |
| <code>get_finding</code> | Retrieves one finding’s complete evidence chain | Drill-down into a single determination |
| <code>list_rules</code> | Retrieves the rulebook in force on a date | Reference lookup including versions, citations, and approvers |
| <code>check_connection</code> | Checks liveness without touching data | Transport health only |
These tool semantics come from AWS’s implementation walkthrough. They give the agent distinct operations for official evaluation, exploration, and inspection.
For a cloud architect, the useful distinction is between an operation that writes an official finding and one that helps investigate a question. A rule simulation supplies directional counts without creating determinations. A clause search supplies relevant examples without answering how many leases violate a requirement. Treating those outputs interchangeably would discard the guarantees the tool boundary is designed to preserve.
Versioned rules and the completeness receipt
The rules engine represents governing requirements as versioned data. It uses generic comparison operators without jurisdiction-specific or topic-specific branching. As The Chenab Times reports, changes to the represented rules are made through rulebook row edits. The date supplied to a sweep determines which rules are in force for that evaluation.
Each sweep produces a completeness receipt asserting that the counts of compliant, in-breach, ambiguous, and unreadable records add up to the total number of scanned documents. The reported design validates that invariant before persistence. Ambiguous and unreadable records remain visible in the accounting; they do not disappear merely because they cannot yield a straightforward determination.
Findings are described as append-only. Separately, get_finding exposes the evidence chain for a single determination, while list_rules exposes rule versions and their supporting references. Remio’s analysis describes that chain as connecting a finding to a lease, clause, rule version, extracted value, and expected value.
The receipt and evidence chain address different review needs. The receipt accounts for coverage; the evidence chain supports scrutiny of an individual outcome. Analytically, a balanced receipt alone cannot establish that an extracted value or encoded rule is correct. Its narrower value is making the population accounting explicit and checkable.
Where model reasoning remains—and what the sample establishes
Amazon Bedrock powers the exploratory clause-search path. The documented components are Amazon Titan Text Embeddings V2 for semantic similarity ranking and Anthropic Claude Sonnet 5 for qualitative clause assessment. Bedrock does not make the official compliance determinations. That separation preserves a place for model-assisted interpretation while keeping official evaluation within the rules engine. The reported architecture makes this boundary explicit.
AWS provides a reference implementation with synthetic data and acceptance tests. The illustrated chat response includes selected noncompliant findings, totals, a synthetic-data caveat, and a dashboard link. As Remio notes, the reference publication does not disclose a customer benchmark across a real portfolio. The screenshots therefore do not establish real-world accuracy or throughput.
For architects evaluating the pattern, the supported takeaway is an execution model: approved tools define the task, versioned rules determine outcomes, and stored findings support later inspection. Its usefulness depends on having an enumerable record set and governing logic that can be represented and reviewed. The completeness receipt makes an important part of that process observable; the correctness of the records and rules still requires scrutiny.
