It's understandable that you might want to do that, but if so that might make sense more at the transition point of the status rather than as a Fix Script.  None of this is written in stone, and certainly customers do have different perspectives and practices here, so there is inherently some subjectivity but the desire is to move toward consistent practices for managing lifecycles.  That said here is what I would suggest considering:

• If something is Absent, in general that means we don't really know what its status is.  From a Discovery perspective this could just mean that it wasn't included in the last scan, which could be a temporary condition.  Maybe Non-operational makes sense here?  An argument could be made either way.
• If something is Retired, this might NOT mean it is non-operational.  Perhaps it is being retired because it is still functional but no longer meets the required use of the services that have depended on it.  It could potentially be put back into stock for reuse by another party.
• If something is In Stock, is it operational or not?  Is it worth tracking this on a CI level?  Often we don't think about tracking CIs for assets that are In Stock because they don't meet the theoretical definition of a CI (a deployed asset) but in reality it's not really that cut and dry.  For instance, if you have Loaner laptop, you will return them back into stock every time they are returned, but the CI still lives on between active assignments, so we might want to be able to track the difference between a Loaner laptop that is Operational (i.e. ready to be loaned out) and one that is Non-Operational (i.e. Pending Repair).

As you can see, it's still a bit subjective, but I think the more we can clarify the difference in usage and meaning between Install Status and Operational Status the better off we'll be.  And to me that means that since Operational Status is not actually part of the synchronization between Asset and CI, it should not be further leveraged as a critical part of the lifecycle transitions, but be used more informationally.  Even the CSDM Lifecycle is not perfect, but it's much more consistent, so my recommendation is that if you are going to base anything like metrics on something solid, you might want to consider implementing them now, as it will be more likely to be compatible with future releases.