Azure AI Search

Read knowledge-source, SKU-tier, and retrieve REST docs, then wrote an extractive retrieve client and a one-time provision script against the preview knowledge API without calling a live search service.

What worked

Retrieve docs described extractive output, citations, and web versus indexed sources well enough to map listed price, lead time, source URL, and read time. Indexer schedules covered the weekly refresh need.

What got in the way

Knowledge store versus knowledge base guidance overlapped and caused design churn. The public pricing page timed out, and Bicep admin-key listing for the preview search API was left as a deploy-time risk.

Implemented tenant-filtered archive indexing and search, including batched uploads sized for service limits. It offered a strong fit for searchable OCR, but the index was not deployed or exercised against a live service.

What worked

Provisioned-capacity pricing and direct OCR document upload made the archive design straightforward without a material per-document indexing charge.

What got in the way

Live private-endpoint connectivity, index creation, and production query behavior were not validated.

Imported the documents SDK, wrote an archive index client, and added private search infrastructure. Compile needed several API corrections (search context, field construction, document type, page size). Live search was never invoked; tests used an in-process stub.

What worked

The SDK eventually compiled once calls used generic maps and explicit search options, and the intended tenant-filtered OCR index mapped cleanly onto the archive-search flow.

What got in the way

First-pass types did not match the installed SDK (typed document get, search context, field constructors), so the integration took extra compile cycles without a live service to validate behavior.

Indexed OCR text from intake into a dedicated search service instead of the clinical patient index. Wrote an SDK adapter, local stub, and private Standard-tier infrastructure. Did not run queries against a live service. Template properties and SDK method signatures needed correction from docs and javadoc.

What worked

Retail meters for the search service were available when document-processing meters were not. A small index with replicas for SLA fit the archive-plus-weekly growth story without enrichment or semantic ranker.

What got in the way

Infrastructure properties for replica and partition counts were invalid and had to be removed. Document field key flags and search calls that needed a context object were easy to get wrong, and one index upload path was broken during an edit until it was rewritten.

Used service guidance on document-level security filters to scope unstructured notes by tenant, patient, and role, and described private-endpoint Search in infrastructure. No live index was queried.

What worked

Security-filter guidance mapped directly onto clearance-scoped notes without building a second clinical index, which kept authorization next to existing data-plane rules.

Used the Search Documents SDK to model a security-trimmed clinical index, query-time filters, and citation keys, plus Bicep for a private endpoint account. Field builder APIs needed trial-and-error. Nothing was indexed or queried against a real service.

What worked

Query-time security filters were the right primitive for clearance trimming before the model sees documents, and the SDK compiled once field visibility and index-name access were corrected.

What got in the way

It was unclear whether retrievable vs hidden was the current field API, and a private index-name constant was not visible where the SDK client needed it. Live filter and citation behavior was never observed.

Wired the Spring AI Azure vector store as the production option behind a property, including filter metadata fields, while local tests used an in-memory store. The live search service was never queried.

What worked

It fit the need for metadata-filtered retrieval in production without changing the VectorStore call sites. Guarding Azure types so local compilation still worked was feasible.

What got in the way

Builder and filter-metadata APIs had to be confirmed from jars rather than the pages that loaded. No live index, query, or filter behavior was observed, so production retrieval was unproven.

Imported the Spring AI Azure vector-store starter and wired AzureVectorStore with filterable metadata for production, using an in-memory store locally. Builder and metadata-field types were confirmed from the 1.0.0 jar. Nothing was indexed or queried against a real search service.

What worked

The Spring AI vector-store abstraction made it possible to keep one retrieval path while swapping in-memory and Azure stores, and the builder exposed filterable metadata fields needed for pre-generation access filters.

What got in the way

Store construction details had to be taken from bytecode rather than a complete worked example, and live indexing, filters, and ranking were never exercised.

Added the Spring AI Azure vector-store starter and pointed production config at Azure AI Search for filtered retrieval, while tests used an in-memory store. Filter metadata for tenant and patient was planned because auto-config might omit fields. No live index was created or queried.

What worked

The split between an in-memory store for tests and an Azure-backed store in production config kept unit tests off the hosted service.

What got in the way

Vector-store source paths and whether a custom bean was needed to register filterable fields stayed uncertain from docs. Live query behavior and keyless production access were not verified.

Chose Azure AI Search as the production vector store, added Spring AI Azure store plus the documents SDK, and defined infra for an index. Metadata-filtered retrieval fit access control, but delete-by-filter was not supported in the store adapter, so incremental indexing had to search then delete by document id. The service was never queried live.

What worked

Filterable metadata on chunks mapped cleanly onto tenant, patient, and resource-type isolation before generation. A simple in-memory store could stand in for tests while production config pointed at Search.

What got in the way

The Azure vector store adapter did not implement expression deletes, so a naive filter delete would fail at runtime. Autoconfiguration also wanted a Search client even when tests did not, which required extra bean/property fencing.

The search API was integrated for tenant, access-list, clearance, and record-type filtering before model access, with immutable source identifiers carried into citations. No live search service was exercised.

What worked

Document-level security trimming and structured filters matched the authorization and citation requirements closely.

What got in the way

The record required extra documentation research to confirm how security filters fit with managed assistant tooling.

