For most enterprises, search starts as a feature and ends up as foundational infrastructure. That shift happens gradually—until the scale of a product catalog, the complexity of a data model, or the expectations of an AI-powered experience make it impossible to ignore. When an organization reaches that inflection point, the decisions made about architecture, schema design, and cloud infrastructure either unlock future capability or create compounding technical debt.
In a recent engagement, our team delivered an enterprise search and agentic AI platform for a large-scale supply chain operation—one spanning hundreds of thousands of product items, multiple data sources, and a user base with zero tolerance for slow or irrelevant results. The project surfaced a set of architectural challenges that we believe are broadly instructive for any organization building AI-powered search at scale. What follows is an honest account of what we encountered, the tradeoffs we navigated, and the engineering principles that guided our decisions.
Schema Design at Scale: When the Data Model Becomes the Constraint
Enterprise product catalogs are rarely clean. Data accumulates across years, source systems, and business units—each with its own naming conventions, unit definitions, and field structures. When you attempt to consolidate that data into a unified search index, the complexity doesn’t disappear. It moves into schema design, and it creates hard constraints that surface late if you don’t plan for them early.
On this engagement, our primary search index grew to nearly 1,000 fields. That number matters because cloud-managed search platforms impose field limits that are not always visible until you hit them. In Azure AI Search, exceeding the default attribute ceiling requires a direct request to Microsoft engineering, a process that carries a roughly two-week lead time. For a project under active development, that kind of dependency has real schedule implications. We documented this constraint explicitly in our architecture governance materials so that no one encountered it as a surprise.
Equally consequential were the decisions around field types. A natural instinct when designing for faceted search, where users need to filter by multiple values simultaneously, is to convert single-value fields into collections. In practice, that decision triggers performance and cost consequences that are easy to underestimate: query response times can increase four to ten times, index size can grow three to eight times, and full-text search capability on those fields is lost. The better approach is to be selective. Identify the specific fields that genuinely require multi-value faceting and treat those as exceptions, not defaults.
The broader principle here is that schema decisions in AI search are not just data modeling choices, they are performance and cost decisions. The organizations that get this right treat schema design as a first-class engineering discipline, with explicit review gates before structural changes reach production.
Embedding Strategy: The Recovery Risk That Only Appears at the End of the Path
Semantic search—the ability to return results based on meaning rather than keyword match—is one of the most valuable capabilities AI brings to product discovery. It allows users to search the way they think, not the way the data is labeled. But enabling it requires generating vector embeddings for every item in the catalog, and that process introduces an operational risk that most architecture discussions overlook: what happens when you need to rebuild those embeddings from scratch?
We asked that question during architecture planning and traced the full recovery path end to end. What we found was instructive. On a catalog of several hundred thousand items, a full embedding rebuild against a throttled API endpoint is not a quick operation. Modeling a worst-case scenario against pay-as-you-go throughput limits put the rebuild window at approximately 55 hours. That analysis went directly to the business as a documented risk, one that needed to inform DR planning before the platform reached production scale.
The same analysis identified a clear mitigation path: pre-storing generated embeddings in cloud object storage at the time of creation would reduce that 55-hour window to approximately 30 minutes on recovery. Whether and when to implement that mitigation is a business prioritization decision. The value of the architecture review was in making sure that decision could be made deliberately—with full visibility into the tradeoff—rather than reactively after an incident.
The broader point is worth naming: in AI-powered systems, the most consequential operational risks are often not the obvious ones. Network outages, database failures, region disruptions—those are well-understood and planned for. The 55-hour embedding rebuild is the risk that only becomes visible when someone traces the recovery path all the way to the end. That kind of analysis belongs in every AI search architecture review, whether or not the mitigation is implemented immediately.
Data Source Complexity: Normalizing Upstream Before it Reaches the Index
A unified search experience feels seamless to the end user. Behind it, in most enterprise environments, is a fragmented source landscape: a master data management platform, a digital asset system, a content management layer, and one or more integration pipelines stitching them together. Each source has its own data conventions—and those conventions rarely align.
On this project, a concrete example was unit-of-measure handling. One data source embedded unit-of-measure labels directly inside field names, creating dozens of fields like “weight_lbs” or “volume_ml”—while another represented the same data as a value-unit pair stored as a sibling property. Both approaches are defensible in isolation. Together, they create a normalization decision that the pipeline must resolve before data reaches the index, or every downstream query becomes more complicated.
We documented these divergences explicitly and escalated the canonical convention decision to the appropriate stakeholder before writing pipeline logic. That sequencing matters. Resolving field naming conventions after index schemas are built forces expensive migrations. Resolving them before allows the schema to be designed correctly from the start.
The practical lesson is that data pipeline design is architectural work, not implementation detail. The decisions made in the ingestion layer—how entities are related, how field names are standardized, how conflicts between sources are adjudicated—have direct consequences for search relevance, index performance, and the complexity of every query written against the system.
Cost and Scale Planning: Designing for the Catalog You Will Have, Not Just the One You Have Today
Enterprise systems have a way of growing faster than their original architecture anticipated. An index sized for 100,000 items may need to accommodate 500,000 within 18 months. A platform built for 100 internal users may be extended to thousands. Decisions that looked appropriately sized at the start of a project can become constraints within a year.
On this engagement, we modeled the cost and performance implications of scaling the product index to half a million items. The analysis identified a clear inflection point: at that volume, a second search partition becomes necessary. Partitioning adds both cost and query routing complexity, so it is not a decision to make reactively. It belongs in the roadmap conversation from the beginning, not because the organization needs to incur the cost now, but because it needs to know what the threshold is and how to recognize when it is approaching.
The same logic applies to AI model strategy. On this project, we deployed a generally available foundation model as the production baseline while a more capable model remained in limited access approval. That is a reasonable interim posture, but it requires a clear upgrade path and an explicit decision about when the transition should occur. Deferring that decision until the limited access window opens means the team is making a time-pressured architecture choice rather than a deliberate one.
Cost planning for AI infrastructure is not a one-time activity. It is a recurring engineering conversation that should be built into quarterly roadmap and architecture reviews.
Security and Access Control: Filtering at the Intdex, Not the Application
In any multi-user enterprise system, access control is not optional. For a supply chain platform serving users with different roles, regions, and organizational contexts, the ability to surface only the data each user is authorized to see is a core product requirement, not a feature to add in a later phase.
The architecture pattern we applied was security trimming at the index layer. Rather than filtering results in application code after retrieval, every document in the search index carries metadata representing its allowed roles, groups, and users. Queries are automatically scoped to the requesting user’s identity at search time. This approach is both more reliable and more performant than application-layer filtering; results that a user is not authorized to see are never retrieved in the first place.
Equally important is how role-to-filter mappings are managed. Hardcoding those mappings in application logic means that every access control change requires a code deployment. Storing them in a managed configuration service—decoupled from the application codebase—allows access policies to be updated without a release cycle. For an enterprise with evolving organizational structures, that flexibility has significant operational value.
Throughout the platform, we eliminated stored credentials by routing all service-to-service authentication through managed identity. In a cloud-native architecture, credential management is an operational burden and a security surface that managed identity largely removes.
The Architecture Decisions That Determine Search Success Are Made Early
Enterprise AI search is not a technology procurement problem. It is an architecture problem, and the decisions that most determine whether a platform succeeds at scale are made during schema design, pipeline normalization, and infrastructure planning, not during UI development or model selection.
The challenges described here—field limits, embedding recovery windows, data source fragmentation, cost inflection points, and access control at index level—are not exotic edge cases. They are the standard surface area of any serious enterprise search engagement. Organizations that treat them as implementation details to be sorted out later will encounter them as production incidents instead.
The better approach is to surface these decisions early, document them explicitly, and build the governance structures that keep architecture aligned as the system grows. That is the work that separates search experiences that scale from ones that stall.
Is Your Search Architecture Ready for AI Scale?
If your organization is evaluating or expanding an AI-powered search or discovery platform, the architectural decisions above are worth examining before you commit to a direction. AAXIS helps enterprise teams assess search readiness, identify structural risk early, and build cloud-native platforms designed to grow with the business. Reach out to start the conversation.