Business Graph: A Computable Foundation for Verifiable Business Reasoning

1. Introduction

Modern organisations are complex systems characterised by numerous interconnected and interdependent components, such as people, processes, resources, information systems, business objects, rules, events, goals, and metrics. Information describing these elements is typically distributed across heterogeneous enterprise systems, databases, documents, process models, and other sources [1]. Although these sources describe individual aspects of an organisation, they do not necessarily provide a unified, machine-interpretable representation of the organisation as a whole.

Such a representation could provide a common computational foundation for understanding organisational structure and state, tracing dependencies, analysing interactions between business elements, performing automated reasoning, and providing computational and AI systems with structured and verifiable business knowledge [2]. Large language models can process heterogeneous and unstructured business information, but their effective use in organisational settings requires a means of grounding this processing in an explicit representation of the organisation’s structure, state, and knowledge provenance [3]. The challenge is therefore not only to integrate enterprise data, but to construct an explicit and computable representation of the organisation itself.

Constructing such a representation, however, requires more than integrating heterogeneous information. Diverse business elements must be captured within a common semantic framework that supports querying and reasoning [2,4], while remaining adaptable to different levels of specialisation. These levels range from a general meta-model of organisational concepts, through domain-specific ontologies built upon it, to models of individual organisations and their evolving state. Specialisation across these levels should preserve the formal and computational semantics established at the general level [5,6,7]. The central problem is therefore how to represent an organisation as a unified formal and computable model that captures its structure and evolving state, preserves the origin and status of knowledge, maintains consistent semantics across levels of specialisation, and provides a common foundation for formal computation, reasoning, and LLM-based processing of business knowledge.

The representation must also support controlled interaction with computational and AI systems without replacing formal business knowledge with probabilistic processing [8]. Both asserted and derived knowledge should remain traceable and verifiable, preserving relevant temporal, epistemic, evidence, and provenance information [9]. This is essential for determining where knowledge comes from, under what conditions it holds, and how derived results are obtained.

Existing approaches address different parts of this problem. Enterprise modelling and business process representations provide abstractions for describing organisational structures and processes [5,6,7,10,11], while ontologies and knowledge graphs offer explicit semantic representations of entities and relations [2,4,12]. Knowledge representation and reasoning methods extend such representations with formal inference mechanisms [8,13], and recent approaches combining knowledge graphs with large language models explore how structured knowledge and symbolic reasoning can be integrated with natural-language interaction [3,14].

However, these capabilities are typically addressed separately or within approaches designed for particular aspects of organisational knowledge (see Section II for a detailed synthesis). This leaves an open problem of bringing them together within a unified computational representation of an organisation that combines explicit business semantics and reasoning with evolving organisational state, knowledge provenance, and controlled interaction with AI systems. Such a representation should also be expressible in a form that can be provided directly to large language models as structured input, enabling LLM-based processing while preserving the semantics and context of the represented business knowledge.

To address this gap, we propose the Business Graph, a formal computational model for representing an organisation as a typed, temporal, and evidence-aware graph. The model is organised around a minimal meta-ontology of general business categories, from which domain-specific concepts and organisation-specific entities are derived without altering the underlying computational semantics. The model is complemented by an algebra of business relations that provides explicit semantics for operations on organisational knowledge and supports querying and reasoning. Together, these components form a unified computational representation in which business entities, relations, states, events, and derived knowledge can be represented, reasoned over, traced, and verified. The framework is also designed to make this representation accessible to large language models and other computational systems through structured representations that preserve the relevant business semantics and context.

The main contributions of this work are threefold. First, we introduce the Business Graph, a formal model for representing the structure and evolving state of an organisation together with temporal, epistemic, evidence, and provenance information. The model is built on a minimal meta-ontology that supports specialisation from general categories to domain- and organisation-specific concepts without loss of computational semantics. Second, we define an algebra of business relations that provides explicit computational semantics for querying, composing, and reasoning over organisational knowledge. Third, we develop an interaction layer through which Business Graph knowledge and derived results can be exposed as structured, semantically grounded input to large language models and other computational systems, while preserving their connection to the underlying formal representation.

The remainder of the paper is organised as follows. Section II reviews related work in enterprise modelling, knowledge graphs, and knowledge-graph-enhanced language models, and positions the Business Graph with respect to these directions. Section III presents the Business Graph itself: its formal representation, executable semantics, and controlled interaction with vector-based methods and large language models, together with how these components form a coherent architecture, followed by a prototype implementation of parts of this architecture. Section IV illustrates the approach on two case studies. Section V concludes the paper with a discussion of its current scope and limitations and directions for future work.

2. Background and Related Work

The problem of constructing a unified computational representation of an organisation intersects several established research areas. Enterprise modelling and enterprise ontologies provide conceptual frameworks for describing organisational structures, processes, roles, and their relationships [5,7]. Knowledge graphs and Semantic Web formalisms provide machine-interpretable representations in which entities and relations can be given explicit semantics and used for querying and reasoning [2]. More recent research combines such structured representations with large language models, retrieval-augmented generation, and vector representations to enable natural-language interaction, contextual retrieval, and decision support [3,8,14]. Together, these research directions provide complementary foundations for representing organisational knowledge, reasoning over it, and making it accessible to computational and AI systems. The following discussion positions the Business Graph approach with respect to these complementary research directions.

Enterprise modelling provides an established tradition for systematically describing organisations. The Zachman Framework, later characterised as an enterprise ontology [5,6], organises descriptions of an enterprise across multiple perspectives and aspects, while Dietz and Mulder’s Enterprise Ontology [7] and the DEMO methodology model the essential organisation in terms of actors, transactions, and the commitments established through communication and action. Enterprise architecture approaches provide another related perspective: TOGAF defines a framework and method for developing and governing enterprise architectures [10], while ArchiMate provides a modelling language for representing and analysing relationships across business, application, and technology domains [11]. These approaches demonstrate that explicit modelling of organisational structure and behaviour is well established; the following discussion turns to knowledge-graph and Semantic Web formalisms that provide a computational representation for explicit relation semantics and automated inference.

Knowledge graphs and Semantic Web standards provide a formal basis for representing entities and relations computationally [2]. RDF Schema and OWL 2 [4,12] provide formally defined semantics for classes and properties, including domain and range specifications, property hierarchies, inverse properties, symmetry and asymmetry, transitivity, and property-chain axioms, enabling implicit knowledge to be derived through automated reasoning. Many of the core constructs used in the Business Graph relation model therefore have direct counterparts in established Semantic Web formalisms rather than constituting a new logical formalism. The Business Graph builds on this foundation by organising these constructs around a business-specific meta-ontology and by making temporal validity, provenance, and epistemic status, distinguished across five levels (observed, declared, derived, predicted, and hypothesised), explicit parts of the model.

KGLM [8] couples the Vadalog reasoning engine [13] with an LLM for natural-language interaction and explanation. Facts and rules are evaluated through the chase procedure, yielding derived facts and a chase graph that records their provenance, while the LLM is used to generate and refine natural-language explanations and fine-tuning data rather than to perform the underlying logical inference. Like the present work, KGLM thus separates formal reasoning from language generation and explains derived results by tracing their provenance. Both approaches rely on a generic reasoning mechanism operating over supplied facts and rules, but differ in the surrounding knowledge model. While KGLM operates over a user-defined schema, the Business Graph incorporates a general business meta-ontology and explicitly represents temporal validity and epistemic status as part of its knowledge model; the proposed framework also includes a separate vector layer for similarity and prediction.

