You already know that Pega applications are built from rules. But a functioning application is more than just a random collection of rules. It’s a carefully organized structure, a blueprint that brings together case types, data models, and logic to solve a specific business problem. Think of the Pega application layer as the master container that defines the boundaries and capabilities of your solution.

At its core, an application record in Pega does two critical things: it defines the available tools (the rulesets) and the structural foundation (the class hierarchy). Getting this architecture right from the start is the difference between a scalable, maintainable system and one that becomes difficult to manage over time. The two main components that define this architecture are the ruleset stack and the class structure.

A ruleset is simply a container for rules, like a folder for files. Its real power comes from how applications organize them. Every application has a Ruleset Stack—an ordered list of rulesets that Pega searches from top to bottom when it needs to find a rule. This ordered lookup is called rule resolution.

This stacking mechanism is crucial for versioning and modularity. You can create new versions of a ruleset to introduce changes without affecting the original version. For example, you might have MyCo:01-01-01 for the initial release and later create MyCo:01-01-02 for a minor patch. The application stack determines which version is currently active.

If rulesets organize rules into modules, the class hierarchy organizes them by business object. It provides the application's structure and, most importantly, enables inheritance. You're familiar with creating case types, which are just classes in Pega's hierarchy. A case for an auto loan might belong to the MyCo-Loan-Auto class.

This class inherits rules—like properties, UI sections, and data transforms—from its parent classes, such as MyCo-Loan- and all the way up to Pega's ultimate base class, @baseclass. Pega uses two types of inheritance: pattern inheritance and direct inheritance. Pattern inheritance follows the class name's hyphenated structure, while direct inheritance allows a class to inherit from another class that doesn't fit that pattern.

A well-designed class structure mirrors the business, creating a logical place for every rule and making the application easier for developers to understand and extend.

As applications become more complex, it's common to split them into two layers: a framework and an implementation. This is a core architectural pattern for promoting enterprise reuse and accelerating development.

An implementation application lists its framework application in its "Built on Applications" list. This allows the implementation to inherit all the rules and case types from the framework, extending them where needed. The result is faster development cycles, as implementation teams don't have to rebuild core functionality. It also ensures consistency and makes maintenance easier, since updates to the framework can be automatically propagated to all implementations.

Now that you understand the core architectural components, let's test your knowledge.

Understanding these architectural principles—applications, rulesets, and classes—is the key to building Pega solutions that are not just functional, but also scalable and easy to maintain.