In what layers should the inheritable rules be placed? 

These rules should be placed in the layer that promotes the appropriate level of reuse that you can anticipate for future applications. Often in the first release of a Pega application for a new Client, some of the data types that represent the Client's core business data (and which will be used by future Pega applications) are identified. These should be defined in the Enterprise layer -- and their Properties, and other truly enterprise-reusable rules.

Your Client should be happy to guide you on whether they consider a data structure to have a broader scope than the first application you are delivering.

Resist the temptation to put everything in the Enterprise layer "just in case" we need to use it later. This can inhibit reuse as there is "too much junk" in the Enterprise layer. Collaborate with your Client to gain consensus on the best known outcome. 

Some will ultimately be proven wrong, but don't be too concerned. The initial outcome was achieved by consensus, so there is no blame. Should an Application-specific Class 'A' be later deemed to have more re-use potential:

1. Create the more reusable Class 'R';
2. Set the Direct-inheritance of Class 'R' to match current Direct-inheritance of Class 'A';
3. Re-wire the Direct-inheritance of Class 'A' to Class 'R'
4. Progressively move the reusable capability in Class 'A' to Class 'R' and withdraw the corresponding rule from Class 'A'.

There should be no difference at runtime. All refactored rules previously resolved from Class 'A' are now resolved from Class 'R' via inheritance (beware of Pattern-inheritance classes between 'A' and 'R' whose rules will resolve before 'R').

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.