Certified Pega Data Scientist cheat sheet

Pega Platform separates design-time artifacts (rules, case types, data types) from run-time instances (cases, assignments, work objects); rules are versioned and resolved by Rule Resolution at run time.

Rule Resolution precedence order: class hierarchy (most specific class wins), then ruleset list and ruleset version, then circumstance (temporal, property, date), then rule availability (Available, Blocked, Final, Withdrawn).

Circumstancing by property or date creates a more specific rule instance; if two circumstances both apply, precedence follows circumstance type ordering, and an unresolvable tie triggers a resolution warning.

A ruleset is the unit of versioning and deployment; rulesets are assembled into a RuleSet stack per application, and higher entries in the stack resolve before lower ones.

Class layering: an application class inherits from the organization class (Data-) and framework classes; a rule defined at a more specific class overrides the same rule at a less specific class without editing it.

Data pages are named, cacheable structures with scope (thread, requestor, node, application); a data page with reload-if-older-than refreshes on access after the threshold, and Save Plan caches the mapped source response.

Clipboard pages follow a hierarchy: pxProcessPage, pxRequestor, pxThread, pyWorkPage; pyWorkPage holds the primary case data and is the page most activities and UI rules default to.

Security is layered: access group (ruleset stack, application, portal, default role), access role of rules (privilege checks), and attribute-based access control (ABAC) conditions evaluated on case data.

Agents and job schedulers run background processing on a node; standard agents handle system work while custom agents must be defined on the node type (background processing vs. web user node) to run.

Process AI in Pega uses machine learning to predict outcomes such as case urgency, routing destination, and next-best-action; models are trained on historical case data captured in the Pega Platform.

A predictive model has a set of predictors (properties), an outcome (label), and a score; binary models output a probability and a threshold-driven label, while multinomial models produce a ranked set of outcomes.

Model performance is judged by AUC (area under ROC curve) for binary outcomes and by accuracy or F1 for multiclass; AUC near 0.5 indicates a model no better than chance.

The modeling lifecycle is: define outcome and predictors, prepare and sample data, train candidate models, evaluate against a holdout set, then deploy and monitor for drift.

Adaptive models update their behavior as new case outcomes arrive, unlike static models that require retraining; adaptive decision and predictive models suit changing operational conditions.

Text analytics converts free-text case notes into structured predictors via entity extraction and sentiment/topic scoring, which can then feed predictive or decision models.

Prediction Studio is the authoring environment for building, testing, and deploying predictive models; it reports predictor importance so low-value predictors can be removed.

Model monitoring compares live prediction distributions against training distributions; a significant shift in predictor or score distribution signals data drift and prompts retraining.

Feedback loops matter: if routing decisions change which cases are labeled, the training data becomes biased, so outcome capture must include cases not selected by the model.

A decision strategy is a directed graph of components evaluated in order; shapes include Decision, Proposition Data, Group By, Filter, Prioritize, and Output, and each shape passes a page list forward.

A decision table evaluates rows in order and returns the first matching row's result; a decision tree splits on conditions and returns the leaf reached, so row/order design determines outcomes.

Strategy results are ranked by propensity or priority; the Output component defines the final result count and the properties returned to the calling case or channel.

Next-Best-Action uses arbitration to select among eligible actions: eligibility (when conditions), suitability (propensity or score), and arbitration (business levers such as weight, value, and caps).

Adaptive models in decision strategies score continuously from feedback; they coexist with predictive models, and strategy testing (A/B or champion-challenger) compares their lift.

Business levers are configured on the arbitration component: weights adjust propensity, and caps limit how many times an action is presented per customer in a period.

Offer eligibility can be enforced by when conditions on propositions and by contact policy limits that suppress over-contacted customers before arbitration.

Decision data flows through Data Flows and Data Sets: a data set is a named source or sink (database, stream, file), and a data flow defines the transformation shape pipeline between them.

Simulation and strategy testing run a strategy against historical or sampled data to compare variants; lift is measured as the difference in conversion or value between the challenger and champion.

A case type defines the case lifecycle: stages (primary phases), processes within stages, and steps (assignments or automations); a case advances when its current stage's processes complete.

Stage types are Create, Process, and Alternate; alternate stages are entered on demand and can run in parallel with the primary stage, and a case can only be in one primary stage at a time.

A process contains steps executed in sequence; assignments create work for a user or work queue, while automations (data transforms, activities, decision steps) run without user interaction.

Case status is derived from the current stage and step; a case's overall status (Open, Pending, Resolved, Withdrawn) is separate from its stage, and resolution is set by a resolution stage.

Service levels define goals, deadlines, and passed-deadline behavior (escalation, urgency increase, notification) and are attached to steps, processes, or the case type.

Routing options include work queue, work group, skill-based routing, and to a specific operator; work group membership and skills determine which users can pull an assignment.

A subcase is a child case linked to a parent; subcases share data through the parent and can run their own stages, and the parent can wait on subcase completion.

Case locking prevents concurrent edits: default optimistic locking detects conflicting saves, while pessimistic locking holds the case lock for the duration of an assignment.

Data propagation across stages uses data transforms and the case's pyWorkPage; stage-level data is available to later stages, and case-wide properties persist for the case lifetime.