A broader family of knowledge-graph-enhanced retrieval-augmented generation systems pursues a related goal, including graph-guided retrieval frameworks [15,16] and domain-specific variants for manufacturing and healthcare [17,18]. Wang et al. [14] exemplify this direction with an Integrated Knowledge-Enhanced Decision Support framework, in which a Dynamic Knowledge Orchestration Engine selects among knowledge-graph reasoning, RAG, and combined reasoning paths depending on the decision task, with evaluation across financial, healthcare, and supply-chain domains. These approaches demonstrate how graph-structured knowledge can guide retrieval, reasoning, and generation, but focus primarily on orchestrating these capabilities rather than defining a unified business knowledge model in which symbolic, epistemic, and vector representations are explicitly distinguished. Unlike Wang et al. [14], the present work has not yet been validated empirically across multiple domains.

Knowledge graph embedding methods [19,20] learn continuous vector representations of entities and relations, enabling tasks such as similarity estimation and link prediction alongside symbolic graph representations. The proposed Business Graph framework builds on this idea by introducing task-specific vector representations for entities, cases, processes, and subgraphs. Vector-based results are kept explicitly distinct from asserted or formally derived knowledge and are represented as predictions or hypotheses, allowing similarity-based discovery to complement rather than replace symbolic reasoning.

Taken together, these bodies of work address complementary aspects of the problem. Enterprise modelling and ontologies [5,6,7] provide systematic representations of organisational structure and behaviour, while RDF and OWL [4,12] provide formal semantics for machine-interpretable knowledge representation and inference. Neuro-symbolic systems such as KGLM [8] combine formal reasoning and provenance with LLM-based interaction, while KG-enhanced RAG systems [14,15,16] connect structured knowledge with retrieval and generation. Knowledge graph embeddings [19,20] further provide vector-based mechanisms for similarity and prediction, yet none of these approaches combines all of these capabilities within a single, formally defined model. For the problem considered here, these complementary capabilities motivate a unified business knowledge model combining a typed business meta-ontology, explicit relation semantics, temporal and epistemic information, provenance, symbolic reasoning, vector-based methods, and a controlled interface to LLMs. These requirements form the basis of the Business Graph approach developed in the following section.

3. Proposed Approach

The requirements identified in the previous section are addressed through the Business Graph (BG), presented here through four guiding questions. (1) How can a business be represented so that its structure and knowledge are formally defined? We address this through a business meta-ontology and relation algebra, specialised across three levels: a general meta-ontology, industry-specific concepts, and a particular organisation and its state. (2) What valid computations, queries, and inferences can be performed over this representation? We define executable semantics that make the formal representation computationally actionable. (3) How can probabilistic AI components interact with the formal model without replacing its knowledge and reasoning? We introduce controlled interaction with vector-based methods and large language models while preserving the formal model as the basis for knowledge and inference. (4) How do these components form a coherent architecture? We integrate the formal, executable, and probabilistic components into an overall workflow.

This section follows the same staged roadmap that guides development of the Business Graph platform [21]: the formal representation described above corresponds to its foundational stage, executable semantics to its query, reasoning, and contract stages, and AI interaction to its retrieval, vector representation, and language-modality stages. In addition to this architectural description, a prototype implementation that realises parts of it, together with its current scope and limitations, is reported separately.

3.1. Business Graph: Formal Model

We define a Business Graph as a formal representation of an organisation:

$$\mathrm{BG}=(E,R,A,V,T,S,M,\Phi ,\mathcal{E}),$$

(1)

where:

• E is a set of typed business entities;
• R is a set of relation types (predicates) with explicitly defined semantics;
• A is a set of assertions relating entities through predicates;
• V contains values and attributes associated with entities and relations;
• T represents temporal information, including time points and validity intervals;
• S represents states and state transitions;
• M contains metrics and their observations;
• $\Phi$ contains rules, constraints, and inference procedures;
• $\mathcal{E}$ represents evidence and provenance associated with assertions and derived knowledge.

Together, these components allow the BG to represent not only the structure of an organization, but also its evolving state and the knowledge available about it. The model may further be extended with a policy layer P that governs which parts of the graph and which operations are accessible to different users and computational agents.

The set E contains the business entities represented in a particular BG. Each entity is typed according to an ontology that defines the concepts used to describe the business and provides a common semantic structure for their interpretation. Since different industries and organizations require different vocabularies, BG does not prescribe an exhaustive universal business ontology. Instead, it defines a small and stable meta-ontology comprising the general categories Actor, Role, Activity, Process, Object, Resource, Capability, Goal, Metric, Rule, Event, State, and Evidence. These categories form a common foundation that can be specialized into domain-specific concepts, which are then instantiated as concrete entities in the BG of a particular organization. The relationship between these levels is illustrated below with representative examples.

The distinction between types and instances also applies to how relationships between business entities are represented in the BG. A relation is treated as a typed binary predicate over business entities. Each relation r has a defined domain and range, specifying the categories of entities that may occur as its first and second arguments, respectively; formally, $r\subseteq dom\left(r\right)\times range\left(r\right)$.

In the formal definition of the Business Graph, R defines the types and semantics of such relations, whereas A records assertions about which relations hold between specific business entities. A relation type $r\in R$ therefore belongs to the schema level, while an assertion $(a,r,b)\in A$ belongs to the instance level and states that $r(a,b)$ holds for particular entities $a,b\in E$ whose types satisfy the domain and range of r. Thus, R defines the admissible relationships in the Business Graph, while A records their concrete instances in a particular organisation. For example, consider the relation $USES$, which represents the use of a resource by an activity. Its schema- and instance-level representations are shown below.

Together, schema-level relation definitions and instance-level assertions provide the basis for formal inference over the Business Graph.

The semantics of relations in the Business Graph are specified explicitly, determining how relations may connect entities and how they can be used in inference. The main semantic characteristics and constructs are summarized below.

Domain and range. These specify the categories of entities that may occur as the first and second arguments of a relation, respectively. Assertions involving incompatible entity types can therefore be rejected, helping maintain semantic consistency across the graph.

Symmetry and antisymmetry. A relation is symmetric if $r(a,b)\Rightarrow r(b,a)$, and antisymmetric if $r(a,b)\wedge r(b,a)\Rightarrow a=b$. In the BG, symmetry permits an assertion represented in one direction to support inference in the reverse direction, while antisymmetry prevents the same relation from holding in both directions between distinct entities, as required for hierarchical relations such as $PART\_OF$.

Transitivity. A relation is transitive if $r(a,b)\wedge r(b,c)\Rightarrow r(a,c)$. In the BG, transitivity permits new assertions to be inferred along chains of the same relation. It must be defined explicitly for each relation type, since the existence of a path does not by itself imply a direct relation between its endpoints.

Relation hierarchy. Relation types may themselves be related through specialization: a relation type may specialize a more general relation, so that $r_1(a,b)\Rightarrow r_2(a,b)$ whenever $r_1$ is a sub-relation of $r_2$. For example, $USES\subseteq DEPENDS\_ON$ implies that every $USES$ assertion is also a $DEPENDS\_ON$ assertion. This enables queries and analyses over general relations to include their specialised forms.

