Knowledge BaseMy Account
BGM

From records to operational objects

Core Data System

The core system is where operational data becomes queryable as objects, relationships, metadata, permissions, files, users, roles, and event history.

Core data system concept artwork
Canonical entities give the organization stable handles for the objects it actually works with.
Relationships make operational knowledge usable because they describe how entities influence, depend on, govern, trigger, or contradict one another.
Audit, lineage, and security need to live beside the model so the system can explain why it believes what it believes.
Core system theory diagram

Core entities

Articles, policies, vendors, products, assets, tickets, cases, documents, customers, employees, orders, locations, and workflows become operational objects.

Customers and accountsPolicies and workflowsProducts and assetsDocuments and tickets

Relationships

A relationship table can carry source entity, target entity, relationship type, confidence, weight, creator, and timestamp.

GovernsOwnsAffectsDepends onRelated to

Metadata and access

Tags, categories, custom attributes, lifecycle state, source system, roles, memberships, row-level security, and object permissions shape what can be seen.

Tags and categoriesCustom attributesRoles and permissionsData visibility

Audit and history

Change logs, version history, access logs, lineage, event history, and compliance logs help the system explain changes over time.

Change logVersion historyData lineageCompliance traces

The core system is the ontology foundation.

Once the relationships, permissions, and metadata are available, the next layer can build useful internal apps from them.

Continue to App Foundry