---
title: Capability Interaction Graph (CIG)
url: https://www.emergentmind.com/topics/capability-interaction-graph-cig
type: topic
---

# Capability Interaction Graph (CIG)

Searching arXiv for the specified paper to ground the article.
{"query":"id:2606.20779 OR title:\"Ontology-Grounded Capability Interaction Graphs: From Knowledge Graphs to Fault Trees\"","max_results":5,"sort_by":"submittedDate","sort_order":"descending"}
Capability Interaction Graph (CIG) is a formally grounded representation of a cyber-physical system’s functional dependency structure and its potential failure-propagation pathways. In the formulation introduced in "Ontology-Grounded Capability Interaction Graphs: From Knowledge Graphs to Fault Trees" [2606.20779], CIGs are ontology-driven, grounded in the Unified Foundational Ontology (UFO), and naturally represented as knowledge graphs. They are intended to support reliability modeling in multidisciplinary Cyber-Physical Systems (CPSs), where failures, their cascading effects, and subsystem interactions are often documented incompletely or remain tacit in expert practice. The framework positions CIGs as an intermediate model between architectural knowledge graphs and synthesized Fault Trees, with the explicit goal of enabling automated, semantically grounded reliability analysis.

## 1. Formal definition and representational scope

A CIG is defined over a finite set of resource types $R$, such as “Ink” or “Electricity.” A passenger CIG is a particular instance $\gamma$ of the type

$$
G := C \times F \times F_x \times Comp \times Chan \times OIf \times IIf \times Exp
$$

with a factual CIG written as

$$
\gamma = (C, F, F_x, Comp, Chan, OIf, IIf, Exp) : G
$$

In this formulation, $C \subseteq CapabilityId \times \wp(R) \times \wp(R)$ contains capabilities, understood as dispositions that inhere in exactly one object; each tuple $(c, R_{in}, R_{out})$ states that capability $c$, when manifested, consumes each $r \in R_{in}$ and produces each $r \in R_{out}$. $F = FunctionId$ denotes functions, treated as atomic events that manifest exactly one capability. There is a partial bijection $\rho : CapabilityId \to FunctionId$ such that $\rho(c) = f \Leftrightarrow f$ manifests capability $c$ [2606.20779].

Faults are given by $F_x \subseteq FaultId \times CapabilityId$ and are characterized as modes preventing the manifestation of certain capabilities. The component set is defined as $Comp \subseteq ComponentId \times \wp(CapabilityId) \times \wp(FunctionId) \times \wp(FaultId)$, where a component $\alpha$ carries exactly the capabilities $C^\alpha$, may manifest exactly the functions $F^\alpha$, and bear exactly the faults $F_x^\alpha$. Channels are represented as $Chan \subseteq ChannelId \times \wp(R) \times \wp(CapabilityId) \times \wp(FunctionId) \times \wp(FaultId)$ and mediate transport of each accommodated resource. For each channel $c$ and resource $r \in R$, $cons(c,r)$ and $prod(c,r)$ are the unique consumption and production capabilities of $c$ for $r$.

The interface structure is split into output interfaces and input interfaces. Output interfaces are defined by $OIf \subseteq ComponentId \times ChannelId \times R$, linking component producers to channels; each $o = (\alpha, c, r)$ aggregates the component-capability $\alpha \to c$ of $r$ and the channel’s $cons(c,r)$. Input interfaces are defined by $IIf \subseteq ChannelId \times ComponentId \times R$, linking channels as providers to component consumers analogously. Finally, $Exp \subseteq CapabilityId$ denotes expectations, where an expectation $e \in Exp$ states that capability $e$ is required to be manifested in the current situation.

This organization makes the CIG a dependency model centered on capabilities rather than only on components or signals. A plausible implication is that the framework emphasizes failure semantics at the level of functional provision and resource dependency, which differs from purely structural network descriptions.

## 2. Ontological grounding in UFO

All CIG elements are grounded in UFO. Components and channels are UFO-endurants, that is, objects. Capabilities and faults are intrinsic moments, specifically dispositions inhering in exactly one bearer $\alpha$. Functions, fault activations, and errors are UFO-perdurants, that is, events manifesting dispositions via $manifests(e,d)$. Interfaces are relators existentially dependent on the participating capabilities [2606.20779].

The ontology also makes explicit the distinction between fault creation, fault activation, and error propagation. Fault creation is a spontaneous event; fault activation is a triggered error; error propagation is a causal sequence. This is expressed using UFO-B’s notions of situations, triggers, and brings-about, together with the predicates

$$
inheresIn(d,o)
$$

$$
manifests(e,d)
$$

$$
triggers(s,e),\ brings\text{-}about(e,s')
$$

$$
directly\text{-}causes(e,e'),\ causes(e,e')
$$

A fault creation over faults $F$ in object $o$ is defined as

$$
s \; \text{—⟳₊}F\text{→} \; s' \quad \text{iff} \quad \forall x \in F.\ x \notin Faults(s) \land x \in Faults(s')
$$

An error for expectation $e \in Exp$ is defined as

