When a Glossary Needs Relationships and Business Rules

“How many active employees do we have?” looks like a simple count. It depends on what the organization means by active: a current contract on a given date, a particular status, or several conditions together.

A glossary helps locate employee records. A correct query also needs the definition and its relationships to other data.

Describe the relationships

A knowledge graph can express that a person has an employment contract, belongs to an organizational unit, or manages another person. It adds domain meaning to technical relationships in the schema.

Foreign keys provide a starting point. They do not establish which of several paths to use or how to handle historical records. Relationships also need conditions and limits.

For example, joining people to contracts may produce several rows per person. A question about headcount needs to account for that multiplicity.

Give definitions an owner

Someone responsible for the data should confirm the definition of an active employee. Record when the definition applies and which queries use it.

The agent can then connect the concept to the necessary tables and conditions. The generated query still needs validation: having a correct definition does not guarantee that the model applies it correctly.

Start with one recurring problem

There is no need to move the whole schema into a dedicated graph database. Relationships and rules can initially live in metadata or verified query patterns.

Choose a concept that repeatedly produces inconsistent answers. Document it, prepare examples, and check whether the added information resolves the failure. Expand the storage and traversal machinery as the relationships actually require it.