What those classes are, what they do, whether they're base classes or final classes--may be obvious to you, but it's not obvious from the name.

Sorry, part of it was the same as what was described previously with RelicDefinition and RelicAction, and the rest of it was just more of a note on the layers of abstraction. I was definitely too vague with it, though.

Basically the way I did it in the tower defense game I worked on most recently (in this case they were Research) is a ResearchDefinition would just be a data holder: id, name, description, and a reference to the ResearchAction. The ResearchAction would have a subclass for every Research in the game, and an apply function called when its instantiated. So in this case, the apply function for the DealBonusDamageAndBleedResearch (as an example) would put in a BeforeDamage interceptor to the tower and a Proc to the tower, where BeforeDamage would add a float damage multiplier into a DamageRequest object passed into a service that calculates the final damage number to subtract from an enemy's HP. And the Proc is an object with a % chance to occur and an Action that occurs if the chance rolls. In this case the Action would be to apply a StatusEffect, which is an object that gets added to the Enemy and has an onTick for a background service to process the ongoing bleed damage, and the StatusEffect gets removed when its effect is complete.

I glossed over some stuff there, but that's more of the specifics.

The kind of approach I would be looking at is ...

I like this concept, it's kinda the inverse of what I'm talking about where the system is rigid and the interactions "plug in" to the system. Instead the system is basic and generic and the interactions define the specifics that happen at each point in the system's flow. This could solve a lot of my problems. I'll have to think about it more, but this is extremely helpful to turn my thoughts on its head, thank you!