Within the TrustyAI initiative, the trusty service is the main service that aims to collect tracing events emitted by one or more kogito-runtime application and to provide explainability on top of the decisions that have been by the application.
The architecture looks like the following:
In particular we have:
- A kogito-runtime application with the
tracing
addon activated. - A kafka broker and an infinispan instance.
- The trusty service (this module).
- The explainability service
- The auditUI
Descriptions and instructions for every single component are provided in the next subsections.
The kogito-runtime application is a standard kogito application that has imported the tracing-addon
as dependency
<dependency>
<groupId>org.kie.kogito</groupId>
<artifactId>tracing</artifactId>
</dependency>
and that is using one or more DMN models. In addition to that, the application needs to know the address of the kafka broker. For example, if you are using Quarkus, you can set it with an enviroment variable
export KAFKA_BOOTSTRAP_SERVERS=localhost:9092
This is needed because every time a decision is evaluated for a dmn model, a trace event is generated and emitted. This event contains all the information needed to provide explainability and accountability on the decision that has been taken.
If you are new to kogito, we recommend to start with https://kogito.kie.org/get-started/ .
You will have to provide a kafka instance as well as an infinispan instance. At the end of this readme, there is a link that contains a full end to end example.
The Trusty service consumes tracing events generated by the kogito-runtime application. A tracing event is a bunch of data that contains the request that has been made to the kogito endpoint, the result, the outcomes of all the dmn nodes (decisions and BKM for example), and error messages if any. The responsability of this service is to store all the information about the decision and to interact with the explainability service to retrieve the analysis of the decision. The trusty service depends of course on kafka, but also on infinispan to persist the tracing information. Enviroment variables can be used to set the information needed to connect to kafka and infinispan, for example
export KAFKA_BOOTSTRAP_SERVERS=localhost:9092
export QUARKUS_INFINISPAN_CLIENT_HOSTS=localhost:11222
export QUARKUS_INFINISPAN_CLIENT_USERNAME=myuser
export QUARKUS_INFINISPAN_CLIENT_PASSWORD=mypassword
The Trusty service by default is configured so that if a connection exception occurs during the processing of a kafka event, the message is not acked and the application is set in an unhealthy status. It's responsability of the underlying orchestrator to redeploy the service until the infrastructural issue is fixed. If you are not using any orchestrator, we suggest you to set up the following ENV variable so to disable this behaviour. With the following variables
export KAFKA_APPLICATION_FAILURE_STRATEGY=ignore
the application discards all the events even if it would be possible to recover them in a second moment. This prevents the trusty service to stay in an unhealthy status waiting for redeployment.
In addition to that, if you would like to ignore the type of the exception and nack the message if any exception is raised, you can set the variable
export TRUSTY_MESSAGING_NACK_ON_ANY_EXCEPTION=true
The explainability service provides local and global explaination.
- The local explanation aims to find the most relevant features that contributed to take that particular decision. In order to do that, the explainability service interacts with the kogito-runtime application to re-execute the decision with perturbed features. At the moment, the communication between explainability service and the kogito application is performed via HTTP calls.
- The global explainability is still under development.
As a consequence, the dependencies of the explainability service are Kafka and the availability of the kogito application.
A sample end to end project is provided here.