{"componentChunkName":"component---src-templates-default-template-tsx","path":"/guides/ke-user-guide-7/","result":{"data":{"asciidoc":{"id":"51841f8d-0b7e-5dff-b8ab-bf95f9c8fbe7","html":"
\n
Table of Contents
\n\n
\n
\n
\n
\n

This guide contains all the essential information for Knowledge Experts to teach HIRO™ how to automate knowledge described by SMEs most efficiently. It provides an overview of the HIRO™ world, direction on how to interact with HIRO™ for best results, and hints and tips on navigating the user interface.

\n
\n
\n
\n
\n

1. Introduction

\n
\n
\n

1.1 What Is HIRO™?

\n
\n

HIRO™ is an automation tool based on artificial intelligence, created by Arago. It can be used to automate both IT and business processes, enabling companies to utilise time and resources effectively.

\n
\n
\n

Knowledge is taught to HIRO™ in small pieces that contain the context in which they can be used. Then, when a Task is assigned to HIRO™, it will try to solve it by recombining all the knowledge it’s been previously-taught based on the Task context at each given point in time. This means that HIRO™ doesn’t learn in strict workflows like, for example, scripts. Instead, it will create a workflow in real time as it evaluates the Task context and, based on that, decides on the Steps to take, on the fly.

\n
\n
\n
\n\"Steps\n
\n
\n
\n
\n

1.2 How It Works

\n
\n

HIRO™ integrates into your environment in order to receive Tasks, the same way that you do! For example, these may be in the form of ITSM Tickets that are assigned to you, or submitting of forms, even e-mails. Integration is the first step because these Tasks will now all be \"delegated\" to HIRO™, and only when HIRO™ can’t solve it, it will go to the Subject Matter Expert (SME).

\n
\n
\n

A simple look at the process is as follows:

\n
\n
\n
    \n
  1. \n

    Ticket/Task is assigned to SME

    \n
    2. \n
  2. \n

    SME sees what HIRO™ has already done and determines which steps are missing from the solution

    \n
    3. \n
  3. \n

    SME solves the Ticket manually

    \n
    4. \n
  4. \n

    They locate the Ticket in HIRO™ Tasklist and press Start Teaching (This is the same when a Knowledge Expert wishes to teach HIRO™ directly)

    \n
    5. \n
  5. \n

    SME explains all the steps they took to HIRO™ Chatbot in natural human language and hands it over to Knowledge Experts

    \n
    6. \n
  6. \n

    A Knowledge Expert selects chat from their Tasklist view and converts it to code that HIRO™ understands7.

    \n
    7. \n
  7. \n

    Next time Task occurs, HIRO™ will use this knowledge to solve the Ticket autonomously

    \n
    8. \n
\n
\n
\n
\n\"SME\n
\n
\n
\n

Teaching HIRO™ is made simple with the help of a chatbot, which will guide the knowledge transfer by asking the SME questions regarding the Task solution. Once they complete and hand over the chat, it’s then available to all Knowledge Experts of the same team in the Tasklist app.

\n
\n
\n
\n\"HIRO\n
\n
\n
\n
\n

1.3 HIRO™ Modes and Workflow

\n
\n

HIRO™ is always working in the background, whether that be carrying out tasks, or learning how to automate new ones. This can be seen in the two modes HIRO™ works in:

\n
\n
\n
\n
The Automatic Execution Mode
\n
\n

HIRO™ solves tasks automatically by applying pre-existing knowledge.

\n
\n
The Agile Automation Mode
\n
\n

HIRO™ gets taught new knowledge to automate new tasks in an agile manner.

\n
\n
\n
\n
\n
\n\"map\n
\n
\n
\n
\n

1.2 The Workflow

\n
\n

Primarily, HIRO™ needs to understand the environment that it will automate in, including which tasks can occur there. These can both be extended as the scope grows, but to start off one should select an end to end process to automate, and define which tasks can occur there and their triggers.

\n
\n
\n

Triggers will be defined for each problem type, and an Automation Task will be created in HIRO™ every time a trigger is detected. In the Automatic Execution Mode, HIRO™ tries to solve each task by applying existing knowledge that it will have been taught previously.

\n
\n
\n

If the knowledge present is not sufficient for a specific task, HIRO™ will request to be taught new knowledge in the Agile Automation Mode, so that it can solve the task automatically the next time a similar trigger occurs.

\n
\n
\n
\n

1.3 User Roles

\n
\n

Automating with HIRO™ entails indirectly collaborating with various team members that will each use HIRO™ differently. For this purpose, Arago has created some User Roles to better separate responsibilities, processes for hand-over, and allow for the user interface and training content to be better catered to each role.

\n
\n
\n

1.3.1 HIRO™ Developer (Dev)

\n
\n

A HIRO™ Developer is responsible for creating and configuring the Action Handlers and Connectors planned in the Solution Design phase. They are familiar with the source and target systems, and the available HIRO™ APIs.

\n
\n
\n
\n

1.3.2 Subject Matter Expert (SME)

\n
\n

Experts who will teach HIRO™ how to automate processes they are knowledgeable on through a chat conversation where they answer some questions regarding said processes and tasks within them.

\n
\n
\n
\n

1.3.3 Knowledge Expert (KE)

\n
\n

This role will be given to users who understand how HIRO™ works, and can edit HIRO™'s automatically generated code to ensure it has translated content from an SME’s chat conversation correctly into KIs.

\n
\n
\n
\n

1.3.4 Admin

\n
\n

This role will be given to users who understand how HIRO™ works, permissions required for each user, and how to configure this using HIRO™ User Interface.

\n
\n
\n
\n
\n

1.4 Where Do I Fit In

\n
\n

Once a business process has been selected for automation, a Business Analyst will design the automated solution for the tasks within that business process and how they will be transferred into HIRO™. They will also define which external systems need to be connected to HIRO™ and what content is needed from each.

\n
\n
\n

These designs will be communicated to a Developer who will create the necessary Connectors and Action Handlers which will import data into HIRO™ for automation, and define how HIRO™ interacts with external systems.

\n
\n
\n
\n\"MotW\n
\n
\n
\n

Once the integration phase is complete, the Connectors will pick up any triggers that were defined to start an automation task, and push this information into HIRO™. HIRO™ then tries to solve said task with existing knowledge. If there is no knowledge applicable to the task at hand, the Connector should pick up on this, and inform the relevant Subject Matter Expert, who will complete the task manually.

\n
\n
\n

After manual resolution, this knowledge needs to be taught to HIRO™ for next time the same issue occurs. In this case, the automation task that was not able to be solved by HIRO™ appears in the user interface listed in the Tasklist app. This is where the SME would need to locate it and start teaching the HIRO™ Chatbot when they’re redirected to the Knowledge Acquisition Tool.

\n
\n
\n

Through the chat conversation, HIRO™ understands the steps and translates it into code that is used for automation. These steps are called Knowledge Items and for the process to be complete, a Knowledge Expert would need to peer review HIRO™'s translation and edit where needed, before deploying all the new knowledge so that HIRO™ can solve the problem itself next time it occurs.

\n
\n
\n
\n
\n
\n
\n
\n

2. Getting Started

\n
\n
\n

2.1 Knowledge Expert User Journey

\n
\n

This User Guide will look at the workflow only from a Knowledge Expert’s perspective.

\n
\n
\n

When HIRO™ can’t solve a Task, it means there’s missing knowledge. In this case, the Task will be handed over to a Subject Matter Expert (SME) and they will solve it manually. Lastly, the SME will teach HIRO™ how to solve Tasks like this in the future. The way they do that is by talking to a chatbot and answering questions to further define the knowledge being transferred.

\n
\n
\n

SMEs will teach HIRO™ what they did in so called Steps. Each Step will be translated by HIRO™ into Knowledge Items(KIs), which is what HIRO™ uses to carry out actions and automate solutions. These KIs are generated based on the SME’s input, and HIRO™'s understanding of it. Throughout the chat, HIRO™ does check in with the SME on whether it understood correctly or not, but sometimes it requires a little extra teaching from a Knowledge Expert.

\n
\n
\n
\n\"HIRO\n
\n
\n
\n

This means that a Knowledge Expert should know how to create KIs as they’re, in essence, peer reviewing HIRO™'s translation of natural language. By answering chatbot questions, the SME should have provided all the details necessary for a Step to be carried out, such as where it can be applied, under what conditions, and exactly how to carry out the action itself. This information can be mapped to the 3 parts of a Knowledge Item: On, When, Do.

\n
\n
\n
\n\"KE\n
\n
\n
\n

It’s the Knowledge Expert’s job to verify that HIRO™'s automatically generated code, does what the SME has described in the chat. Once this is done for each Step, the Knowledge Expert can request reviews from their colleagues to confirm the correctness of the new KIs. Then, they can be deployed into HIRO™, and the next time this Task needs to be carried out, HIRO™ can take care of it automatically.

\n
\n
\n
\n

2.2 Peer Review

\n
\n

2.2.1. Teaching Session Owner

\n
\n

Once a Teaching Session is complete a Knowledge Expert can request a peer review from another colleague as a way of confirming their conversion, that all details are included, and that best practice is followed. Reviewers can be added by clicking on the icon at the top right of the screen in KAT, and typing in the names of the colleagues who will review and press OK.

\n
\n
\n
\n\"SME\n
\n
\n
\n

Then, the Reviewer is notified, and their comments will be visible in the screen on the right, and the Teaching Session owner can choose to reply to the reviewer comments, make the suggested changes and resolve the comments, filter, sort,edit, delete etc.

\n
\n
\n
\n\"KE\n
\n
\n
\n

When a user replies to a comment, they have the option of tagging someone by using the \"@\" symbol and then their name. This will show up to the person who was tagged as a notification and a comment pending reply. When the owner of a session changes something that a comment by the reviewer is referring to, that comment is then marked as \"outdated\" and can be filtered out by clicking the icon at the top right, and unchecking the box. Here one can also sort the comments in the order they prefer.

\n
\n
\n
\n\"KE\n
\n
\n
\n
\n

2.2.2 Reviewer

\n
\n

When a Teaching Session has been assigned to a Knowledge Expert to review, they will receive a notification by HIRO™, and it will appear on their HIRO™ Dashboard. First the number will change at the \"Tasks to be Reviewed\" counter, and the Teaching Session will also be available at the top of their Task List. Once they click to start, they’re taken to KAT, in \"Review Mode\". This can be seen at the top right, next to the Teaching Session name, there will be a title \"Review Mode\", and also the colour scheme is different to that of SME view and Knowledge Expert view.

\n
\n
\n
\n\"KE\n
\n
\n
\n

This KAT also has a comments pane on the right hand side of the screen. Here, a reviewer can add general comments about the Teaching Session. They can also add comments by clicking on the speech bubble icon wherever available (please see list below) if they wish to be more specific about their review point.

\n
\n
\n

A Reviewer can comment on:

\n
\n
\n
    \n
  • \n

    The Teaching Session as a whole

    \n
    • \n
  • \n

    A specific Step

    \n
    • \n
  • \n

    A specific KI

    \n
    • \n
  • \n

    Specific lines of KI code

    \n
    • \n
\n
\n
\n
\n\"KE\n
\n
\n
\n

When there’s multiple reviewers, one can distinguish who they’re referring to by tagging someone in a comment. This can be done simply using the \"@\" symbol and then their name. This will show up to the person who was tagged as a notification and a comment pending reply.

\n
\n
\n

There are two sides to reviewing a Teaching Session. The first is confirming that the expert knowledge that is being taught to HIRO™ is converted correctly and is complete. The second is, ensuring that best practice is followed everywhere. This can be done with the help of checklists and best practice which can be gained through training and experience.

\n
\n
\n

When the owner of a session changes something that a comment by the reviewer is referring to, that comment is then marked as \"outdated\" and can be filtered out by clicking the icon at the top right, and unchecking the box. Here one can also sort the comments in the order they prefer.

\n
\n
\n
\n
\n
\n
\n

3. HIRO™ Tools for Knowledge Experts

\n
\n
\n

3.1 HIRO™ Desktop

\n
\n

The user interface for HIRO™ is called HIRO™ Dashboard and it contains information regarding the relevant HIRO™ instance such as the Tasks that are still open and need teaching or converting and Tasks that the user has left incomplete. On the top right it shows the statistics about the instance such as the automation rate, and the number of tasks that the user has automated, along with the number of Knowledge Items created. In the view on the bottom right a user can have a closer look at their knowledge Items filtered by mode - validation, undeployed, or live.

\n
\n
\n
\n\"Dashboard\"\n
\n
\n
\n

From here we also get access to different apps which allow a user to interact with HIRO™ and automate their tasks. There are 3 types of user roles one can have in Desktop, based on how they are expected to teach the tool:

\n
\n
\n
    \n
  • \n

    SMEs: who will teach HIRO™ how to automate their tasks using a chatbot

    \n
    • \n
  • \n

    Knowledge Expert: who will peer review HIRO™ automatically generated code, which is based on SME chat conversations

    \n
    • \n
  • \n

    Admin: who will configure HIRO™ instances to match all member requirements, permissions and password resets.

    \n
    • \n
\n
\n
\n

so it’s best to check that the right permissions have been granted before continuing. This can be done by clicking on the Profile icon on the top right, and seeing the User Role in the View Profile section, as shown below.

\n
\n
\n
\n

3.2 Tasklist

\n
\n

The Tasklist is a \"ToDo list\" for both SMEs and Knowledge Experts. Depending on the role, different filters and views are available. Start Teaching, Start Conversion, View Teaching take the user to the Knowledge Acquisition Tool where they can teach HIRO™ the steps needed to resolve an Automation Task.

\n
\n
\n
\n\"KE\n
\n
\n
\n

Knowledge Experts can find all sessions that have been handed over by SMEs in their own ToDo List. Knowledge Experts can also view conversion tasks created by their colleagues, and can start a teaching just like the SME would do. These teaching sessions, however, are considered handed over and start with the Structure View in KAT.

\n
\n
\n

Knowledge Expert Filters

\n
\n
\n

The filters in the Tasklist are shown all by default. The meaning for each can be found below.

\n
\n
\n
    \n
  • \n

    My Conversion Tasks:
    \nTeaching Session handed over by SMEs and that the Knowledge Expert themselves has already began converting.

    \n
    • \n
  • \n

    My Knowledge Tasks:
    \nTeaching Session that have not had any SME input, but the Knowledge Expert has taken over to teach HIRO™ the steps directly using KIs.

    \n
    • \n
  • \n

    My Teams Tasks:
    \nFiltered by users in the same organisation

    \n
    • \n
  • \n

    Archived Tasks:
    \nListing all archived tasks. (Archiving can be done using the 3 dots at the end of a row. Once archived they can be restored.)

    \n
    • \n
  • \n

    My Review Tasks:
    \nAll of the Tasks that the Knowledge Expert has requested peer review for.

    \n
    • \n
  • \n

    My New Review Tasks:
    \nAll of the Tasks that peers have assigned to the Knowledge Expert for review and they have note yet begun.

    \n
    • \n
  • \n

    New Conversion Tasks:
    \nTeaching Session handed over by SMEs

    \n
    • \n
  • \n

    New Knowledge Tasks:
    \nKnowledge Experts can also start a teaching session, here is where they’ll be able to see Teaching Sessions not started by an SME. In these Teaching Sessions, however, the Knowledge Expert is taken straight to structure / code view and the session is considered handed over.

    \n
    • \n
\n
\n
\n
\n

3.3 Knowledge Acquisition Tool (KAT)

\n
\n

The Knowledge Acquisition Tool is how knowledge gets inserted into HIRO™. The SME will do this by talking to a chatbot, so their KAT user interface looks different to that of an Knowledge Expert’s. The steps described by the SME during the chat conversation will be visible in KAT, in the Chat View where the Knowledge Expert has read rights.

\n
\n
\n
\n\"KE\n
\n
\n
\n

They can edit Steps in the Structure View, and it’s recommended that this is done in natural language. From there, the Knowledge Expert can choose to browse through existing knowledge in case the SME’s description matches that of a pre-existing KI and can be reused, or they can have HIRO™ automatically generate a new KI based on the chat conversation and this way grow their knowledge pool.

\n
\n
\n

This KI will appear in the Code View and the code itself can then be edited there. From here onwards, an Knowledge Expert must review Variables used, conditions, and the action a KI should carry out. Once this is complete, they can deploy the Knowledge Item, and HIRO™ will then be able to solve tasks like this automatically in the future.

\n
\n
\n
\n\"KE\n
\n
\n
\n

When generating a new KI, HIRO™ tries to map content from the natural language to existing variables, which is the \"vocabulary\" HIRO™ uses. The Knowledge Expert can edit this mapping or even create new ones. The logic behind the mapping suggestions is indicated on the screen in the form of coloured, straight and dotted underlining of the words the SME used to describe a step. Each indicator is explained below:

\n
\n
\n
\n\"KE\n
\n
\n
\n
    \n
  • \n

    Dotted line
    \nHIRO™ was able to match to an existing variable

    \n
    • \n
  • \n

    Red line
    \nHIRO™ wasn’t able to understand the user input

    \n
    • \n
  • \n

    Blue line
    \nHIRO™s suggestion was overwritten by the user or a new definition was added

    \n
    • \n
\n
\n
\n
\n

3.4 Knowledge Item Management Tool (KIM)

\n
\n

KIM allows users to browse all knowledge that has been created within their environment. A Knowledge Expert can filter for deployed (available to the engine), KIs in \"Validation mode\", undeployed, or incomplete KIs. From here, a user can select a KI and then go to the teaching session where that specific KI was created in KAT.

\n
\n
\n
\n\"KE\n
\n
\n
\n

The KI statuses are shown at the end of each line with corresponding icons.

\n
\n
\n
    \n
  • \n

    Green tick in a circle
    \nKI is available to the engine for use.

    \n
    • \n
  • \n

    Empty circle
    \nKI is not available to the engine for use. It is currently \"Undeployed\" so it will not be considered during automation.

    \n
    • \n
  • \n

    Chemistry icon (beaker)
    \nKI is in \"Validation Mode\". This means that the Knowledge Item will be considered during automation, but will not actually be applied. Instead, while a KI is in this mode, HIRO™ will log all the times that a Task matched the conditions of this KI, meaning (had it been Live) it would have been triggered when this Task occured. The details of the Validation statistics can be seen in more detail below.

    \n
    • \n
  • \n

    Red warning sign
    \nKI is syntaxtually incorrect.

    \n
    • \n
\n
\n
\n
\n\"KE\n
\n
\n
\n

By clicking on a KI in the list one can get a closer look at the KI, its statistics, they can edit it, or change the KIs state all from the view in the right hand side. The first view shows the KI code and offers 2 buttons. The \"View in Knowledge Acquisition Tool\" button will take the user to the Teaching Session in which this particular version of the KI was created. If this Teaching Session belongs to them, they can also edit the KI contents.

\n
\n
\n

The second button is a dropdown list with KI states. If the user owns the KI, they can choose to change its state by deploying to \"Live\", \"Validation Mode\", or undeploying altogether.

\n
\n
\n
\n\"KE\n
\n
\n
\n

Validation Mode is a state in which the KI is considered during automation but not applied. So, all Tasks that come in will also check if this particular KI can be applied. But it won’t actually get triggered, so the KI won’t run any actions while in this mode, it will simply log all the times that it could have run. This is useful for validating that the KI’s conditions are correct. The engine stores all the logs of when this KI would have run on a Task in the second tab of the right hand view - the \"Validation Statistics\" tab.

\n
\n
\n

In the \"Validation Statistics\" tab a user can see all the times that a Task occured which would have triggered the specific KI, had it been in \"Live\" mode. One can select the range they wish to see from the statistics (last 24 hours, 3 days, months etc.) and here is also where they are shown the Tasks and given the option to have a closer look at each Task for further inspection by opening it in \"Task Inspector\" (please see following section)

\n
\n
\n
\n\"KE\n
\n
\n
\n

Similarly, this view also offers a tab with \"Live Statistics\", which allows the user to see all of the Tasks that a KI has run on. They can also have a closer look at the Task history and view at which point exactly the KI was applied by opening the Task in Task Inspector. Lastly, the top right corner of a KI shows the KI versions. During the creation and editing of KIs, new versions are saved and are then accessible through KAT.

\n
\n
\n
\n\"KE\n
\n
\n
\n
\n

3.5 Task Inspector

\n
\n

The Task Inspector is where a Knowledge Expert can have a closer look at what Tasks have entered into HIRO™, their status, and which steps (KIs) they have triggered.

\n
\n
\n
\n\"KE\n
\n
\n
\n

After selecting a Task from the list, one can see which steps were taken and when, the findings of executed KIs, the changes that KIs made to the Task and, and where exactly in the environment those steps were taken.

\n
\n
\n
\n\"KE\n
\n
\n
\n

For each Task, the Task Timeline will show the full list of KIs applied, and the environment Nodes they were applied in. After clicking on a KI on that list, one can find more details in the following views:

\n
\n
\n
    \n
  • \n

    Task Content Display
    \nHere one can find the contents of the Task at the point in time where the KI was applied. The Task is in JSON format, and the highlighting allows us to see which Variables were deleted (red), or added (green). If a Variable was updated, the original value will appear in red - as it’s being deleted, and the new value will appear in a different line in green.

    \n
    • \n
  • \n

    Knowledge Item
    \nThe code view of the Knowledge Item that was selected from the Task Timeline, can be found in the Knowledge Item view. From here, one can have a closer look into the KI’s conditions to understand why it was triggered, and get a better view of what it was designed to do. From here, one can also have a closer look into the KI by going to the Knowledge Item Management tool (KIM).

    \n
    • \n
  • \n

    Current Node
    \nThe Task will originate on a certain environment Node, and knowledge will be applied to it there, if that knowledge is not sufficient to resolve said task, the Task will traverse the Graph moving from one Node to another until it finds the knowledge needed. Here one can look into the contents of the Node (in JSON format) that the Task was in at the selected point in time.

    \n
    • \n
  • \n

    Engine Log
    \nHere’s where one can see the output of HIRO™ implicit and explicit logging abilities. It’s useful when one is troubleshooting the outcome of a certain step, or simply see their log messages at that point in time.

    \n
    • \n
\n
\n
\n

(Task Content Display is available by default, the rest will need to be explicitly selected and de-selected from the dropdown list on the top right hand side.)

\n
\n
\n
\n\"KE\n
\n
\n
\n
\n

3.6 Graph Explorer

\n
\n

The Graph Explorer is a browser-base application desined to visualize and interact with data stored in a graph database. It allows users to explore entities(Nodes) and their relationships, view raw data and filter or query specific elements within the graph for better understanding and analysis.

\n
\n
\n

To start using the Graph Explorer, follow this link and use same credentials as for HIRO desktop.

\n
\n
\n

As a KI writer, understanding the implemented model for your automation cases is essential, as you’ll need to reference specific Nodes within your KIs (ON block).

\n
\n
\n

Exploring Nodes and Attributes

\n
\n
\n

For example, to automate a task on a Windows machine, we create a Node of the type \"Machine\" with the specific value \"Windows\" within the Graph. Now, let´s explore how to locate this Node.

\n
\n
\n
    \n
  • \n

    Selecting a Node Type

    \n
    \n
      \n
    1. \n

      Use the filter in Graph Explorer to select the type of Node you want to view. Example: Select MARS/Machine and click Apply.

      \n
      2. \n
    2. \n

      The selected Nodes and their properties will appear on the left-hand side.

      \n
      3. \n
    \n
    \n
    • \n
\n
\n
\n
\n\"SelectNode\"\n
\n
\n
\n
    \n
  • \n

    Node Properties (Attributes)
    \nNodes in the Graph are described by their properties (attributes), which fall into three categories:

    \n
    \n
      \n
    • \n

      Mandatory: Required attributes for the Node.
      \nExample: ogit/MARS/Machine/class.

      \n
      • \n
    • \n

      Optional: Attributes that add detail but aren’t required.
      \nExample: ogit/Automation/automationState.

      \n
      • \n
    • \n

      Free: Custom attributes that you can create to describe your entity if predefined attributes are insufficient.
      \nExample: /ExpenseReport (these do not start with ogit/, as they are customer-specific).

      \n
      • \n
    \n
    \n
    • \n
\n
\n
\n

Note: Attributes starting with \"ogit/_\" are automatically generated by HIRO™ when a Node is created.
\nExample: \"ogit/_modified-on\": \"Tue, 03 Sep 2024 09:33:11 GMT\" , \"ogit/_graphtype\" : \"vertex\"

\n
\n
\n
\n\"FreeAttribute\"\n
\n
\n
\n

Key concepts to learn

\n
\n
\n
    \n
  • \n

    Ontology: A formal description of knowledge within a domain, including its elements and relationships.

    \n
    • \n
  • \n

    Graph Database: Built on a subset of the Ontology, it contains attributes were values tailored to the specific automation case we want to work on.

    \n
    • \n
  • \n

    Graph Explorer: A powerful tool for visualizing and exploring data within the Graph Database.

    \n
    • \n
\n
\n
\n

For a full guide on how to query the graph, please check this link

\n
\n
\n

Graph Explorer App in HIRO Desktop

\n
\n
\n

A limited version of this tool is also accessible from the main HIRO dashboard. The Graph Explorer App allows you to explore Nodes within your HIRO instance.

\n
\n
\n
\n\"GraphExplorerApp\"\n
\n
\n
\n

Key Features:

\n
\n
\n
    \n
  • \n

    Finding Nodes:

    \n
    \n
      \n
    • \n

      Search for Nodes by type, scope, or organization, or use the search box to locate a specific Node.

      \n
      • \n
    \n
    \n
    • \n
  • \n

    Access Node Data:

    \n
    \n
      \n
    • \n

      Select a Node to access its data.

      \n
      • \n
    • \n

      Click \"Show OGIT Values\" on the right-hand side to view all metadata for the selected Node.

      \n
      • \n
    \n
    \n
    • \n
\n
\n
\n
\n\"MainPanel\"\n
\n
\n
\n
    \n
  • \n

    Graph View:

    \n
    \n
      \n
    • \n

      Select \"Graph View\" to visualize relationships between the selected Node and others in the graph.

      \n
      • \n
    \n
    \n
    • \n
\n
\n
\n
\n\"GraphView\"\n
\n
\n
\n
    \n
  • \n

    Customizing the Panel View:

    \n
    \n
      \n
    • \n

      Use the \"Save\" icon on the left-hand side module to customize and save the panel view.

      \n
      \n
      \n\"SaveIcon\"\n
      \n
      \n
      \n
      \n\"SavePanel\"\n
      \n
      \n
      • \n
    • \n

      These customizations are easily accessible via the three-dots icon on the left-hand side.

      \n
      • \n
    \n
    \n
    • \n
\n
\n
\n
\n\"AllPanels\"\n
\n
\n
\n

Why Use the Graph Explorer App?
\nThis app is invaluable for checking existing Nodes in your instance. For KI writers, it helps identify the variables you need to use in the ON block, ensuring your KIs are properly bounded and effective.

\n
\n
\n
\n
\n
\n

4. Translating Chat Conversations for KI Creation

\n
\n
\n

4.1 Knowledge Acquisition Through Chat

\n
\n

HIRO™ Chatbot aims to extract information from an SME regarding the steps to automate a certain task that it was not able to automate before. Which means that, ideally, each teaching session will begin with a Task that has been \"stopped\" and was not automatically resolvable by HIRO™.

\n
\n
\n

From each step HIRO™ is trying to learn where it can apply this knowledge (in the case that there’s environment data present which limits its application), and when it can be applied, meaning what information does the task definition need to contain for this step to be carried out. Lastly, HIRO™ tries to extract exactly what action is to be taken and how it can recreate that specific step when the time comes.

\n
\n
\n

The replies the SME will give to these questions, will show up for the Knowledge Expert in the Structure view of a Teaching Session in KAT. The replies will respective fill the on, when and do section of a KI. So, it’s important for the Knowledge Expert to have in mind that descriptions provided in the on block, will determine which of the Environmental Nodes this KI is applied to. Similarly, the answers for the when block, will determine what information from the Task is needed for this KI to trigger, and the do block will show what exactly needs to be done.

\n
\n
\n
\n\"On\n
\n
\n
\n
\n

4.2 HIRO™'s Vocabulary - Variables

\n
\n

While describing the steps, HIRO™ tries to map natural language to vocabulary it recognises, which consists of Variables. This mapping can be seen by the colour-coded underlining of words.

\n
\n
\n
\n\"KE\n
\n
\n
\n

The logic behind the mapping suggestions is indicated on the screen in the form of coloured, straight and dotted underlining of the words the SME used to describe a step. Each indicator is explained below:

\n
\n
\n
    \n
  • \n

    Dotted line
    \nHIRO™ was able to match to an existing variable

    \n
    • \n
  • \n

    Red line
    \nHIRO™ wasn’t able to understand the user input

    \n
    • \n
  • \n

    Blue line
    \nHIRO™s suggestion was overwritten by the user or a new definition was added

    \n
    • \n
\n
\n
\n

A Knowledge Expert needs to confirm HIRO™'s mapping when autogenerating KIs. This can be done by clicking on underlined words and selecting an existing variable from the pre-defined list, or creating a new one by defining the variable name, a description, and an indicator if it should serve as a ToDo variable or not.

\n
\n
\n

4.2.1 ToDo Variables and Task States

\n
\n

A ToDo Variable differs from other [\"Information\"] Variables as it implies an action needs to be taken. For example, ApproveOrder is an action that needs to be taken, whereas OrderApproved provides information of the status. The main function of the ToDo Variables is to indicate to HIRO™ that something is to be done. Once the necessary steps are taken to complete an action indicated in a ToDo Variable, that Variable is then deleted. HIRO™ will continue to process Tasks (\"PROCESSING\" state) for as long as there are ToDo Variables still present.

\n
\n
\n

When all ToDos have been deleted the Task state changes to \"RESOLVED\" meaning that it has been solved fully autonomously by HIRO™. If the existing knowledge inside HIRO™ at a given point in time is not sufficient to carry out all necessary steps, so there are ToDo variables still left on the Task but no KI is triggering, the Task will stay in PROCESSING state. When a Task is in PROCESSING but no knowledge is being applied, HIRO™ will wait until the Task has been idle for 900 seconds, then will automatically change its state to \"STOPPED\" indicating that HIRO™ could not solve the Task autonomously and will need to be taught the missing knowledge after an SME successfully completes it manually.

\n
\n
\n
\n

4.2.2 Variable Naming Conventions

\n
\n

As Variables are global, and KIs are eligible to be applied to any Task, it’s good to agree on a set of rules regarding Variable and KI naming conventions. The suggested best practice can be found below:

\n
\n
\n
    \n
  • \n

    ToDo Variables always start with a verb.

    \n
    • \n
  • \n

    Information Variables always start with a noun.

    \n
    • \n
  • \n

    CamelCase is used for Variable names (to differentiate between the two at a glance, ToDos can start with a capital letter, and information variables with lowercase).

    \n
    • \n
  • \n

    Variable description should contain what the variable indicates, expected values (e.g. Variable indicates the current free memory available on a server. Expected values are in GB), and a short description on keys usage, when applicable.

    \n
    • \n
  • \n

    KI Title should be consistent with its contents (double-check this at the end if forking, or copy-paste is used).

    \n
    • \n
  • \n

    KI Description should summarize Applicability, Situation and Action in one or two sentences.

    \n
    • \n
\n
\n
\n
\n
\n

4.3 HIRO™ KAT Principles

\n
\n

When a newly-handed-over Teaching Session begins, the Knowledge Expert, should go through it briefly, to get a view of what is being automated. Then, they would work on each Step one by one, to maximise HIRO™'s efficiency.

\n
\n
\n
\n\"Step\n
\n
\n
\n

They should ensure the Step definition is clear as they will need to browse through existing knowledge that HIRO™ has found to be eligible for reuse, or trigger the automatic code generation to create a new KI. The following principles were created to aid in this process, and to refer back to while teaching HIRO™.

\n
\n
\n
\n\"Automatic\n
\n
\n
\n
    \n
  • \n

    Variable declaration needs to be completed (wherever the SME has skipped this step)

    \n
    • \n
  • \n

    No variables used for substitution in DO block without having checked for them in ON or WHEN block (This will also break the colour-coding) not entirely sure this was just for Substitution, for example, it didn’t like ogit/Schedule/Calendar == something either

    \n
    • \n
  • \n

    Try to understand KI description as a whole (logically, what is the SME trying to teach HIRO™ to do? Have a clear answer for this, and don’t let the Variable suggestions sway you)

    \n
    • \n
  • \n

    When there are suggested KI, always inspect those first to see if 1 could be reused for this same purpose

    \n
    • \n
  • \n

    Only if none can be reused, create a new KI

    \n
    • \n
\n
\n
\n
\n\"KE\n
\n
\n
\n
\n
\n
\n
\n

5. Logic of KI Writing

\n
\n
\n

5.1 What are KIs

\n
\n

HIRO™ automates using Knowledge Items (KIs), which are atomic representations of Steps that are taught to HIRO™ by an SME. Once added to the pool, KIs can be re-combined with existing knowledge inside HIRO™ to form automated solutions of similar Tasks. The SME input will be given through a chat conversation with HIRO™ Chatbot, and HIRO™ then can convert this knowledge into KIs.

\n
\n
\n

An Knowledge Expert will review SME input, and ensure that HIRO™'s given the right amount of detail and context in order to get the best results from its automatic code generation feature.

\n
\n
\n

The SME will sometimes use words that are not yet in HIRO™'s Vocabulary, in which case they can extend this by defining a new Variable. If an SME skips Variable definition, or matching of existing Variables, it falls on the Knowledge Expert to map the natural language to Variables using the context provided in the chat. Once all the necessary Variables are defined, HIRO™ has a basis for the conversion.

\n
\n
\n
\n

5.2 What are Nodes

\n
\n

Knowledge Items contain information on where and when they can be applied. In practice, this means each KI contains conditions that need to be met by the Environment, and others that should be met by the Task. HIRO™ begins automation with a pre-existing environment, in the form of a graph.

\n
\n
\n

This graph will typically contain representations of factual knowledge which are relevant to the field of automation. Single instances of these representations are called Nodes. This information is inserted into HIRO™ at the time of Integration, and it is a form of enabling HIRO™ to understand the context in which it’s being taught, and providing it with the means of running actions on said Nodes.

\n
\n
\n

Each Node describes a part of the environment using Variables, which is HIRO™'s existing Vocabulary. These Variables can be read by a Knowledge Item, which is what happens at the time that a new KI is inserted into HIRO™. The ON block of a KI will contain conditions which the Variables of existing Nodes need to match. For each match, the Knowledge Item is made available for use, on that Node. What this means is that Knowledge \"sits\" on Environment Nodes, and is idle until a Task occurs.

\n
\n
\n
\n

5.3 What are Tasks

\n
\n

Tasks are a list of attributes that describe the situation at a given point in time. Tasks will always originate on an Environment Node, indicating that a certain task or process, likely affecting that Node, needs to be carried out. As soon as a Task is created, HIRO™ will check all of the KIs available on the Node it originated on, and will trigger the one(s) whose WHEN conditions are met by the specific Tasks.

\n
\n
\n
\n

5.4 Intro to KI Syntax

\n
\n

KI Syntax is a formalization language for knowledge around automating processes. It is the basis for the Knowledge Items (KI).

\n
\n
\n

The assumption is, the system will have access to the same information as any (privileged) user and needs to be taught how to interact with the data in order to solve Tasks. KI Syntax 6.0 describes logic that processes/gathers/generates data in a certain way to contribute to the overall problem solution. This logic is stored in the Knowledge Items. HIRO™ Engine applies Knowledge Items to its tasks.

\n
\n
\n

Application of Knowledge Items works by matching data to KIs that call for these conditions and associating each KI to these data points. This is called \"binding\". At any time many Knowledge Items can be \"bound\" to the same data.

\n
\n
\n

A Task includes the current state of data gathered/generated for this Task and the history of steps and changes made to the data during processing.

\n
\n
\n

A very simplified Task could look something like this:

\n
\n
\n
\n
{\n \"/Subject\": \"MyTestTask\",\n \"/MyVariable\": [\"FirstValue\", \"SecondValue\"]\n \"ogit/Automation/originNode\": \"pzcxyhawulkadasnwascxzy\"\n}
\n
\n
\n
\n

While KI Syntax 6.0 borrows heavily from common programming language features like string expansion or comparison operators, it should not be confused with a programming language. KI Syntax 6.0 purposefully does not natively support creation of large monolithic algorithms. The goal is to write atomised bits of knowledge that can be freely strung together by their inputs and outputs and are as re-usable for as many use cases as possible.

\n
\n
\n

5.4.1 Functions vs Definitions

\n
\n

The core information is grouped in the Functions and Definitions parts. The Definitions section contains information on concepts such as aliases, scoping, data values etc. The most important section here is the “Matching variables and values”, where we see all the syntax necessary for variable matching. This is how a KI would communicate criteria, which means these are only used in the ON or WHEN blocks of Knowledge Items.

\n
\n
\n

The Functions dropdown contains information on how HIRO can carry out actions on target systems. This will be information primarily used in the DO section of a KI. Functions require arguments which are either unnamed ordered (positional) or named (keyword), depending on the function.

\n
\n
\n
\n\"FunctionsArguments\"\n
\n
\n
\n


\nThe function results are returned as tagged values, and matched to variables using the syntax:

\n
\n
\n
\n
<tag>: <var>,\n<tag2>: <var2> [...] = function(...)
\n
\n
\n
\n

The full list of implemented functions can be found in KI Syntax.

\n
\n
\n
\n
\n
","document":{"main":"Knowledge Expert (KE) User Guide","title":"Knowledge Expert (KE) User Guide","subtitle":""},"fields":{"toc":true,"location":["guides","ke-user-guide-7"]}},"sidebarYaml":{"id":"6d066bdd-c982-5a69-b909-a31e6fc044e0","showIndex":true}},"pageContext":{"id":"51841f8d-0b7e-5dff-b8ab-bf95f9c8fbe7","parent":"guides"}},"staticQueryHashes":["1010459453","1010459453","2356112386","2356112386","2603905930","2603905930","3026652197","3026652197","3167850324","3167850324","63159454","63159454"]}