i see so you can used delayed event to potentially send messages between modules but only on the same card ?
No, delayed events can be listened for by any trigger, including those on other cards. I've never used them for this myself, but you'll see some modules emit delayed events with the intention of allowing other modules to react to them. Personally I think delayed events are underutilized. I've found them useful for re-using code since you can essentially use them as a means to call triggers like you would call a function in other languages.
The reason I suggested them as a way to do a final initialization on the same card is because you can just have a trigger listening for the same Card Added to Class event that most modules use for their initialization, and this trigger would emit a delayed event with a delay time set so that the 2nd trigger listening for the delayed event would only fire after the other modules are done initializing. These triggers could be restricted with the typical ThisCard == TriggerCard, which would mean they only ever fire once when the card gets added to the class. It gets more complicated if you're trying to run a final initialization after multiple cards are added because there's no way of knowing when the player is done adding the cards that they want, and thus when all of the other modules are done initializing, so you'd have to be content with this hypothetical final init trigger running multiple times.
Ultimately I don't know what your goal is, but if it's to check for the existence of certain modules and react to their existence in some way, then the simpler and safer route is just to have a single trigger doing the check that runs once at the start of the day or even at the start of each period. It won't have any noticeable performance impact, and it'll account for things like cards being added or removed mid-save, modules enabling/disabling each other, and people adding/removing modules on cards in a save using QtEdit.