AnthropicClaude Certified Architect – Professional2026-103.6 Apply retrieval strategies matched to data shape and query pattern
Classify sources and questions before retrieval
Completed by the knowledge check
Learning objective
Characterize data shape (unstructured, semi-structured, relational, code) and query pattern (exact lookup, conceptual, aggregation, multi-hop).
Core idea
Before choosing an index, specify what information exists and what a correct answer must establish. Data shape describes the source’s structure; query pattern describes the operation the question requires. These are independent dimensions. A relational database can hold narrative notes, and a prose document can contain an exact identifier.
For an architect, the deliverable is a source-and-query inventory that exposes unsupported answer types before they become confident production responses. It records the authoritative source, usable fields, required relationships, and completeness requirement for each request class. Method selection belongs to 3.6.2; here you decide what that method must accomplish.
How it works
Characterize the source without flattening it
Unstructured data carries meaning principally in prose: policies, reports, manuals, and transcripts. A relevant passage can explain a concept, but its interpretation may depend on surrounding sections. Inventory the document’s title, scope, version, and effective dates as well as its text. Chunking and indexing decisions belong to subsection 3.5; identifying what those chunks must preserve comes first.
Semi-structured data combines stable fields with variable content. A support ticket can have an account identifier, opening date, product version, and narrative description. Ask which fields are reliable enough to filter or compute over. “Reported a billing problem” in free text is different from a validated issue_category field. Counting the latter does not automatically count every ticket whose prose describes the former.
Relational data represents records and their connections through tables and keys. Identify the unit represented by one row, the keys used to join sources, and the definitions behind measures. Anthropic’s text-to-SQL cookbook supplies the database schema to Claude before generating queries. That schema is essential context: a question about departments and employees cannot be translated reliably without knowing how the tables relate.
Code has text, exact symbols, module structure, and executable relationships. A filename or matching function name can locate a candidate without establishing which behavior runs. Distinguish a request for a definition from a request about its callers or dependencies. Anthropic’s context-engineering guidance describes loading code through lightweight references and targeted exploration rather than materializing every file into the prompt.
Do not force each source into one exclusive category. A code repository includes prose documentation; a relational ticket store includes narrative fields. Record the structure relevant to the requested answer, including which source owns updates. A flattened text copy can remain useful for discovery while the underlying records remain authoritative for computation.
Define the answer requirement
The four query patterns impose different obligations:
| Pattern | What makes an answer correct | Diagnostic question |
|---|---|---|
| Exact lookup | The requested key identifies the intended record or passage | Would a one-character difference change the answer? |
| Conceptual | The evidence expresses the requested idea despite different wording | Must synonyms or paraphrases retrieve the same evidence? |
| Aggregation | The computation covers the defined population with the intended measure | Does the answer require every qualifying record? |
| Multi-hop | Connected facts establish the required relationship or dependency | Does finding one fact reveal the next fact needed? |
An exact lookup such as “What does fault code R-218 mean?” has a different correctness test from “Why does the device restart under load?” Anthropic’s Contextual Retrieval article explains why semantic embeddings can miss an exact error code even when they retrieve broadly relevant error documentation. Conceptual similarity is useful evidence for the second question, but insufficient proof of identity for the first.
Aggregation requires a population definition. Specify date bounds, counting unit, inclusion rules, and deduplication. Ten relevant passages establish that ten passages were retrieved, not that ten incidents occurred. A top-ranked subset cannot establish the total unless a separate completeness guarantee covers the entire qualifying population. The text-to-SQL cookbook illustrates database aggregations and joins rather than asking the model to infer totals from retrieved prose.
Multi-hop requires connected evidence. Anthropic’s knowledge-graph cookbook represents entities as nodes and typed relationships as edges, then uses serialize_subgraph(center, hops=2) to supply a relevant neighborhood. That function is a cookbook example, not an API parameter. Its significance here is the answer requirement: relationships must meet at the same resolved entity, and the path must retain its supporting facts.
Record combinations and unresolved assumptions
A question can combine all four patterns: identify an account, interpret a complaint category, count its qualifying cases, and follow subsidiaries to a parent organisation. Record the compound requirement rather than choosing the first recognizable phrase. “How many” identifies a computation but leaves its population unresolved.
Treat missing structure as a design assumption to test. If a business concept exists only in narrative text, decide whether the answer is illustrative or requires a governed classification process before aggregation. Do not silently convert uncertain semantic matches into authoritative rows. Record what an unanswered or ambiguous request should return, so the delivery team can distinguish missing evidence from a zero result.
Key distinctions and trade-offs
Shape versus pattern: The storage format does not determine the question. Tables support conceptual discovery through text columns; documents support exact lookup through identifiers.
Relevance versus completeness: A passage can be highly relevant while the result set omits most of the population. Completeness is central to counts and exhaustive relationship questions.
Observed relationship versus shared wording: Two passages mentioning the same company do not establish a supplier relationship. A relationship answer needs the particular connection and resolved entities, not co-occurrence alone.
Preserving source structure adds integration work, but flattening it can discard the very keys and measures that make answers defensible. The inventory makes that cost visible before the team optimizes retrieval latency.
Architecture / decision scenario
A healthcare equipment provider wants an internal maintenance assistant with a four-second response target. Its pilot searches manuals, ticket exports, a device registry, and source code through one vector index. On a held-out set, conceptual explanations pass at 94%, exact fault-code answers at 78%, and population counts at 61%. These are hypothetical pilot measurements.
The architect rejects a proposal to classify every question as “document search” and fix the weaker classes by increasing context. The architect inventories manuals as prose, tickets as semi-structured records, the registry as relational data, and diagnostic software as code. Exact fault-code interpretation requires identity; symptom explanations require conceptual evidence; monthly failure totals require complete qualifying records; tracing an installed component to a software dependency requires connected hops.
A ticket question combining “this device,” “power loss,” and “last quarter” receives both an identity requirement and a population definition. The service owner must decide whether the ticket category is reliable enough for a count; if not, the assistant reports illustrative cases rather than an authoritative total. The architect owns the routing requirements, while registry and ticket owners approve their keys and measures. Only then does the team compare retrieval methods against the four-second target.
Common exam traps
- Treating every source that contains text as unstructured data.
- Choosing retrieval from file format without analyzing the answer requirement.
- Treating a similar identifier as the requested identity.
- Reporting a count from a top-ranked subset without establishing completeness.
- Assuming a join or entity relationship from shared wording.
- Classifying a compound question by only one of its clauses.
What to remember
Classify both the source and the required answer. Preserve keys, fields, measures, and relationships that a flattened text index cannot replace. Decide whether the result needs identity, conceptual relevance, complete computation, or connected facts before selecting a retrieval path.
Knowledge check
A product manager asks a support assistant: “How many warranty tickets for the Model X kettle in Q3 were about overheating?” Tickets have validated model and issue_category fields, and the category includes overheating. The pilot filters on the model field, retrieves the 20 highest-ranked ticket passages about overheating, and counts them. Which requirement of this request does the pilot fail to meet?
Leadership wants a monthly total of tickets about “billing confusion.” The concept appears only in free-text ticket descriptions; no field records it, and the service owner has approved no classification of these tickets. What should the inventory record for this request?
A procurement assistant is asked whether Delta Components supplies the valve in a recalled Acme pump. Retrieval returns two passages that each mention both companies by name. What must the evidence establish before the assistant answers yes?
References
- Anthropic, Contextual Retrieval
- Anthropic, Text to SQL with Claude
- Anthropic, Knowledge Graph Construction with Claude
- Anthropic, Effective context engineering for AI agents