Relation families. The same grouping impulse behind relation hierarchy, applied more loosely than formal subsumption, also yields representative families such as structural, operational, dependency, process, goal, normative, and evidential relations. This is an expository classification of the relation vocabulary rather than a further formal property, and it does not prescribe an exhaustive set of relation types.

Beyond these static properties, relations support operations that construct new relations from existing ones and determine what may be inferred from paths in the graph.

Inverse. The inverse operation reverses a relation by exchanging its arguments: for a relation r, $r^{-1}(b,a)\iff r(a,b)$. In the BG, an inverse relation type may be explicitly defined, making the reverse relation available without storing both directions as separate assertions; for example, $HAS\_PART=PART\_O{F}^{-1}$.

Permitted compositions. Composition combines two relations through a shared intermediate entity b: $r(a,b)\wedge s(b,c)\Rightarrow (s\circ r)(a,c)$. A path $a\stackrel{r}{\to }b\stackrel{s}{\to }c$ therefore establishes that c is reachable from a, but it does not by itself license a new assertion between a and c. Such an assertion can be derived only when the corresponding composition is explicitly defined in the BG relation semantics.

The same distinction applies to chains of a single relation. From $r(a,b)$ and $r(b,c)$, c is reachable from a; the direct assertion $r(a,c)$ follows only if r is defined as transitive. Thus, graph reachability and logical inference are distinct: reachability depends on the existence of a path, whereas inference depends on the explicitly defined semantics of the relations along that path.

Every assertion in the Business Graph, whether it records a value, a state, or a relation between entities, may be associated with a validity interval $[t_1,t_2)$ during which it is taken to hold. Composition of relations must respect these intervals: if $r(a,b)$ is valid over $[t_1,t_2)$ and $s(b,c)$ over $[t_3,t_4)$, the derived assertion $(s\circ r)(a,c)$ is valid only over the intersection of their validity intervals,

$$valid\left(\right(s\circ r\left)\right(a,c\left)\right)=valid\left(r\right(a,b\left)\right)\cap valid\left(s\right(b,c\left)\right).$$

We write ${\mathrm{BG}}_t$ for the state of the Business Graph restricted to assertions valid at time t, so that the model can be queried as of any point in its history rather than only its current snapshot. This is essential for tracking how organisational roles, processes, and dependencies evolve over time, and for supporting historical and audit-style analysis.

Beyond its predicate and arguments, every assertion $\alpha$ in the Business Graph carries an epistemic status,

$$\begin{array}{c}status\left(\alpha \right)\in \{observed,declared,derived,\hfill \\ \hfill \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}predicted,hypothesis\},\end{array}$$

distinguishing directly observed or declared knowledge from formally derived knowledge, vector-based predictions, and unconfirmed hypotheses. These statuses are not freely interchangeable. The status of a derived assertion depends on the statuses of its premises and on the applicable inference rule. In particular, predicted or hypothetical knowledge must not silently acquire the status derived: uncertain knowledge cannot be promoted to formally established knowledge merely by participating in an inference. Every assertion may also be linked to evidence in $\mathcal{E}$, recording the source that substantiates it, such as a transaction record, signed document, or sensor measurement. For a derived assertion, provenance additionally records the premises and rules involved in its derivation. Thus, if an assertion ${\alpha }_3$ is derived from premises ${\alpha }_1$ and ${\alpha }_2$ using rule $\varphi$, its provenance may be represented as

$$provenance\left({\alpha }_3\right)=\{{\alpha }_1,{\alpha }_2,\varphi \}.$$

Derived assertions therefore retain a proof lineage through the assertions, evidence, and rules on which they depend, providing a basis for tracing, explaining, and verifying the results of formal reasoning.

Taken together, the meta-ontology, relation algebra, temporal semantics, and epistemic and provenance mechanisms provide a common formal representation of organisational knowledge. Relations have explicit semantics, assertions are qualified by temporal validity and epistemic status, and derived knowledge can be traced to its premises and evidence. Additional rules and constraints in $\Phi$ specify which assertions may be derived and which combinations are admissible. The individual mechanisms used in this model have direct counterparts in established formalisms such as OWL and RDF Schema, and are not introduced here as novel constructs. The contribution of the Business Graph lies in integrating them with a business-specific meta-ontology into a coherent model in which organisational knowledge can be represented and subjected to controlled computation. Having established the formal representation, we now turn to its executable semantics: the queries, derivations, and analyses that can be performed over the Business Graph.

3.2. Executable Business Graph

A Business Graph is not only a representation or storage layer. Because its entities are typed and its relations and rules have explicit formal semantics, well-defined operations can be executed over the graph. Executability here means that assertions can be validated against the schema, the current or historical structure and state of the organisation can be queried, new assertions can be derived from existing ones, dependency and impact analyses can be performed, and results can be traced to the evidence and rules on which they depend.

This executable behaviour rests on a separation of concerns among three components. The relation algebra introduced in the previous section defines the meaning of relations independently of how operations over them are executed. The reasoner uses these semantics together with the rules in $\Phi$ to derive new assertions. The query engine is responsible for executing queries by retrieving and combining assertions according to these semantics. This separation of meaning, inference, and execution allows execution strategies to be optimised without altering the conclusions licensed by the formal model.

The reasoner carries out inference within the executable Business Graph by computing the closure $C{l}_{\Phi }\left(\mathrm{BG}\right)$, the smallest extension of the graph containing all assertions derivable under the explicitly defined relation semantics and the rules in $\Phi$, such that $\mathrm{BG}\subseteq C{l}_{\Phi }\left(\mathrm{BG}\right)$. It may thereby derive new assertions through mechanisms such as transitivity and permitted composition, but it does not introduce relation semantics of its own: the meaning of each relation remains fixed by the relation algebra defined earlier. Every assertion produced by formal inference is assigned the epistemic status $derived$ and retains provenance linking it to the premises and rules used to obtain it. Inference also respects the temporal and epistemic conditions established in the formal model, including the validity intervals and epistemic statuses of its premises.

Higher-level business analyses are constructed over the same formal semantics by combining relation traversal, closure, and permitted composition. For a relation r, its transitive closure is defined as $r^{+}=r\cup r^2\cup r^3\cup \dots$, with $r^2=r\circ r$, capturing reachability through repeated traversal of r. As noted in the previous section, such reachability licenses corresponding direct assertions only when r is defined as transitive. Compositions of relations $r_1,\dots ,r_n$ similarly allow paths involving different relation types to produce derived relations when such compositions are explicitly permitted. More generally, an analysis may operate over a selected family $D\subseteq R$ of semantically related predicates and their admissible compositions, restricting traversal and derivation to paths whose meaning is defined by the model. This provides a common formal basis for dependency, impact, responsibility, process-decomposition, single-point-of-failure, and bottleneck analyses rather than treating each as an unrelated graph algorithm. Crucially, the existence of a graph path alone does not establish a business dependency or impact: higher-level conclusions follow only from paths licensed by the defined relation semantics.

We introduce the Business Graph Query Language (BGQL) as a portable query language for querying and analyzing the Business Graph. BGQL combines graph pattern matching with higher-level business operators such as WHY, IMPACT, SPOF, and BOTTLENECK, which expose semantic analyses over the graph as explicit query operations. Pattern matching retrieves assertions in A satisfying specified combinations of entities and relations, while higher-level operators provide direct access to predefined analytical operations over the relation semantics and inference mechanisms of the Business Graph. The following examples illustrate representative BGQL constructs; a complete specification of the language is beyond the scope of this paper. A basic pattern query retrieving activities and the resources they use can be written as

