Hi @Noah.ClarkX5FEF. When we are working with an 'internal' (saved within the Inventor document) iLogic rule (as opposed to an external rule), and we include the unquoted name of a parameter that is present in the same document that the rule is within, that parameter name will usually turn Blue, by default. That is an indication that it is recognized as directly representing the value of a local parameter. When we include those within internal rules, that will cause the rule to be triggered to run whenever the value of those blue parameters changes. That behavior will not work in external rules, or when using the iLogic Parameter("Parameter_Name") tool.
However, there are other ways to achieve similar functionality. The simplest option would be to place that iLogic rule into the Event Triggers dialog, on the 'This Document' tab, under the "Any Model Parameter Change" event and/or under the "Any User Parameter Change" event. If you do it that way, the rule may be triggered to run far more often, but at least it will run when that/those parameter's values change. If you are using the Parameter("Parameter_Name") tool, because the code is in an external rule, where you can not use the blue, unquoted parameter names, then what you can do is create a local rule within the model file, and simply includes one or more 'dummy variables' (not used for anything) where you set their values with those blue parameter names, just to cause that rule to be triggered to run when those parameter values change, then include a line of code to run the external rule you want to deal with those parameter changes. That way the 'real' code is in the one external rule, while the 'local' rule is just a dummy one for enabling the triggering action.
If that behavior is unacceptable, and you only want it to run when that exact parameter value changes, then we must create our own custom event handler codes for monitoring 'all' parameter change events, which includes a lot of filtering in order to avoid responding to all those other parameter changes, and only respond to that one (or more) specific parameter changes, from that one specific document. Code like that is more advanced, and is usually best suited for use within Inventor add-ins, instead of trying to handle it with iLogic rules. The code for handling the custom event would need to be ran one time (not multiple times) to start it 'listening' in the background for the events, while you do other things in Inventor. Then when those types of events happen, it catches them, evaluates them, and reacts appropriately. If not set-up right, could degrade Inventor performance.
Wesley Crihfield

(Not an Autodesk Employee)