Skip to main content
Ontology theory represents the business world as an object space that can be identified, connected, and validated. It describes entities, relationships, and attributes together with the actions objects support, the policies that govern those actions, and the evidence required for execution.

​
Entities

An entity is an object that can be identified, referenced, and operated on. It can be a customer, an order, a metric, a semantic model, a database table, or a concept node in a knowledge graph. An entity should have:
  • Stable identifiers, such as external keys, internal entity IDs, and ontology IDs.
  • A type, such as semantic_indicator or database_table.
  • A readable name for search, display, and explanation.
  • Attributes describing state, fields, granularity, evidence, and runtime context.
Entities let the system locate a concrete object in a concrete resource and carry its model, fields, relationships, and query contract as context.

​
Relationships and Attributes

Relationships express structural links between entities, including containment, reference, navigation, dependency, derivation, and evidence association. For example, a semantic model contains Cubes, a database table contains columns, and a SAP OData Entity Set points to an Entity Type. Attributes are structured descriptions on entities and relationships. They can carry:
  • Resource state, version, and update time.
  • Execution context such as analysis_contract, query_capabilities, and key_schema.
  • Evidence such as aliases, sources, confidence, and mention samples.
  • Security boundaries such as write support, CSRF support, and sync truncation.
Structured attributes support reliable search, policy matching, and audit replay.

​
Actions and Policies

An action (affordance) describes how an object can be used. For example, a semantic metric can query trends, a database table can preview rows, and a SAP Entity Set can read a collection or update an entity. A policy decides whether an action is allowed, denied, or sent for approval under the current tenant, organization, resource, target, and risk. Actions should declare a target type, input schema, risk level, idempotency requirements, and execution effect. Agents can then discover available capabilities while the system validates their boundaries before execution.

​
Constraints and Validation

Constraints define how objects may be used:
  • Type constraints: an action applies only to specified entity types.
  • Parameter constraints: inputs must satisfy the action schema.
  • Business constraints: write actions may require approval or an idempotency key.
  • Runtime constraints: query limits, sync limits, and source metadata restrictions.
  • Permission constraints: policy bindings return allow, deny, or require_approval.
When the target object, action contract, parameter validity, or policy result cannot be confirmed, the system should reject execution or send it for approval instead of allowing an Agent to guess. This is the ontology system’s fail-closed principle.

​
From Objects to Execution

Agent execution should proceed through the object-semantic space:
  • Object location identifies the entity referenced by the user.
  • Neighborhood context provides related models, fields, relationships, and constraints.
  • Action discovery shows what the object can do now.
  • Simulation and validation check parameters, policies, and runtime conditions.
  • Real execution calls the adapter and records the result.
Context is disclosed progressively: resources and entity candidates first, then neighborhood, schema, action contract, risk, and approval information, and finally results, audit evidence, and review details. This controls context cost and reduces misuse.

​
Separating Semantics and Fact Execution

The ontology layer discovers objects, relationships, schemas, constraints, and context. The execution layer calls external resources, queries fact data, or triggers writes. For example, the ontology layer can identify which Cube contains a metric, while the semantic model adapter queries its value from the source; it can describe fields in a SAP Entity Set, while the SAP OData adapter performs the real read. Ontology snapshots, RDF, or local projections preserve reusable semantic facts. Action manifests and audit records preserve execution contracts and result evidence. This keeps semantics consistent while respecting each source system’s fact and permission boundaries.