tinythings · isbm · Oct 29, 2024 · Oct 29, 2024 · Oct 29, 2024 · Oct 29, 2024
diff --git a/docs/modeldescr/actions.rst b/docs/modeldescr/actions.rst
@@ -12,8 +12,8 @@ data to modules.
 
     The following rules are applied to an action:
 
-    - An action is a consumer of facts of an entity
-    - One action applies only to one fact, but it may statically refer facts from other entities
+    - An action is a consumer of claims of an entity
+    - One action applies only to one claim, but it may statically refer claims from other entities
 
 Synopsis
 --------
@@ -78,7 +78,7 @@ Below is the description of configuration sections:
     If actions processing the system in a serial fashion without knowing what it is even discovered, then how exactly
     the state is determined?
 
-    They are not. An entity anyway is checked through all defined states. If facts are matching for one particular state,
+    They are not. An entity anyway is checked through all defined states. If claims are matching for one particular state,
     it is concluded that the device is in this state. Another option is to pass an argument to a module of a state. So
     if a module is able to request a state, then it can match the return result accordingly.
 
@@ -150,25 +150,25 @@ Given there are entities, such as ``syslogd``, ``systemd`` etc, one can bind an
 
 .. warning::
 
-    The *minimal* data structure of a facts must be identical!
+    The *minimal* data structure of a claims must be identical!
 
-In this example of two entities that have additional facts and one action that is checking
+In this example of two entities that have additional claims and one action that is checking
 those processes. Module ``sys.proc`` receives a flag ``is-running`` which puts it to a
-process checking mode, accepting ``process`` parameter of a currently processed fact.
+process checking mode, accepting ``process`` parameter of a currently processed claim.
 In this case, ``sys.proc`` will accept ``/sbin/init`` and ``/usr/bin/syslogd`` file.
 
-The fact ``discspace`` from ``my-special`` fact will be omitted.
+The claim ``discspace`` from ``my-special`` claim will be omitted.
 
 .. code-block:: yaml
 
     entities:
       systemd:
-        facts:
-          my-fact:
+        claims:
+          my-claim:
             - default:
                 path: /sbin/init
       syslogd:
-        facts:
+        claims:
           my-special:
             - default:
                 path: /usr/bin/syslogd
@@ -198,7 +198,7 @@ to the Shell expression as such: ``$MY_VAR``.
     a clear arguments without complex interpolations.
 
     In some rare cases one might create a comma-separated string, if that is very necessary:
-    ``myfact: "claim(foo),claim(bar)"``, however this is very discouraged practice and it is strongly
+    ``myclaim: "claim(foo),claim(bar)"``, however this is very discouraged practice and it is strongly
     recommended to change the module so it accepts a list of values instead of a comma-separated string.
 
 Another example, showing static data references. Consider the following configuration:
@@ -209,7 +209,7 @@ Another example, showing static data references. Consider the following configur
     # An entity, describing a static configuration
       systemconf:
         descr: static system configuration
-        facts:
+        claims:
           default:
             - storage:
                 type: SSD
@@ -223,7 +223,7 @@ Another example, showing static data references. Consider the following configur
       syslogd-possible:
         # Description of the action that will be logged
         # The shorter, the better
-        description: Validate syslogd facts
+        description: Validate syslogd claims
 
         # Path to the module namespace.
         # Modules are located in $module_root and namespace
@@ -238,7 +238,7 @@ Another example, showing static data references. Consider the following configur
           $:
             args:
               # Variable $(foo.bar) always refers to a full path from the document root.
-              - free-disk: "static(entities.syslogd.facts.storage.free)"
-              - free-mem: "static(entities.systemconf.facts.mem.free)"
+              - free-disk: "static(entities.syslogd.claims.storage.free)"
+              - free-mem: "static(entities.systemconf.claims.mem.free)"
 
-In the example above, function ``static(....)`` can statically reach any defined value of a fact.
+In the example above, function ``static(....)`` can statically reach any defined value of a claim.
diff --git a/docs/modeldescr/constraints.rst b/docs/modeldescr/constraints.rst
@@ -6,13 +6,13 @@ Constraints
     This document explains how constraints work and what they are for.
 
 Constraints are declarative logic carriers. They provide clear rules what to *consume* within
-a specific fact.
+a specific claim.
 
 .. important::
 
     The following rules are applied to a constraint:
 
-    - It provides declarative logic for modules those are consuming a specific fact
+    - It provides declarative logic for modules those are consuming a specific claim
     - It operates on actions, using entities's data
 
 Synopsis
@@ -110,7 +110,7 @@ Example
     entities:
       # NOTE: An id of an entity, referred by a constraint below
       addresses:
-        facts:
+        claims:
           $:
             - wifi:
                 if: wlp0s20f3

diff --git a/docs/modeldescr/entities.rst b/docs/modeldescr/entities.rst
@@ -8,7 +8,7 @@ The element ``entitles`` is the basis of the model. It contains the entire inven
 of a system in a CMDB fashion.
 
 Each entity can be described in a specific manner, holding all the
-necessary attributes, facts, claims and other data that must be
+necessary attributes, claims and other data that must be
 understood by the corresponding consumers. Consumers are actions that
 call specific modules, and constraints that process them.
 
@@ -17,22 +17,22 @@ call specific modules, and constraints that process them.
    Entities the the following rules:
 
    - An entity is independent of the specific architecture of a system
-   - An entity may contain only self-applied facts, describing only that particular entity.
+   - An entity may contain only self-applied claims, describing only that particular entity.
    - A single entity exists on its own and is unaware of other entities.
    - A compound entity exists only when all its parts are active.
 
 Synopsis
 --------
 
-Entitles describe facts and relations within the architecture. These expectations should
+Entitles describe claims and relations within the architecture. These expectations should
 be aligned with constraints. Each entity has a **true** or **false** state. A "true" state is when
 all constraints and checks produce the expected result.
 
 
 Each entity is a map. A map starts with an "id" and then contains the necessary attributes.
 The current attributes of an "entity" are as follows:
 
-1. ``facts`` *(required)* contains all data to be consumed by any module, check, or constraint, which must be true in the end.
+1. ``claims`` *(required)* contains all data to be consumed by any module, check, or constraint, which must be true in the end.
 2. ``consists`` *(optional)* It is only for collection entities (e.g., a network) and contains a list of other single entities that together form such a collection. This determines the operational state of the entity **itself**.
 3. ``depends`` *(optional)* It is for defining which other entities are required for this entity to be functional.
 
@@ -50,7 +50,7 @@ Here is the full entity description:
      <entity-id>:
         inherits:
           - <entity-id>
-        facts:
+        claims:
           <state-id>:
             <label>:
               key: value
@@ -62,18 +62,18 @@ Here is the full entity description:
 
 ``inherits`` (optional)
 
-  List of inherited (copied) facts from other entities. Facts section will be just
+  List of inherited (copied) claims from other entities. Claims section will be just
   merged (overwritten) over the inherited ones with "last wins" rule.
 
   .. warning::
 
-    The big limitation of the inheritance is that the facts's keys must be unique.
+    The big limitation of the inheritance is that the claims's keys must be unique.
     Otherwise they will clash and overwrite each other. However, often this is desired
     behavior.
 
 ``state-id``
 
-  The *state-id* is an ID within a current fact and keeps properties that could match that state. For example, it can hold a data
+  The *state-id* is an ID within a current claim and keeps properties that could match that state. For example, it can hold a data
   for a router with two states: 2.4GHz with 5GHz Wifi and only 2.4GHz Wifi.
 
 ``<label>``
@@ -90,7 +90,7 @@ An example of a single entities:
 
   entities:
     journald:
-      facts:
+      claims:
         default:
           - label:
             path: /lib/systemd/systemd-journald
@@ -106,15 +106,15 @@ An example of a compound entity:
       - syslogd
       - systemd
 
-An entity can be also just a static configuration of something, keeping facts.
+An entity can be also just a static configuration of something, keeping claims.
 For example:
 
 .. code-block:: yaml
 
   entities:
     systemconf:
       descr: static system configuration
-      facts:
+      claims:
         default:
           - main:
               storage:
@@ -129,43 +129,43 @@ a collection of those entities, or even just a physical wire. With this in mind,
 but it is a compound one, where one can "zoom in" to see its smaller parts, which can also be compound
 entities representing some part of the network, and so on.
 
-Facts
+claims
 ^^^^^
 
-Each entity **must** contain some facts about it.
+Each entity **must** contain some claims about it.
 
-A section in key/value format contains a series of facts under the name ``facts``. Each *fact* consists of *claims*,
-and a fact can have one or more claims. Facts also have states. States are essentially the segregation of
-facts, by which constraints and actions select different parameters for the processing module.
+A section in key/value format contains a series of claims under the name ``claims``. Each *claim* consists of *claims*,
+and a claim can have one or more claims. Claims also have states. States are essentially the segregation of
+claims, by which constraints and actions select different parameters for the processing module.
 
 Syntax:
 
 .. code-block:: text
 
-   facts:
+   claims:
      <id>:
       <state>:
         key: value
 
-Each fact has a label, which allows it to be tagged so that any other process can refer to this
-particular fact directly or indirectly. The main use of labels is in declarative constraints.
+Each claim has a label, which allows it to be tagged so that any other process can refer to this
+particular claim directly or indirectly. The main use of labels is in declarative constraints.
 