MATCH (a:Activity)-[:USES]->(r:Resource)

RETURN a, r

while a higher-level analytical query may take the form

WHY bg:object/order/81772

METRIC bg:metric/order-cycle-time

DEPTH 4

where the WHY operator requests an explanation with respect to a specified metric and analysis depth. BGQL is defined against the semantics of the Business Graph rather than a particular physical graph database. A query therefore specifies what is to be retrieved, derived, or analysed in terms of the formal model, independently of how the computation is executed. Within this roadmap, BGQL corresponds to the query and reasoning stage [21].

The separation between meaning, inference, and execution introduced earlier in this section is realised architecturally as a pipeline from semantics to a logical plan and, finally, to a physical plan. A query is first interpreted against the formal semantics of the Business Graph, producing a logical plan expressed in terms of its relations, rules, and analytical operations. This logical plan is then translated into a physical plan describing how the computation is actually executed. The optimiser performing this translation may exploit formally defined relation semantics, such as declared transitivity, inverse relations, and admissible compositions, to select a more efficient execution strategy, but it may not introduce semantic assumptions merely because they would simplify or accelerate a particular query. The reasoner therefore remains an explicit operator in the execution pipeline rather than an inference mechanism that the optimiser may silently introduce or remove. A physical plan may be realised over different backends, such as an in-memory graph engine, RDF/SPARQL or SQL adapters, or a specialised analytics engine.

Because the execution pipeline is explicit, query results can retain the information required for reproducibility and auditability. A result is linked to the query that specified it, the logical and physical plans used to compute it, the version of any applicable policy, and a checksum of the graph snapshot over which it was evaluated. Together with the evidence and provenance carried by the underlying assertions, these records make it possible to trace and audit not only what was concluded, but also how and under what conditions the result was obtained. This provides a basis for auditable business reasoning, in which computational results need not be treated as one-off outputs of an opaque process.

Having established this executable and auditable layer, we now turn to how probabilistic AI components, in particular vector-based methods and large language models, can interact with it in a controlled manner.

3.3. AI Interaction with the Business Graph

The interaction between the Business Graph and probabilistic AI components is organised around a single principle: neural understanding, symbolic execution. Probabilistic components may interpret intent, identify similarities, retrieve relevant information, and generate predictions or hypotheses, while formal knowledge, exact querying and inference, authorisation, and provenance remain governed by the executable Business Graph.

This principle assigns distinct responsibilities to three components. A large language model handles natural-language understanding, intent interpretation, and the explanation of results in ordinary language; its outputs do not by themselves constitute formal assertions in the Business Graph. The symbolic Business Graph layer, comprising the relation algebra, reasoner, query engine, and policy layer, remains responsible for formal knowledge, exact querying and inference, authorisation, and provenance. A vector layer, introduced below, supports similarity-based retrieval, prediction, and hypothesis generation. The large language model and vector layer therefore complement the executable Business Graph rather than replace its formal knowledge and reasoning mechanisms.

Interaction with the Business Graph is structured through a contract-based pipeline that makes the transition from natural-language intent to formal execution explicit. Semantic Intent represents the interpreted request grounded in the Business Graph; the QueryContract specifies what is being requested; Conversation/Patch maintains and updates the semantic state across interactions; the ExecutionContract specifies what will actually be computed; and the Result Contract records the resulting data, claims, evidence, and lineage. The query to which a reproducible result is bound in the preceding section corresponds to this QueryContract. By representing these stages explicitly rather than mapping natural-language intent directly to execution, the architecture makes the transformation from language to formal computation inspectable and preserves a clear boundary between interpretation and execution. Within this roadmap, this contract pipeline corresponds to the Contracts stage [21].

In a multi-turn interaction, the semantic conversation state is updated incrementally through patches,

$$C(t+1)=ApplyPatch\left(C\right(t),P(t\left)\right),$$

where $C\left(t\right)$ denotes the current semantic state and $P\left(t\right)$ an update resulting from a subsequent interaction. This allows clarifications or revisions to modify the relevant parts of the semantic state without requiring the interaction to be represented as a new request from scratch.

Retrieval over the Business Graph is organised as graph-first and evidence-oriented, rather than being centred on unstructured-text retrieval. The retrieval space is defined as

$$Retrieval=Graph+Events+Metrics+Documents.$$

Vector-based search over documents is therefore one retrieval channel among several, rather than an authoritative source of formal knowledge. Document chunks are connected to the formal model through relations such as $MENTIONS$, $SUPPORTS$, and $EVIDENCE\_FOR$, so that a retrieved passage remains linked to the Business Graph entities it concerns rather than being treated as free-floating text. Before information is passed to a large language model, relevant facts, paths, events, metrics, and documents are assembled into an Evidence Package. This allows generation to be grounded in structured business knowledge and its supporting evidence rather than in retrieved text alone. Within this roadmap, this graph-first retrieval mechanism corresponds to the Hybrid RAG stage [21].

Beyond graph-first retrieval, the Business Graph can be complemented by a continuous vector representation layer, $bg2vec$, comprising multiple task-specific representations rather than a single universal embedding. Several such representations are proposed: $Entity2Vec$ and $Relation2Vec$ for individual entities and relations, $Case2Vec$ for entire cases or scenarios, $Process2Vec$ for processes, and $Subgraph2Vec$ for arbitrary subgraphs. Each representation may in turn be computed over different contextual views, such as operational, risk, financial, organizational, or temporal aspects of the same underlying data. This vector layer is presented here as a proposed research direction: unlike the formal representation and executable semantics described in the preceding sections, its implementation and empirical evaluation have not yet been established. Within this roadmap, bg2vec corresponds to a later stage [21].

The epistemic distinctions established earlier for Business Graph assertions also apply to outputs originating from the vector layer. Vector methods operating over $bg2vec$ representations may identify similar cases, anomalies, candidate missing links, and probabilistic dependencies, but such findings retain the epistemic status $predicted$ or $hypothesis$, rather than $derived$: similarity or proximity in vector space does not itself constitute formal inference. Symbolic reasoning, by contrast, produces $derived$ assertions together with explicit proof lineage, as described above. The two layers can interact in complementary ways: a symbolic filter may narrow the space of candidates before vector ranking is applied, while vector-based retrieval may propose candidates that are subsequently evaluated against the formal model. In both patterns, probabilistic methods extend the space of candidates that can be identified, while formal semantics determines which assertions are licensed by the Business Graph. This separation makes the neuro-symbolic character of the architecture explicit without conflating probabilistic prediction with formal inference.

A more ambitious, longer-term direction is to treat the Business Graph not only as a model queried through BGQL, but as a distinct modality that a large language model can process through a dedicated representation pathway, analogous to the integration of image representations in vision-language models. Rather than serialising an entire enterprise graph into text, a query-aware selector first identifies a relevant subgraph; a $BGTokenizer$ forms structured units from this selection; a $BGEncoder$, potentially building on $bg2vec$, transforms them into continuous representations; and a projector or $BG$-QFormer maps these representations into a compact set of graph tokens that can be processed jointly with textual input by a multimodal language model. For large enterprise graphs, an alternative is to treat the Business Graph as external graph memory: the language model forms a query state, the relevant portion of the graph is selected, and cross-attention is restricted to this selection rather than applied to the graph as a whole. In either architecture, formal operations remain the responsibility of BGQL and the reasoner rather than the language model itself. This graph-as-modality integration represents a longer-term stage of the proposed roadmap [21] and is presented here as an architectural research direction rather than an already validated component.

