Let's talk for a bit about correlation identifiers. Correlation IDs are used to identify the different parts of a computation when they happen concurrently. Picos are single threaded, so you never have to worry about this in a single evaluation cycle (response to one event) in a given pico. But as soon as there is more than one actor involved in a computation, you run the risk that things might not happen in order and parts of your computation will come back differently than you expect.

For example, in Fuse, creating fleet report was initiated by an event to the fleet pico. This, in turn, caused the fleet pico to send events to the vehicle picos asking them to do part of the computation. The vehicle picos responded asynchronously and the fleet pico combines the results to create the completed report. Suppose the initiating event is received twice in quick succession, the vehicle picos will get multiple requests. It's possible (due to network delays, for example) that the responses will come back out of order. This picture shows the situation:

The response pattern on the left is what we want, but the one of the right is one of many possible combinations that could occur in practice. The colors of the two events and the events they spawn (red or blue) are a pictoral correlation identifier. We can easily save the various responses and then combine them into the right report later if we know all the red responses go together and all the blue responses go together.

To make correlation IDs work in KRL, you wouldn't use colors, of course, but rather a random string for each initiating event. So long as all the participants pass this ID along as an event attribute in the various computations that occur, the fleet pico will be able to use the right pieces to create each report.