...
This diagram shows one of the events connected with logging in, owner:eci_requested. Four rules might be selected for this event (depending on their where clauses), and they are shown left-to-right in the order they appear in the ruleset (which is the same order they would be evaluated in, if selected). Suppose that we would like to augment this behavior, in another ruleset (using this one as a module) which would provide a dummy ECI when the owner_id provided isn't known.
The only opportunity to hook into these rules to provide a dummy ECI would be to react to the owner:login_attempt_failed event, but then the other ruleset would have to do all of the work for the second purpose, including scheduling and providing the cleanup of the temporary channel. Besides that, the new temporary channel wouldn't be able to use the policy mentioned in line 11, because it's kept in an entity variable of the account management ruleset (so it would have to be provided and obtained through a module reference). It quickly gets very complicated, and in the interest of DRY, this isn't really the way to go.
...
Here the left-hand branch (from the third rule) shows the chaining to the new provide_temporary_eci rule. Also shown is how another ruleset can hook into the owner:no_such_owner_id event to provide a dummy ECI. By raising the owner:eci_found event, it can cause evaluation to rejoin the main ruleset. The code is shown in the next section, and is very simple.
How this is useful
...