3.4. Integrated Architecture and Workflow

The components introduced throughout this section combine into a single end-to-end architecture. Data from enterprise sources are integrated into the Business Graph, over which BGQL, the reasoner, and the analytical operations described earlier operate. A vector layer interacts with this symbolic layer to support similarity-based retrieval, prediction, and hypothesis generation. The resulting data and claims, together with their supporting evidence and lineage, are organized into a ResultContract and passed to a large language model, which produces an explanation or decision-support output grounded in this evidence rather than generated from the user request alone. Policy, temporal validity, and provenance operate across this architecture as cross-cutting concerns: execution is subject to authorization, assertions and results can be temporally qualified, and derived knowledge retains links to its premises and supporting evidence. Taken together, the architecture connects natural-language intent through explicit query and execution stages to evidence-grounded results and explanations, reflecting the target architecture of the broader system roadmap [21].

To illustrate this pipeline concretely, consider a user asking why Order #81772 was delayed. Semantic Intent identifies this as a $WHY$ request concerning a specific order, and the corresponding QueryContract specifies the target object and the relevant metric, order cycle time, as in the query introduced earlier. BGQL then retrieves the relevant events, metrics, and formally defined dependencies associated with the order. The reasoner and analytical operations evaluate these elements under the relation semantics and rules of the Business Graph and, where licensed by the formal model, derive claims explaining the observed delay. Evidence and provenance are collected alongside these claims, linking them to the underlying assertions, events, metrics, and applied rules. Finally, the large language model transforms the structured result and its supporting evidence into a natural-language explanation for the user. This and related scenarios are examined in greater detail in the case studies.

Taken together, the Business Graph architecture combines three complementary spaces: symbolic knowledge and execution, vector-based similarity and prediction, and language understanding and explanation. These spaces are not merged into a single undifferentiated AI component; each retains a distinct epistemic role, so that formal assertions, probabilistic outputs, and natural-language explanations remain explicitly distinguishable throughout the pipeline. A prototype implementation of parts of this architecture is described in the following section, providing the basis for the case studies presented afterwards.

3.5. Prototype Implementation

We developed a compact reference prototype [22] in Python 3.11. It targets Business Graph version 0.3 and makes the core abstractions executable. The prototype is designed for inspection rather than production use or performance benchmarking. Its components are kept separate so that each processing step remains visible.

Graph representation and validation A Business Graph is exchanged as a JSON document. The document contains its schema and typed entities. Assertions and events describe the business state; metrics and evidence provide supporting context. Validation has two stages. JSON Schema Draft 2020-12 checks the document structure. A semantic validator then checks identifiers and references between records. It also checks relation types and selected domain-range constraints. Predicted or hypothetical assertions must refer to evidence. These checks cannot be expressed through local JSON structure alone. The relation catalog records semantic properties independently of the stored assertions. It distinguishes semantic inference from analytical reachability. As a result, a path found by an IMPACT query does not become a new direct assertion. Each assertion can retain its temporal validity and business context. It can also retain confidence, epistemic status, and links to evidence.

Semantic query and reasoning pipeline The current natural-language interface is deliberately deterministic. Ordered patterns identify a limited set of intents. Entity mentions are then resolved against the selected graph snapshot. The result is a QueryContract with the interpreted intent and grounded subject. It also records confidence and parsing provenance. If essential information is missing, the contract contains a blocking clarification instead of executing an ambiguous query. An LLM is not used for intent recognition in the current prototype. A future model-based parser could support more varied language. It would still have to produce the same QueryContract and ground its references against the graph. Executable contracts are compiled to Business Graph Query Language (BGQL). The implemented subset supports typed graph patterns and variable-length paths. Patterns may be optional or test that a relation does not exist. Queries support filtering and aggregation. They also support ordering and result limits. BGQL defines four analytical operations: WHY, IMPACT, SPOF, and BOTTLENECK. A baseline planner estimates cardinalities from graph statistics. It records an inspectable logical plan and an approximate cost. The current executor does not use this plan as a separate physical execution program. Relation-algebra reasoning is implemented as a fixed-point procedure over an explicit rule profile. The profiles contain selected transitive and subproperty rules, as well as several relation compositions. For example, responsibility can imply participation in an activity or its containing process. Every inferred assertion is marked as derived. It records both the rule and its source assertions. The reasoner propagates the lowest input confidence and intersects validity intervals. It rejects derivations whose contexts conflict. Dependency relations used only for reachability are never materialized by this procedure.

Execution and persistence The prototype provides an in-memory execution path and a persistent path. The in-memory engine executes the supported BGQL patterns. It can also query a reasoned closure. The persistent path stores the canonical graph snapshot in PostgreSQL. The same transaction writes normalized rows for efficient access. A graph identifier and a SHA-256 checksum identify the exact snapshot. Apache AGE provides a rebuildable graph projection for pattern queries. PostgreSQL remains the canonical source; rebuilding the AGE projection does not change the snapshot. The analytical operations are implemented as deterministic reference procedures. IMPACT follows incoming dependency relations to a bounded depth. WHY returns events linked to the target and upstream dependency findings. SPOF identifies simple concentration candidates. BOTTLENECK uses event density to identify candidates. These procedures are limited heuristics. They are not validated causal or resilience analyses. They also do not constitute a complete process performance method. For example, the current code does not compare stage duration with a service-level target. It does not search for alternative failover paths either. Temporal and contextual filters are not yet applied by every analytical operation.

Result contracts and evidence Before execution, the prototype creates an ExecutionContract. It binds the compiled query to the source QueryContract and the exact graph checksum. It also records the selected engine and its limits. Execution is rejected if the provided graph does not match this identity. The output is stored in a ResultContract. This contract links back to the execution identifier and checksum. It separates result data from factual claims, warnings, and evidence references. The current lineage is sufficient to trace a result to its query and graph snapshot. It does not yet explain every claim at the level of individual execution operators.A separate PostgreSQL retrieval component supports snapshot-scoped full-text search. It can also rank supplied embeddings by cosine similarity. Retrieved document chunks remain linked to evidence records and to the graph snapshot. Retrieval is not yet invoked automatically by the analytical executor.

LLM presentation boundary The prototype includes an optional LLM renderer after symbolic execution. The renderer accepts a validated ResultContract; it does not give the model direct access to the graph. Its prompt contains the contract’s claims and evidence references. Missing data and execution warnings are included explicitly. The model must return a JSON object. The object contains the answer and a status that is either supported or abstained. A supported answer must cite at least one claim identifier. The renderer rejects claim or evidence identifiers that do not occur in the source contract. The accepted answer records the model identifier and the checksum of the result it presents. This boundary keeps the LLM in a presentation role. The model cannot add claims to the authoritative ResultContract. References outside that contract are rejected. This check does not prove that every phrase in the generated text is semantically faithful. The implementation therefore supports different model providers through an injected adapter while preserving the symbolic result as the authority.

