Skip to content

Scenarios

A scenario is the definition of a potential "story" that could potentially happen. A scenario is completely detached from the structure of the knowledge graph (aka core brain).

A scenario is defined by its name and optional description, and actors. Actors are the "variable" elements of the scenarios. Two instances of the same scenario cannot have the exact same actors.

Actors

Every actor is defined by its name and an optional (but recommended) description, and the temporal aggregation function that will apply if multiple instances of the same scenario are discovered for a same entity.

Scenarios have an impact on the factors of entities that have an actor role in a possible scenario. If multiple occurrences of the same scenario affect the same entity, the aggregation function for this scenario can also been defined using a standard aggregation function (maximum, sum, or average).

To get familiar with the aggreagation functions, please look at the example below.

Parent scenarios

Parent scenarios are the way of defining abstract scenarios that could affect the same sets of actors with different probabilities, and that have the same meaning at a higher level.

For every parent scenario, you have to define the mapping between the actors of this scenario and the actors of the parent scenario.

Sub-scenarios

It is also possible that a scenario consists of the succession of multiple simpler scenarios. This is particularly true when you want to evaluate the plausibility of complex, very rare scenarios.

Like for parent scenarios, every sub-scenario must have all its actors mapped to actors of the complex scenario.

Let's take the example of a "kill chain" in cybersecurity. We could define a complex scenario called A hacker gets domain admin rights. This complex scenario could be composed of at least two sub-scenarios called A hacker obtains an access to the system, that could be the parent scenario of multiple ways a hacker could get an access to a system, and another sub-scenario called A standard user elevates his privileges to domain admin, that could also have multiple child scenarios.

CogTL will then try to link all the simpler possible scenarios, and if two possible instances match, automatically create a possible scenario of this complex type, affecting the matching actors, with a probability corresponding to the combination (product) of the probabilites of the sub-scenarios.

Example

Let us define a scenario called A person encounters a technical issue, that we want to apply on a graph containing entities of type Person using entities of type Application.

The scenario would have two actors: person, and failing application.

We also define a factor Operational risk that will be attached to both actors.

Let us also define an assertion that for every couple of subjects Person connected to an Application by a relation uses, stores a possible scenario A person encounters a technical issue, with an impact on the factor Operational risk having the value 1.

For the sake of simplicity, let us assume that every application is necessary for every person in order to be able to work. Let us also assume that every application has the same probability to be failing, and define that it may happen arbitrarily 1 hour per year.

In such a situation, we should define the aggregation functions as follows:

  • On the actor person:
  • The temporal aggregation should be defined to Sum, as if multiple instances of this scenario may apply to the same person (meaning that the same person uses multiple different applications that have the potential to fail in an independent manner), it may increase the number of hours per year the user is prevented to work.
  • The factor aggregation on the factor Operational risk must be defined to Maximum, as at a given time, the operational impact on the company employing this person won't be different if multiple applications are failing, or if only one is failing: he cannot do his work.
  • On the actor failing application:
  • The temporal aggregation should be defined to Maximum, as if multiple instances of this scenario may apply to the same application (meaning that multiple persons are using this application), it would not increase the temporal probability of this application to fail.
  • The factor aggregation on the factor Operational risk must be defined to Sum, as if multiple users are using this failing application and it fails, all those persons will be affected, and the global operational risk is getting higher for the company.

Finally, CogTL will then calculate the factor values for every entity by multiplying the temporal probability by the impact on factor calculated on every entity. Which means that the final value will be high for:

  • Entities of type Application that are used by numerous users (with a temporal probability that still sticks to 1 hour every year).
  • Entities of type Person that use numerous applications (with a temporal probability that is equal to the probabilistic sum of every failing application).

As a side comment, please note that the "sum" of temporal probabilities is not a simple sum (e.g. 2 hours over a year). It is calculated as the probabilistic sum of two independent scenarios, i.e. P(AUB) = P(A) + P(B) - P(AnB), which means that the probability will be slightly lower than 2 hours over a year.