Note: This is a feature to validate rule conditions, not incoming events.

An Event has attributes/types/keys can we record that and offer suggestion to users based on the content of the payload just once when the first event comes in

Because most of the time the Shape of the Event is the same.

1. Record the first event and store its structure.
2. Check rule conditions if it meets the structure. (If not, raise a suggestion). Only once

if we had an event that looks like

event:
     payload:
          - alerts:
               name: Fred

We know the shape as event.payload.[alerts].name

so if we see the user is close to that match but not exact we can offer an error message saying did you mean event.payload.alerts if the user had entered event.alerts (<- checking a rule which the user entered)

If the user has made a typo in the first pass thru Drools nothing will match, that is a hint to us that its possible that the user might have a typo.

At that point we compute the shape of the event and then check against the conditions once.

Offer a suggestion and then from the second event onwards, don't offer any suggestion.

In a well written rulebook where the condition matches something in the event we should not do this.

We can start with 1 event shape and then maybe extend it to other event shapes down the road.

Hint: https://www.mi.fu-berlin.de/wiki/pub/ABI/RnaSeqP4/filtering.pdf

Additional info:
Use case like

Correct rule:

condition: event.payload.alerts[0].labels.job == "kube-state-metrics" and event.payload.alerts[0].status == "firing"

But a user write

condition: event.alerts.labels.job == "kube-state-metrics" and event.payload.alerts.status == "firing"

or

condition: event.payload.alerts.labels.job == "kube-state-metrics" and event.payload.alerts.status == "firing"

With this feature, the user can notice the mistake in the rule when an event comes in.