Designing Business Worlds with Ontology and Flow: From Static Graphs to Dynamic Digital Twins

OntoFlow name origin

Ontology (Entity/State Machine) + Flow (Edge/Dynamics) builds on the OntoGraph temporal‑graph database to create a runtime‑capable digital world.

Problem with entity‑centric modeling

Listing entities such as Enterprise, User, Product, Warehouse, Hospital and filling them with attributes assumes business digitization is complete, but real business changes occur in the relationships between entities.

Examples:

Port status changes ( Port.status = Closed) but the critical change is the shipping route capacity dropping to zero – the transport relationship fails.

Supplier status degrades ( Supplier.status = Bad) while lead time expands from 5 days to 20 days – the supply relationship changes.

Hospital overload ( Hospital.state = Overflow) reduces daily referral throughput from 100 to 20 – the referral relationship is constrained.

Edges as first‑class business objects

In conventional graph databases an edge is only a connector. In OntoFlow an edge carries its own properties, timestamps, and aggregation logic, becoming an independent runtime object.

Factory F01 | SUPPLY | Warehouse W01 2026‑06: quantity 1000, lead 2 days, cost 5 2026‑07: quantity 800, lead 6 days, cost 7

The edge represents a time‑evolving business unit rather than a static line.

Core simulation loop

Universal logic: Flow change → State change → Flow change . Applied across domains:

Supply chain: material flow → inventory state → production plan adjustment.

Military: information flow → command state → new orders.

E‑commerce: traffic flow → user state → ad‑spend optimization.

Why traditional graph databases cannot perform true simulation

They provide only node aggregation and lack edge dynamics. Propagation path is Entity → Entity → Entity. For example, defining Truck.capacity = 100 is possible, but modeling a truck breakdown, road closure, or driver leave is not, because the limiting factor is the dynamic transport relationship.

Consequences:

Can produce a digital‑twin dashboard (static visualization).

Cannot build an operational world simulator that runs the business.

Five practical edge‑aggregation scenarios

Flow : volume sum – material, fund, people, energy flows.

Constraint : capacity min – railway capacity, bandwidth, production limits.

Delay : leadTime max – transport delay, approval cycle, repair time.

Confidence : average confidence – radar detection confidence, data trustworthiness.

Intent : priority + deadline – command orders, approval priority, task deadlines.

Edges as propagation links

Edges can store state and act as both source and node in a propagation chain. Example of a port delay chain:

Port delay → shipping route delay ↑ → warehouse inventory risk ↑ → distribution capacity ↓ → customer service level ↓

Propagation pattern: Edge → Entity → Edge → Entity , forming a World Runtime that autonomously propagates and evolves.

OntoFlow unified runtime

Both entity and edge are represented by DependencyGraphNode and share the same runtime semantics:

ENTITY(label, property)
EDGE(label, property)

This enables four propagation directions:

Entity → Entity

Entity → Edge

Edge → Entity

Edge → Edge

Full supply‑chain simulation path example:

Supplier inventory ↓ Supply quantity ↓ Factory input ↓ Production capacity ↓ Warehouse stock ↓ Distribution delay ↓ Customer service level

Key takeaway

Entity aggregation describes the current state of the world; edge aggregation describes how the world will change next. Achieving a runnable business‑world simulator requires:

Entity Aggregation (state description).

Edge Aggregation (flow description).

Property Runtime (driving evolution).

Combining ontology (state) with flow (dynamics) yields a continuously running, self‑evolving digital world capable of outputting decisions.