LLM rendering evaluation We evaluated the presentation boundary using two models: nvidia/ nemotron-3.5-lightning [23] and inclusionai/ling-3.0-flash-fin [24] were selected to compare a fast general-purpose LLM with a finance-oriented model under the same contract-constrained rendering protocol. The evaluation contained five synthetic ResultContract instances. Three contracts supported an answer, while two required abstention. Each contract was rendered once with temperature zero and a 600-token output limit. Reasoning output was disabled. Ling does not advertise structured-output support, so its run relied on prompt-level JSON instructions and the same renderer validation. The evaluation measured whether the response passed the renderer protocol. It also compared cited claims with a case-specific expected set. Evidence coverage and evidence-to-claim alignment were measured separately. A strict pass required the expected status, complete claim coverage, relevant citations, and aligned evidence.

Table 1. Responce evaluation.

Metric	Nemotron 3.5 Lightning	Ling 3.0 Flash Fin
Protocol adherence	5/5 (100%)	5/5 (100%)
Status accuracy	5/5 (100%)	5/5 (100%)
Abstention accuracy	2/2 (100%)	2/2 (100%)
Mean required-claim recall on supported cases	72.2%	100%
Relevant-claim precision on supported cases	100%	91.7%
Required-evidence recall on supported cases	100%	100%
Evidence alignment	4/5 (80%)	5/5 (100%)
Clean abstention under the evaluation policy	0/2 (0%)	0/2 (0%)
Strict case pass rate	1/5 (20%)	2/5 (40%)

Table 1. Responce evaluation.

Metric	Nemotron 3.5 Lightning	Ling 3.0 Flash Fin
Protocol adherence	5/5 (100%)	5/5 (100%)
Status accuracy	5/5 (100%)	5/5 (100%)
Abstention accuracy	2/2 (100%)	2/2 (100%)
Mean required-claim recall on supported cases	72.2%	100%
Relevant-claim precision on supported cases	100%	91.7%
Required-evidence recall on supported cases	100%	100%
Evidence alignment	4/5 (80%)	5/5 (100%)
Clean abstention under the evaluation policy	0/2 (0%)	0/2 (0%)
Strict case pass rate	1/5 (20%)	2/5 (40%)

Nemotron answered the responsibility question completely. Its two broader answers were grounded but incomplete. It omitted the approval dependency in the delayed-order case. In the impact case, it omitted an indirect effect and cited organizational evidence without citing the related ownership claim. Ling covered every required claim in the three supported cases. Its delayed-order answer included both the SLA deviation and the dependency on approval. Its impact answer also included the indirect effect. However, it added the true but nonresponsive ownership claim, which reduced claim precision. Both models assigned the correct abstained status to the insufficient-information cases. Nemotron returned only the word abstained. Ling gave a useful missing-data explanation for the inactive approval task, but returned only Unknown for failover. Both models attached nonresponsive claims to their abstentions and therefore failed the clean-abstention criterion. These results indicate strong protocol compliance from both models. Ling showed better coverage on this small set, while Nemotron avoided adding a nonresponsive claim to supported answers. Reference validation prevented unknown identifiers, yet it did not prevent omissions or irrelevant known claims. The evaluation is small and uses one run per synthetic case. It should therefore be treated as a diagnostic of the rendering protocol, not as a general model benchmark.

Experimental graph-aware retrieval We implemented an isolated retrieval experiment provisionally named bg2vec. It is not connected to the PostgreSQL retrieval component or to automatic query execution. A versioned deterministic renderer converts a synthetic Business Graph into 33 retrieval units. The record-only condition renders entities, assertions, events, and evidence separately. The graph-aware condition keeps the same root unit identifiers but adds incident one-hop assertions. The serialized form preserves relation direction, epistemic status, context, validity, and evidence references. It marks reachability-only relations and does not create a direct assertion for the endpoints of an indirect path. The experiment compared four conditions: a token-overlap lexical baseline; voyage-4 embeddings over record-only units; 1024-dimensional voyage-4 embeddings over graph-aware units; and graph-aware retrieval followed by Voyage rerank-2.5. Voyage-4 [25] and rerank-2.5 [26] were chosen to support a modern two-stage multilingual retrieval pipeline, combining semantic embedding retrieval with instruction-aware reranking. Vector ranking used exact cosine similarity. The initial candidate set contained ten units and the recorded final set contained five. The graph, retrieval judgments, renderer version, model identifiers, and configuration were checksum-bound in the result artifact. Embedding vectors and credentials were not persisted. The nine synthetic questions reused five development scenarios from the renderer evaluation and added four held-out paraphrase or relation confusion questions. Six questions had answer-supporting records; three represented missing knowledge. Retrieval units were judged against graded assertion and event identifiers. Recall and evidence recall measured unique supporting records covered by the retrieved units. Mean Reciprocal Rank (MRR) and Normalized Disconted Cumalative Gain(nDCG) measured answer-supporting rank positions. The table below reports the four-question held-out split, of which three questions were answerable.

Table 2. Retrieval evaluation.

Condition	Recall@1	Recall@3	Recall@5	MRR@10	nDCG@5	Evidence recall@5
Lexical, record only	33.3%	44.4%	55.6%	0.511	0.451	83.3%
voyage-4, record only	55.6%	66.7%	66.7%	1.000	0.852	100%
voyage-4, graph-aware	66.7%	77.8%	100%	1.000	0.861	100%
Graph-aware + rerank-2.5	66.7%	100%	100%	1.000	0.896	100%

Table 2. Retrieval evaluation.

Condition	Recall@1	Recall@3	Recall@5	MRR@10	nDCG@5	Evidence recall@5
Lexical, record only	33.3%	44.4%	55.6%	0.511	0.451	83.3%
voyage-4, record only	55.6%	66.7%	66.7%	1.000	0.852	100%
voyage-4, graph-aware	66.7%	77.8%	100%	1.000	0.861	100%
Graph-aware + rerank-2.5	66.7%	100%	100%	1.000	0.896	100%

All four conditions also placed at least one context-related unit in the top five for every missing-knowledge question. Candidate relevance therefore does not itself provide an abstention decision. The recorded run used 14,923 embedding tokens and 37,257 reranking tokens. Its measured latency includes deliberate request spacing for the provider’s reduced rate limit and is not a performance result. These values describe one run over a small, authored synthetic graph. The test questions are paraphrases over the same graph rather than an independent dataset, and the judgments were manually specified. The experiment therefore tests the retrieval protocol and the effect of its serialization choices; it does not establish production effectiveness or general superiority. In particular, bg2vec here denotes graph-aware textual serialization combined with an external embedding model, not a learned structural graph embedding.

From implementation mechanisms to illustrative cases The prototype now covers the main processing boundaries. It validates a graph and grounds a constrained question. It then executes symbolic operations and binds the result to a snapshot. The optional LLM renderer can present validated claims without replacing them. The following section applies these mechanisms to two synthetic scenarios. The first explains a delayed order. The second examines the possible impact of a payment-service failure. Their outputs are representative rather than empirical results. The exact datasets are not yet included as executable fixtures. The automatic connection between analytics and evidence retrieval also remains to be completed

4. Case Studies

