2. CAE engineering knowledge landscape

A retrieval-augmented assistant for CAE engineering is only as capable as the knowledge it can reach. Before any embedding model, vector store, or retrieval policy is chosen, the engineering team must map the corpus that the assistant will actually draw on. That corpus is not a single document set. It is a heterogeneous landscape spanning simulation domains, solver reference material, material property databases, and accumulated engineering practice. Treating these as one undifferentiated pile of text is the most common reason a CAE assistant produces confident but unusable answers. This section builds a working map of that landscape and shows how to structure it for retrieval.

Simulation domains define the vocabulary boundary

CAE covers structurally different physics, and each domain carries its own terminology, governing assumptions, and failure modes. A structural statics query about bolt preload, a CFD query about y+ wall spacing, and a thermal query about contact conductance share almost no vocabulary. When these domains are mixed in one index without metadata, a query about "convergence issues" can retrieve a CFD turbulence note when the user is running a nonlinear structural solve.

The practical response is to tag every document with a domain field and to route or filter on it. A minimal domain taxonomy for a general-purpose CAE assistant looks like this:

Domain tagging is not cosmetic. It changes retrieval precision directly, because it lets the assistant apply a hard filter before similarity ranking. A query that mentions "y+" should never surface a structural contact tutorial, regardless of how similar the surrounding prose looks.

Solver documentation is structured, not prose

Solver documentation has a predictable internal anatomy: element or model definitions, material constitutive models, boundary and load keywords, solver control parameters, and output requests. Each of these has a name, a type, a default, and a valid range. This structure is an asset for retrieval, because it allows chunking by semantic unit rather than by fixed token count.

Consider a typical keyword entry. A naive fixed-window chunker might split the default value away from the parameter description, producing a fragment that says only "default = 1.0" with no context. A structure-aware chunker keeps the keyword name, its parameters, defaults, and constraints together. The difference in answer quality is substantial when a user asks "what is the default for this control and when should I change it?"

Keyword: *CONTACT_CONTROL
  Parameter: SCALE_FACTOR   type=real   default=1.0   range=(0.0, 10.0)
  Parameter: PENALTY_STIFF type=real   default=auto  range=(0.0, inf)
  Note: SCALE_FACTOR below 1.0 softens contact; use only when
        convergence stalls and penetration remains acceptable.

When documentation is ingested this way, the assistant can answer parameter-level questions with the default, the valid range, and the engineering caveat intact. That is the difference between a lookup tool and a usable engineering assistant.

Material databases require provenance and units discipline

Material data is the most error-prone part of the landscape. The same alloy may appear in a handbook, a vendor datasheet, and an internal test report with different values, different units, and different temperature ranges. A retrieval system that ignores provenance will happily mix them.

Every material record should carry, at minimum: material identifier, property name, value, unit system, temperature or strain-rate condition, source, and date. Units are the silent killer. A yield strength stored as 350 MPa and another as 350 ksi are numerically identical and physically wrong by a factor of roughly seven. The assistant must normalize units at ingestion and preserve the original in metadata.

Best practices are the hardest knowledge to retrieve

Best practices live in checklists, lessons-learned notes, internal wikis, and the tacit knowledge of senior engineers. They are unstructured, often contradictory across teams, and rarely versioned. Yet they are exactly what users ask for: "how should I set up this analysis?" Retrieval quality here depends on capturing the condition under which a practice applies, not just the practice itself.

A useful pattern is to store each practice as a condition-action pair with a scope tag. For example: condition = "nonlinear contact model with large sliding," action = "enable finite sliding and verify penetration," scope = "structural / nonlinear." This makes the practice retrievable by situation rather than by keyword coincidence.

How the four layers connect

The four knowledge layers are not parallel silos. A real query often crosses them: a user asks why a nonlinear structural model diverges, and the answer requires a solver control parameter, a material model assumption, and a best-practice note about contact setup. The assistant must retrieve across layers while keeping domain and provenance filters active.

The diagram shows the intended flow: four distinct knowledge layers feed a shared ingestion stage that attaches domain, unit, and provenance metadata, and retrieval applies those filters before ranking. The final answer is grounded because every retrieved fragment can be traced back to a specific layer and source.

A practical ingestion checklist

When preparing a CAE corpus for retrieval, verify the following before indexing. Each item maps to a failure mode observed in real assistant deployments.

• Domain tag present on every chunk; untagged content is quarantined, not indexed.
• Units normalized to a single internal system, with the original unit preserved in metadata.
• Source and date recorded for every material value and every best-practice note.
• Structure-aware chunking for solver documentation, so defaults and ranges stay with their keyword.
• Condition captured for best practices, so they are retrieved by situation, not by keyword.
• Version field on solver docs, because defaults and keyword names change between releases.

The knowledge landscape is the foundation of everything that follows. Domain tags control routing, structured documentation enables parameter-level answers, material provenance prevents unit and source errors, and condition-tagged best practices make tacit knowledge retrievable. With this map in place, the next stage—designing the retrieval pipeline itself—has a well-defined corpus to work against rather than an undifferentiated text dump.