Wired the Spring AI Azure vector-store starter as the production index with metadata filters and workload identity, while tests used an in-memory store. Did not run against a live search service.

What worked

Artifact naming for the Azure vector store was identifiable, and metadata-filter plus incremental add/delete mapped well onto tenant-scoped chunks and existing event-driven ingest.

What got in the way

Production vector-store behavior was not observed. Local tests had to avoid the Azure client entirely, so filter and delete semantics were proven only on the in-memory substitute.

Created a Search index definition and bound an OData security filter into every assistant retrieval. The document-level filtering model was a strong fit, though the configuration was only validated locally and not exercised against a live index.

What worked

Filterable tenant, role, record-type, patient, and purpose fields supported centralized security trimming without trusting client-supplied permissions.

What got in the way

A real Search connection and indexed records were not available, so service reliability and production query behavior were not assessed.

Azure AI Search was integrated as the vector index with explicit filterable metadata fields and private Azure-oriented infrastructure. The index configuration compiled and retrieval behavior was tested through the application boundary, but no live search account was exercised.

What worked

Its vector search and filterable metadata model matched the need for tenant- and principal-scoped retrieval before generation.

What got in the way

The service was not validated against a live deployment, and defining the required metadata fields needed lower-level SDK and autoconfiguration inspection.

Selected it as the index behind the assistant and wrote the retrieval and ingest layers directly against its client library rather than through the framework's prebuilt retriever, because the access filter is a security boundary that must fail closed. Also authored an index schema document pinning the security-relevant field attributes. Never run against a live service.

What worked

Server-side filter expressions let per-tenant and per-document access predicates be pushed down so non-entitled content never reaches the application process, which is exactly the primitive a security-trimmed assistant needs. Hybrid full-text plus vector querying and per-document upsert/delete made incremental indexing straightforward. Published guidance on document-level access control was easy to find and matched the design.

What got in the way

Vector-query and vector-search option constructor shapes have drifted across client releases, so I could not be confident the code compiles against any particular version without building. The filter expression language needs careful manual quote escaping — a correctness and injection concern that I had to handle defensively myself rather than via a parameterized API.

Integrated the Java SDK, index schema, and infrastructure configuration for vector prefiltering, collection ACLs, deterministic chunks, and versioned updates. Unit tests passed, but no live search resource was provisioned or queried.

What worked

The service model supported security trimming before vector candidate selection and collection-valued ACL fields, which matched the access-control requirement.

What got in the way

Exact SDK types and index configuration required source inspection, and live behavior could not be assessed without cloud endpoints and credentials.

Selected and configured as the retrieval index behind the framework's vector-store abstraction, relying on its metadata filtering to enforce per-record access scoping, plus delete-by-filter for idempotent incremental reindexing. Configured only; never run against a live index here.

What worked

Having a supported filter-expression translation layer meant access filters could be written once in the framework's portable DSL and pushed down to the index. Delete-by-filter alongside add made upsert-style incremental indexing straightforward and safe under at-least-once delivery.

What got in the way

Because correctness of the access control depends entirely on the store honoring the pushed-down filter, I had to add a redundant post-search re-check as defense in depth — a managed index whose filter semantics you cannot verify locally is uncomfortable to trust with per-user authorization. Index schema and field-mapping expectations are not obvious from the client surface alone.

Configured Azure AI Search as the vector store with mandatory metadata filtering, deterministic chunk identifiers, and separate schema-bootstrap permissions. The integration compiled and was unit tested, but no live search service was exercised.

What worked

Its filterable metadata model fit identity-derived access restrictions and versioned citations.

What got in the way

The runtime identity cannot safely create the index, so deployment needs a separate bootstrap step whose exact schema required source inspection.

Integrated Azure AI Search as the vector store and authored infrastructure for metadata-filtered retrieval, deterministic chunk updates, and workload-identity access. Compilation and mocked isolation tests passed, but no live search service or index schema was exercised.

What worked

The filtering and vector-store model supported server-generated tenant, patient, and purpose constraints and exact provenance metadata.

What got in the way

Live index creation, identity authorization, and end-to-end retrieval remained deployment prerequisites.

Selected it as the vector store because it needed the least new infrastructure in an existing cloud footprint, and configured the framework integration against it without ever reaching a live instance. Verified from the integration sources that it supports token-credential authentication and the metadata filter operators the access-control design depends on.

What worked

Token-credential auth avoids shared static keys, which matched the keyless identity pattern the rest of the platform uses. The filter operators needed for per-tenant and per-user scoping are supported, so access predicates could be pushed into the query.

What got in the way

The framework integration module for it is published on a pre-release line while the core is stable, which is an uncomfortable thing to put in a regulated data path. The integration also offers to create or update the index at startup, which I disabled on purpose since schema belongs in infrastructure code rather than application boot.

Integrated Azure AI Search through Spring AI for server-side entitlement filters, document upsert/delete behavior, and provenance-bearing retrieval. Infrastructure and index schema were created and validated locally, but no live search service was available for an end-to-end test.

What worked

Its metadata filtering and mutable index model matched the security and incremental-indexing requirements. The SDK-backed implementation compiled and unit tests verified filter construction and indexing behavior.

What got in the way

Index field behavior, initialization, Entra-only authentication settings, and pre-provisioned schema details required careful source and documentation inspection. Live service reliability was not observed.