Why a context layer?

Why not only connect an LLM to a database?

Database access exposes records. It does not by itself define a consistent identity, relationship model or business policy across systems. The proposed PatternLab context layer makes those meanings persistent and traceable.

A direct connection can be appropriate for a well-scoped question in a single system. The added context layer becomes useful as reasoning spans sources and business rules.

Why not only retrieval?

Retrieval helps find relevant information. Explicit relationships describe how things affect each other. A supplier-impact question may require Supplier → Material → Product → Order → Customer, not only passages containing a supplier’s name.

Retrieval and an ontology address different parts of that problem and can be used together. This release uses simple source search, not a production ontology or vector retrieval engine.

Why not only a knowledge graph?

A graph alone does not connect sources, maintain mappings, apply permissions, execute instructions or attach useful evidence. The product design brings these capabilities around a shared business model.

The technical direction

The work is determining what each source represents, which records refer to the same object, how objects relate, which rules apply, where facts came from and what changed. That is the context problem the architecture targets.

The implemented foundation is persistent Workspaces, source snapshots, limited checks, source-update Runs and evidence. Automatic mapping, identity resolution and AI reasoning remain unimplemented.