This section builds on the implementation described in previous section. It presents two scenarios for a hypothetical online retailer. Both use the same order-to-cash model and connect it to organizational and application knowledge. The first scenario asks why an order was delayed. The second asks what may be affected by a payment-service failure. They illustrate retrospective explanation and prospective impact analysis, respectively. The cases are deliberately illustrative rather than empirical. Their purpose is to make the intended behavior and boundaries of the approach concrete, not to establish its effectiveness in a production organization. The data are synthetic but model realistic enterprise sources. Process definitions provide the business structure. System events provide observations. Policies and technical documents provide supporting evidence. The exact case datasets and complete orchestration are not yet packaged as an end-to-end executable artifact. Instead, each case shows the intended workflow. The input first becomes a versioned Business Graph. Symbolic operations then produce a structured result. Evidence can be selected for that result, after which the LLM renderer can produce a user-facing answer. A separate executable retrieval-protocol fixture captures a compact subset of both scenarios. It is used by the bg2vec experiment reported in Section IIIE, but it does not implement the complete case workflows described here. In the current prototype, natural-language intent recognition and graph grounding are implemented using a deterministic semantic layer. This makes query construction reproducible. An optional LLM renderer is available after execution. It receives validated claims from the ResultContract and must cite their identifiers. Unknown references are rejected. The renderer improves the presentation but does not become an authority for business facts. The current execute flow does not invoke a model provider automatically. It also does not yet connect retrieval to the renderer. The examples below therefore distinguish implemented mechanisms from representative case results.

4.1. Case Study 1: Explaining a Delayed Order

Scenario and input knowledge The first case concerns an individual order, Order-81772, that was not released to fulfillment within the expected service level. An operations manager asks: Why was Order-81772 delayed? Answering this question requires more than locating the order record. The ERP system and approval workflow hold the operational history. A process model explains why approval matters. An organizational directory identifies the responsible role, while an approval policy supplies the governing rule. These sources describe different aspects of the same situation and use different identifiers. The ERP log records when the order was created and when it was released to fulfillment. The workflow log records when discount approval was requested, assigned, and completed. The process model states that fulfillment requires a completed approval for orders whose discount exceeds a specified threshold. The organizational model assigns responsibility for the approval activity to the Sales Manager role, while the directory records the person holding that role during the relevant period. Finally, the approval policy and service-level definition provide documentary evidence for the responsibility assignment and the expected approval time. The order was created at 09:00. Discount approval was requested at 09:03 and assigned at 09:05. It was completed at 13:40, after which the order was released at 13:45. The approval target was 30 minutes. These records show what happened, but not why approval blocks fulfillment or who is responsible for it.

Business Graph representation The graph represents the order and the activities that act on it. It also contains the relevant organization and supporting systems. Representative entities are Order-81772, DiscountApproval, and OrderFulfillment. The organizational side contains Alice and SalesManager; WorkflowSystem represents the supporting application. Stable identifiers reconcile records that refer to the same business object. Structural knowledge is encoded as assertions. Alice HAS_ROLE SalesManager and SalesManager RESPONSIBLE_FOR DiscountApproval. The approval activity USES WorkflowSystem. In turn, OrderFulfillment REQUIRES DiscountApproval. Operational records are represented as events linked to the order and activity. Assertions retain their epistemic and temporal qualifications. They also retain their evidence links. Responsibility can therefore be traced to the approval policy, while approval timing can be traced to workflow events.

This representation separates relatively stable business structure from time-specific observations. It also avoids reducing the case to a single process diagram. The model retains organizational responsibility and technical use as different relations. Process dependencies remain distinct from event history and documentary evidence.

Reasoning and query execution In the case workflow, the natural-language question is grounded to the order entity and represented as a WHY analytical query. Execution against the persistent backend can be pinned to an immutable graph snapshot. This allows the same business state to be selected later. A complete case specific procedure would first retrieve events linked to the target. It would then trace upstream dependencies and distinguish observations from derived findings. For the supplied scenario data, the event sequence shows that discount approval consumed most of the elapsed time before fulfillment. Comparing the timestamps with the service target yields a substantial deviation at that stage. This duration and service-level calculation represents case-specific analytical logic beyond the current generic WHY procedure. The dependency assertion states that fulfillment requires completed approval. Relation-algebra rules can additionally derive participation from responsibility: because the Sales Manager is responsible for the approval activity, the role participates in the containing process. Assertions produced by the implemented reasoner are marked as derived and retain the identifiers of the source assertions and the rule used to obtain them. The representative explanation separates three epistemic levels. Observed facts report the event timestamps and approval duration. Derived findings connect the approval stage to the delayed release through the declared dependency. Finally, the explanation identifies missing knowledge. The available events do not show why the assigned task remained inactive for several hours. A user-action log could provide the missing detail. An incident record or explicit exception event could do the same. A responsible result should therefore not attribute the delay to negligence or system failure without further evidence.

Figure 1. Case 1: Delayed order.

Figure 1. Case 1: Delayed order.

Evidence-grounded interaction and output Before LLM rendering, the selected policy and service-level evidence must be attached to the ResultContract. The optional renderer then receives those references together with the symbolic claims. Its role is to explain the result to an operations manager, not to discover causes outside the graph. We constructed a validated contract from this scenario and submitted it to the Nemotron 3.5 Lightning model. The answer was:

Order-81772 was delayed because the discount approval interval exceeded the 30-minute SLA target, running from 09:03 to 13:40.

The answer cited the SLA and approval-window claims. It also cited their two evidence records, and all identifiers were valid. Nevertheless, it omitted the dependency between approval and fulfillment. The word because was therefore stronger than the cited claims alone supported. The answer also omitted the unresolved inactive period. This case shows that referential grounding does not by itself ensure complete or appropriately qualified wording. Ling 3.0 Flash Fin produced a more complete rendering of the same contract:

The order was delayed because discount approval ran from 09:03 to 13:40, exceeding the 30-minute target, and fulfillment requires completed discount approval.

This answer cited all required claims and both evidence records. It therefore passed the strict criteria for this case. It still did not communicate the missing cause of the inactive period. The accepted output is bound to the checksum of its source result. That result can in turn point to an ExecutionContract and graph snapshot. This separates model-generated wording from the symbolic findings it presents.

4.2. Case Study 2: Assessing the Impact of Payment-Service Failure

Scenario and input knowledge The second case concerns operational resilience. The retailer is planning maintenance of its external PaymentGateway, and a manager asks: What business operations will be affected if the Payment Gateway becomes unavailable? This question differs from the first case because no failure event has yet occurred. The task is to evaluate a hypothetical condition using structural dependencies and to expose both direct and indirect consequences. The application catalog and CMDB describe the technical services. Process and capability models connect those services to business operations. Organizational records identify the owning team and on-call role. Incident-response policy and technical documentation provide evidence for recovery procedures. The graph contains the payment gateway and the services that use it. It also contains the affected processes and business capabilities. A backup gateway or manual procedure is included only when a source supports it.

Business Graph representation The application and process dependencies are represented explicitly. The CheckoutService and RefundService use the PaymentGateway. OrderPlacement requires the checkout service. OrderToCash then requires order placement. Finally, OnlineSales depends on the order-to cash process. Customer support uses the refund service to execute customer refunds. The Payment Operations Team owns the gateway. The Payment On-Call role is responsible for restoring it. This model does not collapse different relations into a generic connection. A USES edge indicates technical use. A REQUIRES edge identifies a process dependency that can propagate impact. A RESPONSIBLE_FOR edge identifies an accountable actor without treating that actor as a technical component. The graph may also contain contextual or temporal qualifications. For example, a backup gateway may be valid only in one region or after a particular date. A complete impact analysis should therefore evaluate assertions against the context and time selected in the query rather than against an unqualified union of all known assertions. The current generic analytical procedure does not yet apply these qualifications.

Figure 2. Case 2: Payment failure.

Figure 2. Case 2: Payment failure.