-Here is an example of a fact that claims there is a TCP network with an open SSH port,
+Here is an example of a claim that claims there is a TCP network with an open SSH port,
 listening to the world:
 
 .. code-block:: yaml
 
-   facts:
+   claims:
 
-      # Fact ID or label. It is unique per
-      # facts set within the entity.
+      # Claim ID or label. It is unique per
+      # claims set within the entity.
       # The label isn't addressed and skipped.
       tcp-network:
 
          # State ID by which action may refer it
          default-state:
 
-            # Fact label
+            # Claim label
             label:
 
               # Here are whatever key/value data, understandable by a
@@ -174,21 +174,21 @@ listening to the world:
               port: 0.0.0.0:22
               listen: 0.0.0.0:*
 
-A fact's claims are just arbitrary key/value pairs that can later be referred to by a
+A claim's claims are just arbitrary key/value pairs that can later be referred to by a
 corresponding consumer, such as a logic flow, an action, a plugin, etc.
 
-Facts can be addressed by built-in functions directly or indirectly:
+Claims can be addressed by built-in functions directly or indirectly:
 
 .. code-block:: yaml
 
    # Directly
-   foo: static(entitles.ssh-sockets.facts.port)
+   foo: static(entitles.ssh-sockets.claims.port)
 
-   # Indirectly, within the context of a current fact
-   # this returns the whole fact structure by its static ID
-   bar: fact(tcp-network)
+   # Indirectly, within the context of a current claim
+   # this returns the whole claim structure by its static ID
+   bar: claim(tcp-network)
 
-   # Claim returns a specific value of a claim within a current fact
+   # Claim returns a specific value of a claim within a current claim
    baz: claim(port)
 
-For more details about fact functions, please refer to the corresponding section.
+For more details about claim functions, please refer to the corresponding section.
diff --git a/docs/modeldescr/functions.rst b/docs/modeldescr/functions.rst
@@ -17,7 +17,7 @@ they only serve to properly link its navigation.
 
 List of currently supported functions:
 
-``fact(value | @)``
+``fact(value)``
 
   Function ``fact`` can accept the following parameters:
 
@@ -35,7 +35,7 @@ action consumer.
 
   The function returns a defined value of that claim.
 
-``static()``
+``static(value)``
 
   Function ``static`` accepts a type ``String`` with the whole absolute path with the ID of the claim.
 

diff --git a/docs/modeldescr/relations.rst b/docs/modeldescr/relations.rst
@@ -12,7 +12,7 @@ Synopsis
     The following rules are applied to a relation:
 
     - It defines edge relation between two or more entities within the specific system
-    - It is only a transport between the facts of an entity
+    - It is only a transport between the claims of an entity
 
 Relations form a dependency graph, very similar to a typical package manager in a regular Linux
 distribution, such as RPM or Dpkg. However, the main difference between a map of package

diff --git a/examples/models/inherited/model.cfg b/examples/models/inherited/model.cfg
@@ -15,4 +15,4 @@ config:
   modules: target/debug
 
 #inherits: ../router
-inherits: /home/bo/work/sysinspect/examples/models/router
+inherits: /home/bo/work/sysinspect/examples/models/router
diff --git a/examples/models/router/constraints/network-validation.cfg b/examples/models/router/constraints/network-validation.cfg
@@ -17,7 +17,7 @@ constraints:
     all:
       # State (applies to "entities" clause)
       interfaces:
-        # compare data with facts
+        # compare factual data with the entity claims
         - fact: if-up.virbr1.mac
           equals: "claim(virtual.mac)"
 

diff --git a/examples/models/router/entities/ports.cfg b/examples/models/router/entities/ports.cfg
@@ -11,7 +11,7 @@ entities:
 
   # Single entities
   ssh-sockets:
-    facts:
+    claims:
       $:
         - default:
             port: tcp,0.0.0.0:22,0.0.0.0:*
@@ -23,21 +23,21 @@ entities:
       - ssh-sockets
 
   postgres-sockets:
-    facts:
+    claims:
       $:
         - default:
             port: tcp,0.0.0.0:5432,0.0.0.0:*
             port6: tcp,[::]:5432,[::]:*
 
   routes:
-    facts:
+    claims:
       $:
         - default:
             route_a: 192.168.2.0/24
             route_b: 192.168.122.0/24
 
   interfaces:
-    facts:
+    claims:
       $:
         - default:
             lo: lo
@@ -46,7 +46,7 @@ entities:
             wifi: wlp0s20f3
 
   addresses:
-    facts:
+    claims:
       # Fact label. It is referred
       # by a constraint, if needed
       interfaces: