Before we will move one, it is necessary to define some terms for better understanding of context.
The first and basic concept that should be introduced is \textbf{Rule} (marked with $R_i$). Rule in diKTat is the logic described in a special class named with \texttt{"Rule"} suffix, which checks whether code meets a certain paragraph of code-style. The set - is a well-defined collection of distinct objects, considered as an object in its own right. So we can define a \textbf{Ruleset} - a set of such code analysis Rules. We will mark any of such set of Rules with $R$.

\textbf{Inspection} is the part of any Rule. It is an algorithm that can detect (marked with $W_i$) or fix (marked with $F_i$) invalid code. It is very important to understand that $Rule \neq Inspection (Inspection \subset Rule)$. We will use $I_i$ notation to mark each separate inspection. So it is obvious that: $I_i = W_i \cup F_i$, where $i \in \mathbb {N}$. Using the same logic we can say that $R = \bigcup\limits_{i} R_i$ where $R_i = \bigcup\limits_{j} I_j$.

\textbf{Abstract syntax tree (AST)} is a tree representation of the abstract syntactic structure of source code written in a programming language (Kotlin in our case). Each node of the tree denotes a construct occurring in the source code. \textbf{CI/CD} - continuous integration (CI) and continuous delivery (CD) is a methodology that allows application development teams to make changes to code more frequently and reliably \cite{ref:cicd}. \textbf{KDoc} - is the language used to document Kotlin code (the equivalent of Java's JavaDoc).