$$
\hat{s} \; \text{—⟳⟨}e\text{⟩→} \; s' \quad \text{iff} \quad \hat{s}\ \text{earliest with}\ \neg meets(\hat{s},e)\ \text{and}\ (e \notin Exp(s') \lor meets(s',e))
$$

The significance of this grounding lies in semantic disambiguation. The paper states that UFO grounding disambiguates fault creation, activation, error, and the distinctions among event, situation, and state. This suggests that CIGs are designed not merely as graph encodings of architecture but as semantically typed artifacts intended to preserve explanatory distinctions that are often collapsed in informal reliability models.

## 3. Construction from CPS architecture and knowledge graphs

CIG construction proceeds from a Knowledge Graph that instantiates a lightweight ontology described as gUFO + CIG schema. The extraction is performed with SPARQL queries over the KG. The paper specifies that the query retrieves all components `?α rdf:type :Component`, all capabilities `?f :inheresIn ?α`, resource types `?r rdf:type :ResourceType`, all channels `?c :accommodates ?r`, and all input/output interfaces linking `?α`, `?c` for resource `?r` [2606.20779].

A representative SPARQL fragment is given as:

```sparql
SELECT ?α ?f ?c ?h ?k ?r WHERE {
  ?α a :Component .
  ?f a :Capability; :inheresIn ?α; :consumes ?r .
  ?h a :Capability; :inheresIn ?c; :consumes ?r .
  ?k a :Capability; :inheresIn ?c; :produces ?r .
  ?c a :Channel; :accommodates ?r .
  ?i a :InputInterface; :channel ?c; :component ?α; :interfaceCapability ?h .
  ?o a :OutputInterface; :channel ?c; :component ?α; :interfaceCapability ?k .
}
```

The result set $\Omega$ is transformed into an initial CIG $\gamma_0$ by a mapping $T(\Omega)$. According to the specification, this mapping collects all capability tuples, function-manifestation, component/capability/fault sets, channel definitions, interface definitions, and an empty initial $Exp_0$.

The KG representation itself uses gUFO, a lightweight OWL profile of UFO. The classes include `Component`, `Channel`, `Capability`, `Fault`, `Function`, `ResourceType`, `InputInterface`, `OutputInterface`, and `Expectation`. The object properties include `gufo:inheresIn`, `gufo:manifests`, `:consumes`, `:produces`, `:accommodates`, `:providedBy`, and `:provides`. Example ABox facts include `(PSU, rdf:type, Component)`, `(fElec, rdf:type, Capability)`, `(fElec, gufo:inheresIn, PSU)`, and `(fElec, :consumes, Electricity)`.

Graph-based reasoning via standard OWL/RDFS entailments and SPARQL populates the CIG elements. Situations and events are not represented in the KG; the KG encodes only the static architecture $\gamma_0$. This restriction is methodologically important: the architectural model is static, while failure semantics are imposed through the CIG-to-Fault-Tree transformation and the associated interpretation of errors and fault activations.

## 4. Fault Tree synthesis from CIGs

Given an initial CIG $\gamma_0$, the framework synthesizes a static Fault Tree

$$
FT = (BE, G, T, I)
$$

targeting a top-level capability $f^* \in Exp_0$. Here, $BE$ is the set of Basic Events, each corresponding to fault activation of one capability; $G$ is the set of intermediate gates; $T(g) \in \{AND, OR\}$ is the type of each gate; and $I(g) \subseteq (BE \cup G)$ gives the children of each gate [2606.20779].

The transformation is specified procedurally:

```text
function Transform(γ,f*):
  create FT with empty BE,G,I,T
  buildOr(P={}, node=f*, parentGate=nil)
  return FT

procedure buildOr(P,node,parentGate):
  if node ⚑ P:
    # already expanded ⇒ this basic event is repeated
    addBasicEvent(node,parentGate)
    return
  P ← P ∪ {node}
  orGate ← newGate(OR)
  attach(orGate,parentGate)
  addBasicEvent(node,orGate)         # fault activation
  for each r in prerequisites(node): # functional‐dependency case
    andGate ← newGate(AND)
    attach(andGate,orGate)
    for each k in ChannelOutputs(node,r):
      cor ← newGate(OR); attach(cor,andGate)
      addBasicEvent(k,cor)
      h ← ChannelInputOf(k,r)
      hor ← newGate(OR); attach(hor,cor)
      addBasicEvent(h,hor)
      for each g in ComponentProviders(h,r):
        gor ← newGate(OR); attach(gor,hor)
        addBasicEvent(g,gor)
        buildOr(P,g,gor)
```

The recursion builds, for each capability node, one OR gate expressing “fault-activation or loss-of-all-resources,” one basic event for its own fault activation, and, for each prerequisite resource $r$, one AND gate that requires an error in every minimal provider of $r$. The provider chain is described as component-output OR → channel depletion OR → component provider OR → recurse.

The paper further states a failure-semantics preservation result. For each Fault Tree, an evaluation $\pi_{FT}(S,e) \in \{0,1\}$ gives whether event $e$ occurs when a set $S \subseteq BE$ has failed. By induction, for any CIG situation $\gamma_n \geq \gamma_0$ and top-level capability $f^*$,

$$
[\![f^*]\!]^{\gamma_n}_{\gamma_0} \Leftrightarrow \pi_{FT}(S,f^*)
$$

where $[\![f]\!]$ is the CIG’s structure function, meaning that an error is active across $\gamma_0 \ldots \gamma_n$, and $S$ is the set of basic events corresponding to the capabilities erroneous in $\gamma_n$. Within the confines of the paper, this establishes that the synthesized Fault Tree preserves the relevant failure semantics of the CIG.

## 5. Running example: print-head subsystem

The running example is a print-head subsystem. In the architecture $\gamma_0$, `PSD` provides `Electricity`, `InkReservoir` provides `Ink`, and both feed `PrintHead` via the channels `wire` and `tube`. The CIG capabilities in $\gamma_0$ are

$$
C = \{ProvideElec, ProvideInk, DepositInk, SelfClean\}
$$

with expectations

$$
Exp_0 = \{DepositInk\}
$$

and initial faults

$$
F_{x0} = \varnothing
$$

The constructed CIG diagram is given as:

```text
[PSU: ProvideElec]—wire—[PrintHead: DepositInk]—tube—[InkRes: ProvideInk]
```

For the target `DepositInk`, the synthesized Fault Tree contains an OR gate for `DepositInk`, a basic event `FaultActivation(DepositInk)`, and an AND gate for “loseElec” AND “loseInk.” The electrical path is represented as `FaultActivation(wire-elec) OR FaultActivation(PSU-elec)`, and the ink path as `FaultActivation(tube-ink) OR FaultActivation(InkRes-ink)` [2606.20779].

The qualitative minimal cut sets are stated explicitly as

$$
\{PSU\text{-}elec,\ InkRes\text{-}ink\},\ \{PSU\text{-}elec,\ tube\text{-}ink\},\ \{wire\text{-}elec,\ InkRes\text{-}ink\},\ \{wire\text{-}elec,\ tube\text{-}ink\}
$$

plus the single cut set

$$
\{DepositInk\}
$$

This example illustrates the stated transformation principle: direct failure of the target capability yields a single basic-event cut set, whereas loss of required resources is captured compositionally through the conjunction of independently disrupted prerequisite paths.

## 6. Analytical role, benefits, and multidisciplinary significance

The framework is presented as supporting early-stage reliability modeling because CIGs require only functional architecture and resource-flow information, not detailed error models [2606.20779]. It also provides ontological clarity through UFO grounding, traceability because each Fault Tree element maps back to components, capabilities, and interfaces in the KG and thus the system model, and automation because SPARQL queries together with the CIG-to-FT algorithm yield Fault Trees without manual gate placement.

The generated Fault Trees are intended to support both qualitative and quantitative Fault Tree Analysis. The paper states that once a Fault Tree is generated, standard cut-set and probability analysis apply. Interoperability is also emphasized: CIGs absorb heterogeneous modeling languages, including SysML, AADL, and custom KGs, under a common UFO-based ontology. In addition, multidisciplinary collaboration is explicitly identified as a benefit, because systems engineers, software engineers, and reliability experts share a unified semantic layer.

These claims position CIGs as a lightweight but formally precise intermediate model between architectural knowledge graphs and synthesized Fault Trees. A plausible implication is that the method addresses a recurrent integration problem in CPS engineering: architectural models, semantic models, and reliability artifacts are often developed in different notations and by different expert groups. The CIG formalism, as described, is intended to mediate among these layers without requiring detailed stochastic failure models at the initial stage.

## 7. Conceptual boundaries and common points of confusion

Several boundaries of the framework are explicit in the formulation. First, the KG encodes only the static architecture $\gamma_0$; situations and events are not represented in the KG. Reliability semantics therefore do not arise solely from RDF/OWL encoding, but from the combination of ontological grounding, graph extraction, and Fault Tree synthesis. Second, the synthesized artifact is a static Fault Tree. The paper does not present the CIG itself as a substitute for Fault Tree Analysis; rather, CIGs provide the semantically grounded dependency model from which Fault Trees are generated.

A further point concerns the role of expectations. The set $Exp$ does not merely annotate desired functions informally; it denotes that a capability is required to be manifested in the current situation. This is central to the definition of error, which is framed in terms of whether an expectation is met. Another possible misunderstanding is to treat channels as passive connections only. In the CIG formalization, channels have their own accommodated resources and associated consumption and production capabilities, and channel-level failures appear explicitly in the synthesized Fault Tree.

Finally, the framework is not described as eliminating the need for domain expertise. Rather, it reduces complexity by leveraging CIGs and knowledge graphs, while providing a common semantic representation across engineering domains and supporting automated generation of reliability models. This suggests a division of labor in which expert architectural knowledge is formalized once in a KG and then reused for downstream reliability analysis through ontology-grounded transformation.

Source: https://www.emergentmind.com/topics/capability-interaction-graph-cig