Human in the loop¶

Automation can catalogue, survey, classify, provision and monitor. What it cannot do is make the judgement calls: whether these two records really are the same customer, whether this data set may be released, whether an unexpected survey result is a problem or a quirk. Those need a person - and the person needs to find out that they are needed, understand the situation well enough to decide, and have their decision picked up by the process that was waiting.

Getting that loop to work is the difference between automation that scales and automation that stalls.

People need to see what is happening¶

The first half of the loop is visibility. Egeria's user interfaces present both the structural picture and the operational one.

The structural picture - what exists and how it fits together:

• The Catalog for the inventories of infrastructure, data assets, APIs and processes.
• Egeria Explorer for the wider knowledge graph, including the type system and the valid value sets behind it.
• Lineage Explorer for where data came from and where it goes.
• Mermaid graphs, generated from the metadata itself, so a diagram is never out of date with what it describes.

The operational picture - what the ecosystem is doing right now:

• Egeria Operations shows the status of servers, connectors, governance engines and engine actions, and supports simple commands such as refresh, restart and cancel.
• Egeria Audit shows exceptions, certifications, licenses and users.
• My Egeria gives an individual their own view: their to-dos, meetings, reviews, roles, communities and teams, as either a terminal or browser application.

Being able to see both matters more than it sounds. A person asked to make a decision needs the structural context to understand what they are deciding about, and the operational context to know whether what they are looking at is current.

Automation needs to reach people¶

The second half of the loop is the outbound call - and it has a range, not a single mechanism. What is appropriate depends on how much the automation needs from the person.

A notification is simply a record to be read, organized into a note log - an activity log entry, a blog entry, a journal entry. Nothing depends on the reader doing anything.

A notification type goes further: it defines the trigger, the style of notification and the recipient, so people subscribe to the situations they care about instead of watching everything. This is managed through the Notification Manager API, which links notification types to the elements being monitored and maintains the list of subscribers. The graph below shows an engine action doing exactly this - a watchdog service maintaining the notification types for every subscription in the digital product catalog:

---
title: EngineAction - baudot-subscription-manager (EgeriaWatchdog) [3374b860-eb43-423e-804e-93d6a2f40538]
---
flowchart TD
%%{init: {"flowchart": {"htmlLabels": false}} }%%

1@{ shape: rounded, label: "*Engine Action*
**baudot-subscription-manager (EgeriaWatchdog)**"}
2@{ shape: stadium, label: "*Integration Connector*
**JacquardHarvesterIntegrationConnector**"}
2==>|"Action Requester"|1
3@{ shape: rect, label: "*Digital Product Catalog*
**Open Metadata Digital Product Catalog**"}
3==>|"Actions"|1
4@{ shape: doc, label: "*Notification Type*
**Notification type for Daily refresh subscription for product List of People**"}
1==>|"notificationType [Action Target]"|4
5@{ shape: doc, label: "*Notification Type*
**Notification type for Ongoing update subscription for product Valid Metadata Value Set: defaultMediaUsage**"}
1==>|"notificationType [Action Target]"|5
6@{ shape: doc, label: "*Notification Type*
**Notification type for Evaluation subscription for product Valid Metadata Value Set: contactMethodType**"}
1==>|"notificationType [Action Target]"|6
7@{ shape: doc, label: "*Notification Type*
**Notification type for Weekly refresh subscription for product Valid Metadata Value Set: projectHealth**"}
1==>|"notificationType [Action Target]"|7
8@{ shape: doc, label: "*Notification Type*
**Notification type for Evaluation subscription for product Open Metadata Types List**"}
1==>|"notificationType [Action Target]"|8
9@{ shape: doc, label: "*Notification Type*
**Notification type for Evaluation subscription for product Survey Report List**"}
1==>|"notificationType [Action Target]"|9
10@{ shape: stadium, label: "*Action Target*
**... plus 302 Items**"}
1-.->10
style 1 color:#000000, fill:#e0ab18, stroke:#004563
style 2 color:#000000, fill:#BDB76B, stroke:#004563
style 3 color:#000000, fill:#f5fffa, stroke:#000000
style 4 color:#FFFFFF, fill:#006400, stroke:#000000
style 5 color:#FFFFFF, fill:#006400, stroke:#000000
style 6 color:#FFFFFF, fill:#006400, stroke:#000000
style 7 color:#FFFFFF, fill:#006400, stroke:#000000
style 8 color:#FFFFFF, fill:#006400, stroke:#000000
style 9 color:#FFFFFF, fill:#006400, stroke:#000000
style 10 color:#000000, fill:#F9F7ED, stroke:#b7c0c7

A to-do is the strong form: a work item with a description, a priority, a due date and a status that moves from requested through in progress to complete. It has an originator - which may be a person or a governance action process - and it is assigned to a role rather than directly to an individual, so the work survives someone changing jobs or going on leave. When automation raises a to-do, it is usually because it cannot proceed until the work is done.

An incident report is for situations rather than tasks: it provides a focal point for coordinating a response, accumulating the cause, the affected resources, related incidents and the actions taken, so there is a complete record afterwards.

Closing the loop¶

An individual has no REST API to call. So the pattern is always the same: the automation records what it needs and notifies someone; the person investigates through the user interfaces, makes the change through the APIs or a connected tool; the automation sees the change and continues.

This is described in more detail under working with people, and it is the basis of stewardship: survey action services produce findings, and rather than applying every finding blindly, the significant ones are put in front of a subject-matter expert who confirms or rejects them. Even when human validation is required, the effort is far smaller than doing the work by hand - the person is reviewing a candidate answer rather than producing one.

Two things make this practical at scale:

• Assignment to roles, not people. Because responsibilities are held as roles with appointees, automation can address the responsibility and let the organization decide who currently holds it.
• A record of what was decided. The to-do, its status and the change that resulted are all in the metadata, so a decision made under time pressure can be explained later.

The same mechanisms serve AI¶

Automation connected to Egeria is no longer only Egeria's own governance engines. AI applications working through Egeria's APIs participate in the same loop: they read the structural and operational context from the knowledge graph, and they raise the same range of notifications and work items when they need a person - whether that is an informational message, or a decision the application is waiting on before it acts.

Keeping people addressable in the same way as any other participant is what allows an organization to add AI to a process without losing the ability to say who approved what.

Raise an issue or comment below