DataByte
Semantic Ontology

Your business as objects the platform can act on.

Orders, Customers, Shipments, and Network Elements become versioned, governed business objects. Each one carries its own relationships, generated APIs, workflows, lineage, and security policy. Every team reads the same definition.

Semantic topology of connected business objectsSix business objects across five domains: Product in Catalogue, Customer in Customer care, Order and Order Invoice in Orders, Network Element in Inventory, and Shipment in Logistics. They are joined by named relationships: a Customer places an Order, an Order contains an Order Invoice, includes a Product, and is fulfilled by a Shipment. A Product is provisioned on a Network Element, and a Shipment delivers one.placescontainsincludesfulfilled byprovisioned ondeliversProductCatalogueCustomerCustomer careOrderOrdersNetwork ElementInventoryOrder InvoiceOrdersShipmentLogistics
The shift

Model the business the way the business talks.

A table is an implementation detail. "Customer Order" is not. The Semantic Ontology lets the people who own a domain define it in the language they already use: an Order, a Product, a Shipment, a Network Element, each one a first-class business object, where today it is a join someone has to remember.

Underneath, every object stays bound to the real schemas and tables it is drawn from, across as many source systems as it takes. The business gets a concept it recognises. Engineering keeps the physical model. Neither side has to translate for the other in a meeting.

What a single ontology object carriesThe Order business object, published and version 1.0.11, in the Orders domain. It carries fields, named relationships, generated APIs, state transitions and actions, workflows and pipelines, table and column level lineage, datasets and consumers, and its own security, masking, and policy.OrderPublishedOrdersBound to the source schemas and tables it is drawn from, across every system.Fieldsschema and customRelationshipsnamed, directionalAPIsgenerated, versionedState transitionsand actionsWorkflowsand pipelinesData lineagetable and columnDatasetsand consumersSecuritymasking and policy
Semantic topology

See how the business actually hangs together.

Objects are connected by named, directional relationships: a Customer places an Order, an Order contains an Invoice, a Product is provisioned on a Network Element. The topology view renders that map across every domain at once, so the shape of the business is something you can look at. Today it lives in the heads of three people.

Because the relationships are declared rather than inferred from joins, they survive schema changes, and they are what lets an agent or an API traverse from a customer to their unpaid invoices without anyone writing the path by hand.

Semantic topology of connected business objectsSix business objects across five domains: Product in Catalogue, Customer in Customer care, Order and Order Invoice in Orders, Network Element in Inventory, and Shipment in Logistics. They are joined by named relationships: a Customer places an Order, an Order contains an Order Invoice, includes a Product, and is fulfilled by a Shipment. A Product is provisioned on a Network Element, and a Shipment delivers one.placescontainsincludesfulfilled byprovisioned ondeliversProductCatalogueCustomerCustomer careOrderOrdersNetwork ElementInventoryOrder InvoiceOrdersShipmentLogistics
Change control

A model with versions and a release process.

Objects are versioned semantically and move through draft, review, published, and deprecated. Before a change is activated, Compare shows exactly what was added, removed, modified, or renamed against the previous version, so a rename that would break ten downstream consumers is caught before it ships rather than after.

Every change lands in a semantic change feed with the actor and the timestamp attached, filterable by objects, relationships, or APIs. Model governance stops being an email thread.

Ontology object release lifecycleAn object moves from draft, through governance review, to a compare gate that reports what was added, removed, modified, or renamed against the previous version, then to published, and eventually to deprecated. Every change is versioned, attributed, and timestamped in the semantic change feed.DraftModel the objectIn reviewGovernance sign-offCompareAssess version impactPublishedLive for consumersDeprecatedRetired with noticeDiffed against the live versionaddedremovedmodifiedrenamedEvery change versioned, attributed, and timestamped in the semantic change feed.
Not a diagram that goes stale

Objects the rest of the platform reads from.

A modelling tool produces a picture. An ontology produces behaviour. Because every object is defined once and governed centrally, the rest of the platform reads from it directly instead of keeping its own copy.

APIs, per object

Each object exposes generated, versioned endpoints, so a consuming team integrates against Order rather than against four tables and a join.

Data Insider
Lineage, end to end

Table and column-level lineage per object, showing sources, pipelines, consumers, and column mappings in one view.

Data Catalog
Workflows and actions

State transitions, actions, and workflows attach to the object itself, so business rules live with the definition rather than in the tool that happens to run them.

ProcBot
Security and masking

Access, masking, and PII policy are set per object and inherited by every API, pipeline, and report that reads it.

Security and trust
Pipelines that stay bound

Transformation pipelines reference the object, so a schema change surfaces as an impact assessment rather than a 3am failure.

Transformer
Grounding for the agents

Plain-English questions resolve against defined objects and relationships instead of guessing at table names, which is what makes the answers reproducible.

The agentic layer
Where it runs

An ontology of your business, inside your own walls.

An ontology is the most sensitive artefact you will ever build. It is not your data, it is the map of how your business works: which entities exist, what they are worth, how they connect, and who is allowed to see them. That map is exactly what you least want sitting in a vendor's cloud.

DataByte's Semantic Ontology runs on the same footing as the rest of the platform: your Kubernetes, your cloud, or fully air-gapped on your own infrastructure, with the built-in agents reading it from self-hosted models. Nothing about how your business is structured has to leave the building for you to get the benefit of modelling it.

Bring your messiest domain.

We will model it as objects on the call and show you the topology, the generated APIs, and the lineage behind them.