Impact and single-point-of-failure analysis After the target has been grounded, the analytical request is represented as an IMPACT PaymentGateway query. Starting from the target, the implemented procedure traverses incoming dependency relations to the configured depth. For the scenario graph, it would first identify checkout and refund as directly affected services. It would then reach order placement and order-to-cash. Further traversal would reach online sales and customer-support refund operations. Each returned step records the relation and assertion identifier. Its traversal depth is recorded separately. This traversal is intentionally different from semantic materialization. A multi-hop REQUIRES or USES path is evidence of potential propagation, but it does not create a new direct assertion between its endpoints. Reachability-only relations remain paths, preventing the graph from turning an analytical route into an asserted business fact. The same snapshot can also be examined using a SPOF query. The current reference procedure can identify simple dependency-concentration and exclusive-responsibility candidates. A stronger technological single-point-of-failure conclusion would additionally require criticality and alternative-path analysis, which are not yet implemented by the generic procedure. Likewise, the absence of a recorded failover relation should be reported as missing information unless the completeness of the application catalog has itself been established; it must not be presented as proof that no failover mechanism exists.

Evidence-grounded interaction and output In the five-case Nemotron evaluation, the model received three expected impact claims for this scenario. Its complete answer was:

Checkout Service, Refund Service

Both named services were correct direct effects. The model omitted the indirect effect on Order Placement, giving required-claim recall of two thirds for this case. It also cited organizational evidence although it did not cite the associated ownership claim. The response was therefore grounded but incomplete, with one evidence-alignment error. Ling returned a broader answer:

Checkout Service, Refund Service, and Order Placement are affected. Payment Operations owns the Payment Gateway.

This answer covered all expected direct and indirect impact claims. It also added the ownership claim, which was true but not required by the question. Thus, Ling improved recall at the cost of precision in this case. An integrated case result should accompany each affected element with its full dependency path and supporting assertion identifiers. The current IMPACT procedure records each traversed step and its depth but does not yet reconstruct the complete path for every result. Preserving that path would allow a generated summary to be checked against the graph rather than accepted solely because it is linguistically plausible. The case illustrates prospective decision support through bounded multi-hop analysis. It also shows why direct impact should be separated from indirect impact and missing resilience knowledge.

4.3. Cross-Case Analysis

The two cases exercise complementary aspects of the approach. The delayed-order case is instance-oriented and event-intensive. It combines observations with process and responsibility knowledge to explain a past outcome. The payment case is structure-oriented and dependency intensive. It evaluates a possible future condition and identifies the scope of potential impact. The first case primarily uses WHY and bottleneck oriented operations; the second uses IMPACT and SPOF. In both cases, the Business Graph contributes more than document retrieval. Its typed relations give each connection an explicit meaning. Query semantics and bounded traversal make the analytical operation inspectable. Snapshot identity links the result to a defined business state. Retrieval still matters because policies and technical documents provide evidence. Their text is not silently converted into an executable fact. The LLM renderer can adapt the final presentation, but it receives the symbolic claims as its factual boundary. The rendering experiment also showed that this boundary does not ensure a complete answer. Coverage must be evaluated separately or encoded as an additional output requirement. The graph-aware retrieval experiment provides a small protocol-level comparison across these scenario themes. On the four held-out questions, lexical record-only retrieval achieved 55.6% Recall@5 and 0.451 nDCG@5. Record-only voyage-4 embeddings reached 66.7% and 0.852, respectively. Adding one-hop Business Graph assertions to the serialized units raised Recall@5 to 100% and nDCG@5 to 0.861. Applying rerank-2.5 preserved 100% Recall@5 and increased nDCG@5 to 0.896; Recall@3 increased from 77.8% to 100% relative to graph-aware embedding retrieval without reranking. This result is consistent with the role of typed local structure in both cases: the delayed-order question requires events together with a REQUIRES assertion, while the payment question requires direct USES assertions and an upstream dependency. However, all retrieval conditions returned context-related units in the top five for every missing-knowledge question. Ranking relevant context is therefore not equivalent to establishing an answer, and a separate abstention or sufficiency decision remains necessary. The scenarios also expose an important limitation. The quality of the result depends on the completeness and correctness of the graph. Business Graph reasoning can reveal that required knowledge is missing, but it cannot recover an unrecorded dependency or invent evidence for an undocumented procedure. This limitation is made visible through explicit missing-data statements rather than hidden by a fluent generated answer. A larger empirical evaluation should replace the authored synthetic graph with independent datasets and independently adjudicated expected answers. It should measure whether derived findings are correct and whether expected entities are covered. Separate measures should assessevidence links, provenance, and abstention when required information is absent. The present retrieval-protocol experiment supplies these measures only for one small synthetic fixture. A comparative experiment could use three conditions. The first would give an LLM only raw documents. The second would add conventional retrieval. The third would constrain the LLM with Business Graph findings and evidence. This experiment is outside the scope of the present cases, but it provides a direct path to systematic evaluation

5. Conclusions

The proposed approach demonstrates that heterogeneous organisational knowledge can be represented within a unified computational model without transferring authority for business facts to probabilistic components. The Business Graph combines a business-oriented meta-ontology with explicit relation semantics, temporal and epistemic qualifications, evidence, and derivation lineage. The reference implementation shows that these elements can support validation, symbolic reasoning, snapshot-bound execution, and evidence-grounded interaction through explicit contracts. The case studies illustrate how the same model can support retrospective explanation and prospective impact analysis while preserving the distinction between observed facts, derived findings, hypotheses, and missing knowledge.

The Business Graph builds on rather than replaces the approaches reviewed in Section II. Enterprise modelling and architecture frameworks provide established descriptions of organisational structure and behaviour, while RDF, OWL, and knowledge-graph reasoning provide formal constructs for relation semantics and inference. Neuro-symbolic systems such as KGLM similarly separate formal reasoning from language generation, and graph-enhanced RAG approaches demonstrate the value of structured context for retrieval. The contribution of the Business Graph is therefore not a new logical formalism or evidence of superiority over these approaches, but their integration into a business-specific, executable model in which symbolic execution, probabilistic retrieval, and language-based presentation retain distinct roles and epistemic boundaries.

The present results remain limited by the conceptual and prototype status of the work. The implemented language interface, reasoning profiles, planner, and analytical procedures cover only a restricted subset of the proposed architecture, and several operations do not yet apply complete temporal or contextual filtering. Scalability has not been evaluated, retrieval is not automatically integrated with execution, and result quality depends on the completeness of the graph and the correctness of its rules and evidence. The evaluations use small authored synthetic fixtures and single model runs, so they establish protocol behaviour rather than general effectiveness. Contract validation prevents unknown references but cannot guarantee complete or appropriately qualified generated explanations, and the system cannot recover dependencies or evidence that were never recorded.

Future work should strengthen temporal, provenance, and epistemic representation while developing governed methods for graph construction and rule maintenance. The current bg2vec experiment evaluates deterministic graph-aware text serialization with external embeddings and reranking; persistent indexed integration, learned structural graph representations, and larger independent evaluations remain open research directions. Treating the Business Graph as a dedicated LLM modality is likewise a longer-term direction rather than a current contribution. Overall, the study answers the research question by showing that an organisation can be represented as a typed and executable graph whose queries, derivations, and AI-facing results remain connected to explicit semantics and evidence. This provides a concrete foundation for auditable business reasoning, while its scalability and generalisability require further empirical validation.