The role of a Guardrail Warning is to draw your attention to a configuration that introduces a potential risk to your application, including (but not limited to) considerations on performance, data integrity and maintainability.

Consider a Guardrail Warning as a checkpoint for "Are you sure you want to proceed with this configuration?".  Don't consider it a call to "Don't ever do this!!!", otherwise it would be built into what makes a rule instance valid and it wouldn't save. 

Always consider whether you can re-implement the feature in a manner that eradicates the Warning, but if the configuration is justifiable - to its Developer and their Build Reviewer - record the justification in the rule and proceed. 

Minimize the number of non-Guardrail-compliant rules by encouraging their reusability, by positioning such rules in Enterprise layers and parameterizing them. This avoids proliferation of the risky configuration in Case layers, and the potential that some developers misconfigure the pattern.

This yields a larger number of Guardrail-compliant rules that invoke a smaller number of non-compliant rules. The non-compliance risk is contained, justified by the developer and endorsed by the reviewing LSA.

For example, the Polymorphism chapter of the webinar showcased using an Activity to create a page on the clipboard with its type (class) determined at runtime. This raises a Guardrail Warning about Activity usage that is justifiable on the basis that:

1. It is needed to deliver the Polymorphism design required by the application; and 
2. Following the recommendation (to use a Data Transform) would resolve this Warning, but raise a new one (for directly setting .pxObjClass in a Data Transform). 

There would be very few rules in the application that need to create pages in a polymorphism-aware manner, so this would actually have minimal impact on the Guardrail Score. By parameterizing the non-Guardrail-compliant Activity (or Data Transform) and making it available in the Enterprise layer, the number of non-compliant rules might be reduced to as few as one.

A justified guardrail warning has 5 times less impact on the application's Guardrail Score than leaving the same warning unjustified.

Discussion on this topic was sought from the LSA Data Excellence (Pega 8.4) webinar conducted in July 2020. The webinar and its full set of discussions that arose from it are available at LSA Data Excellence: Webinar, Questions & Answers.