Building Nexus: A CLSA-Level Deep Dive into Pega Blueprint to Application Architecture

Building Nexus: A CLSA-Level Deep Dive into Pega Blueprint → Application Architecture

We took a Pega Blueprint (a GenAI-generated application design) for a Retail Banking Customer Onboarding flow, hardened it against Pega's own best-practice checker, and then built it into a live Pega Infinity application called Nexus, owned by organization Alpha. Along the way we made a real mistake — one that cost a full rebuild — and it turned out to be exactly the kind of rule-level mechanic that CLSA (Certified Lead System Architect) prep is supposed to make second nature: how Pega decides class inheritance at application-creation time, what “built-on application” actually wires into the ruleset list, and how a Data Object's System-of-Record setting changes its runtime semantics.

This post documents all three at the level a CLSA candidate needs: not “click here, click there,” but why Pega resolves things the way it does — so the reasoning transfers to any application you architect, not just this one. Exact menu wording and screens can shift a little between Pega Infinity releases, so treat the click-paths as illustrative and the underlying mechanics (which don't change release to release) as the part worth memorizing.

What we built:

Blueprint source	BP-2499757 — CLM/KYC: Client Onboarding for Financial Services
Target instance	Pega Infinity '26.1.1
New application	Nexus (org: Alpha, division: RetailBanking, unit: Onboarding)
Base class	Alph-Nexus-Work
Built-on application	CLM for Financial Services – CIB
Case types	5 (Customer Onboarding, KYC Review, AML Screening, Risk Assessment, Onboarding Approval)
Rules built	395+

Contents

• 1. Blueprint design review: what “good enough to import” means
• 2. Extend vs. New Application: the mistake, and the rule-resolution mechanics behind it
• 3. Class layers: how “Alpha” + “Nexus” become a class hierarchy
• 4. “Built-on application”: what the warning actually meant
• 5. Data Model: what “System of Record” changes under the hood
• 6. Security architecture: from Persona to real access control
• 7. What the build engine actually did, rule by rule
• 8. The 11 warnings we're carrying forward
• 9. Mapping this exercise to CLSA exam domains

1. Blueprint design review: what “good enough to import” means

Blueprint's own best-practice checker flagged two gaps before it would let us download a clean package. Both are worth understanding at the design-rationale level, because they're exactly the kind of judgment call CLSA's Application Design and Security Design domains test.

Case decomposition: why five case types, not one

The natural instinct is to model “Customer Onboarding” as a single case with a long flow. Blueprint split it into five: Customer Onboarding (orchestrator), KYC Review, AML Screening, Risk Assessment, and Onboarding Approval. The rule is: split into a separate case type when the sub-process has its own lifecycle, its own owner, or its own audit/reporting requirement independent of the parent.

KYC Review and AML Screening qualify because regulators audit them as distinct control activities — a compliance team needs to report “AML screening SLA” as its own metric, not buried inside a generic onboarding case's stage history. Risk Assessment qualifies because it can be re-triggered independently (a risk profile can be re-run without re-doing KYC). Onboarding Approval qualifies because approval authority (compliance analyst vs. manager, based on risk tier) is a distinct decision point with its own SLA and its own audit trail. If none of those independent-lifecycle/independent-reporting conditions held, we'd have kept it as stages inside one case — stage-based decomposition is cheaper to build and query than case-based decomposition, so CLSA expects you to justify the split, not default to it.

Primary vs. alternate stages

Customer Onboarding's primary stages are Intake → Verification → Review → Manager Approval → Fulfillment → Completion. Rework and Rejection are modeled as alternate stages, not primary stages with conditional branches. This matters at the rule level: primary stages define the case's canonical stage progression that Pega's reporting layer (case summary, SLA calculations, stage-duration reports) reads by default. If Rejection were a primary stage sitting between Review and Manager Approval, every report grouping by stage would show a confusing, bimodal distribution for a code path that only a minority of cases take. Alternate stages branch off the primary spine without polluting that canonical progression — they're still fully functional flows, just not counted in the “happy path” stage metrics unless you explicitly query for them.

System of Record: Customer and Account → Core Banking

By default, Blueprint marks every Data Object's Integration System as “Pega(Local)” — meaning Pega treats its own class as the authoritative source of truth, and any instance you create via a save is the record. We changed Customer and Account to Core Banking as their System of Record, leaving Application as Pega(Local).

Why: Customer and Account data pre-exist in the bank's core banking platform before Nexus ever sees a case. If Pega treated its local Customer class as authoritative, you'd get two conflicting “truths” — the core banking system's version and Pega's cached/local version — with no defined reconciliation rule, which is a data-integrity bug waiting to happen the first time a customer's address changes in the core system after onboarding. Declaring Core Banking as the SOR tells the Data Object's integration mapping (the connector and mapping rules Pega generates against it) that reads should be treated as a synced projection of an external system, and writes need a defined sync-back path — not a blind local save. Application data (the onboarding case's own risk flags, stage timestamps) is genuinely Pega-native, so Pega(Local) is correct there.

Persona access: least privilege, not default-open

Blueprint's “Generate with AI” access suggestion is a starting point, not a finished access model — it defaults toward giving every persona broad Create/Read/Edit on every case type. We tightened it to a real least-privilege matrix:

Persona	Customer Onboarding	KYC Review	AML Screening	Risk Assessment	Onboarding Approval
Customer	Create/Read/Edit	Read only	Read only	Read only	Read only
Bank Analyst	Create/Read/Edit	Create/Read/Edit	Create/Read/Edit	Create/Read/Edit	Read only
Manager	Read + Edit	Read only	Read only	Read only	Read + Edit

The rule: a persona gets Edit on a case type only if their job function is the one that actually progresses that case type's stages. A Customer never edits their own KYC Review case — they submit documents into Customer Onboarding, and KYC Review is a control activity performed on their application, not by them. A Bank Analyst doesn't get Edit on Onboarding Approval because approval authority is segregated from the analyst who prepared the file — classic segregation-of-duties, which shows up directly on the CLSA Security Design domain.

2. Extend vs. New Application: the mistake, and the rule-resolution mechanics behind it

Pega Infinity offers two entry points for importing a Blueprint into an instance, and they look almost identical in the wizard — same six steps (Case Types → Data Objects → Personas → Features → Review), same “From Blueprint” defaults. But they resolve to fundamentally different outcomes, and the difference isn't cosmetic.

What we did wrong first

We launched the import from inside an existing HR application, via App Studio Home → “Extend your application” → “Import a Blueprint.” We got all the way to the Review step and found every new case class structured as TGB-HRApps-Work-CustomerOnboarding, inheriting from TGB-HRApps-Work — the HR application's own base class.

The Review step in that flow has no Organization / Division / Application fields to override this. That's not a UI limitation to work around; it's the correct behavior of an extend operation, and here's why.

Why “Extend” can never produce a different base class

Every Pega application is defined by an Application rule, which carries an ordered ruleset list — the prerequisite chain Pega's rule-resolution algorithm walks when it looks up a rule by name. When you launch “Extend your application” from inside an existing app, Pega isn't creating a new Application rule; it's adding case types and data classes as new rules within that application's existing ruleset list, rooted at its existing base class. The wizard's settings in this flow are about ruleset/version placement within that existing hierarchy — not about choosing a different Organization or Application, because there isn't a new Application rule being created at all. Structurally, extending is closer to “add rules to this codebase” than “start a new codebase.” Asking it for a different base class is like asking a commit to also change which repository it's committing to.

This is precisely the distinction CLSA's Application Design domain probes: knowing when a request is really “add capability to an existing application” (Extend) versus “stand up a new, independently-versioned application” (New Application) — and knowing that the wizard entry point you choose is that architectural decision, not a formatting preference.

The correct entry point

The real fix was the Application menu — the small icon beside the current application's name in the top header (easy to miss at narrower browser widths) — which opens a context menu: Overview, Settings, Switch Application, Create new Application from Blueprint, Extend this Application with Blueprint.

Choosing “Create new Application from Blueprint” starts a genuinely new Application rule from scratch, which is why that wizard's Review step has real Organization name / Division name / Unit name / Class layer fields — those fields exist because a new ruleset list and a new base class are actually being minted, not because someone remembered to add a form field.

3. Class layers: how “Alpha” + “Nexus” become a class hierarchy

Starting over through the correct entry point, the “Build from a Blueprint” wizard's Application Settings tab let us set the Application name to Nexus, with the built-on application correctly auto-resolved to CLM for Financial Services – CIB (more on why that matters in the next section):

On the Review step, we set Organization name to Alpha, Division to RetailBanking, and Unit to Onboarding:

The “Class layers” section directly beneath it auto-derived an organization class prefix of Alph from the Organization name we typed, and used “Nexus” verbatim as the Application layer, with “Work” as the class group name:

That combination is exactly how Pega's class-naming convention works: <Org-prefix>-<Application>-<ClassGroup>[-<Type>]. The org prefix is deliberately truncated (Pega defaults to the first four or five characters, and it's editable) because it becomes part of every single rule's class name across the entire application — short prefixes keep rule names and ruleset names manageable at scale.

Scrolling down to the actual Case classes list confirmed the fix: every case type now inherits directly from Pega's own case base class, not from any HR-application ancestor:

Every case class inherits directly from Work-Cover-, Pega's own built-in case-management base class. That's the structural signature of a correctly-scoped new application: your application's base class (Alph-Nexus-Work) is a direct child of the platform, and every case type is a child of that. Compare this to what the Extend flow would have produced: TGB-HRApps-Work-CustomerOnboarding inheriting from TGB-HRApps-Work, which itself sits inside the HR application's own ruleset list — meaning every rule resolution for a Nexus case would have had to walk through the HR application's rulesets as ancestors, coupling two unrelated business domains at the class-inheritance level. That coupling is invisible in the UI until someone tries to version, package, or independently deploy one of the two applications and discovers they can't cleanly separate them.

This is why CLSA's Application Design domain weights class-structure decisions so heavily: a wrong inheritance root doesn't throw an error at build time — it silently creates a maintenance and deployment liability that only surfaces months later.

4. “Built-on application”: what the warning actually meant

Both times we ran the wizard, the Features step showed a banner: “The selected Blueprint was created for use with PegaCLMFSCIB. The chosen built-on Application does not match, which may result in missing functionality.” In the Extend flow, that warning had a real, measurable consequence: the Features step literally said the Blueprint's Features would not be included “due to changes made to the underlying Application selected” — and Entity Verification, PEP/Sanctions Screening, and the Agentic AI (Intelligent Document Processing) features were silently absent from the list entirely, not just greyed out.

What “built-on application” configures, mechanically: an application built “on” another application means the child Application rule's ruleset list includes the parent's rulesets as prerequisites — the child inherits every rule the parent defines (flows, decision rules, integrations, harnesses) and can override any of them. Blueprint's Retail Banking Customer Onboarding design was authored assuming it would sit on top of PegaCLMFSCIB (Pega's own CLM for Financial Services – CIB accelerator), which already ships pre-built rules for exactly the features the Blueprint's business description implies: entity verification, PEP/sanctions/adverse-media screening, and GenAI document-processing agentic flows. The HR application was built on a completely different accelerator lineage, so when we extended from inside it, Pega had no matching rulesets in the prerequisite chain to attach those Feature rules to — they had nowhere to resolve, so the import silently dropped them rather than fail the whole build.

When we instead created Nexus as a genuinely new application, the wizard's “Built-on application” field auto-populated with CLM for Financial Services – CIB — correctly inferred from the Blueprint's own metadata — and the mismatch banner disappeared. The Features step then showed the real feature catalog:

Entity Verification, PEP/Sanctions/Adverse Media Screening, Intelligent Document Processing, Customer Summary, Risk Overview, Document Requirements Optimization — each individually toggleable Enabled/Disabled, exactly the capability the business description called for.

The CLSA-relevant takeaway: “built-on application” isn't a checkbox for turning on extra sample content — it's how you deliberately compose ruleset inheritance across applications so you're not re-authoring integrations and decision logic another application (or Pega itself, via an accelerator) has already built and licensed. Getting it wrong doesn't throw a validation error; it silently produces an application that's missing capability the business asked for, discoverable only by someone who happens to compare the Blueprint's stated scope against what actually got built.

5. Data Model: what “System of Record” changes under the hood

In Blueprint's Data Object editor, each Data Object has an Integration System dropdown, with options including To Be Determined, Pega(Local), and named external systems like Core Banking. This single dropdown answers a question every CLSA candidate has to answer for every entity in a Data Model: where does this data actually live, and who's allowed to say what its current value is?

When a Data Object is left as Pega(Local), the build engine treats the corresponding class as a plain Pega data class: instances are created and updated with a straightforward local save, there's no assumption of an external counterpart, and the class is the sole source of truth. That's correct for Application — the onboarding case's own risk flags, review outcomes, and workflow-local state exist only inside Pega; there's no “real” copy of that data anywhere else to reconcile against.

When we set Customer and Account to Core Banking, we told the Data Object generation to treat the class as a client-side representation of an external system of record. Concretely, this shapes what Pega scaffolds for you: the generated Data Object gets built with an expectation of a connector (a data page sourced by an external API) rather than a local-only instance list, and the class carries integration metadata that downstream tools can use to know they're looking at synced, not authoritative, data. The associated “Resource” picker was empty at Blueprint design time — that's expected; Blueprint records the architectural intent (this class is SOR-external), and the actual connector rule gets built or configured later, against the bank's real Core Banking API.

Why this matters beyond “which dropdown to pick”: if you leave Customer as Pega(Local) by oversight, every developer who comes after you will build features assuming a save on a Customer instance is authoritative — and the first time the core banking system updates a customer's address independently, Pega's copy silently goes stale with zero indication anything's wrong. CLSA's Data Model domain (and Integration domain, since SOR declarations are the seam between them) expects you to make this call explicitly and early, because retrofitting it after a dozen rules assume local authority is expensive rework, not a config flag flip.

6. Security architecture: from Persona to real access control

A Blueprint Persona (Customer, Bank Analyst, Manager) is a design-time abstraction — it doesn't exist as a runtime security object. The Case Access matrix we configured per persona is the input; what the build engine actually produces at import time is the real Pega security chain: Access Group → Access Role → Privilege, wired to case-type-level ACLs.

When the build completed, we landed in Nexus under an access group named following the convention <Application>:<AccessRole> — exactly how Pega access groups are conventionally named so their scope is legible from the name alone. Behind that access group sits an Access Group rule that references one or more Access Role Name rules, and those Access Role Names carry the actual Privileges that gate rule execution (a flow action, a case-type Create/Read/Edit, a report definition). The Case Access checkboxes we set per persona in Blueprint are the seed that generates the corresponding Access-Role-to-case-type privilege grants once the case types actually exist as real classes — there's no case-type privilege to grant until the class is built, which is part of why this whole security shape only becomes concrete after the build, not during Blueprint design.

The least-privilege matrix from section 1 maps directly onto this: Customer's access role gets Create/Read/Edit privileges scoped only to the Customer Onboarding case class, and Read-only privileges on the other four case classes. Bank Analyst's access role gets broader Create/Read/Edit across the operational case types but explicitly withholds Edit on Onboarding Approval — that's a privilege that's absent, not merely hidden behind a UI restriction, which is the difference between real security enforcement and cosmetic UI hiding. This distinction — access enforced at the rule-resolution/privilege layer versus access merely hidden in a portal harness — is a classic CLSA trap: a well-designed harness that hides a button from a Bank Analyst is a UX nicety; the actual security boundary is the missing privilege on the Access Role, which stops the action even if someone hits the API directly, bypassing the UI entirely.

7. What the build engine actually did, rule by rule

Watching the “Pega is creating your application” progress log is a genuinely useful way to internalize what a case-type build is, mechanically, rather than treating it as a black box:

Build phase	What it creates
Preparing base Application assets	The Application rule itself; the Alph-Nexus-Work base class; the initial ruleset and ruleset version
Building Case Types (×5)	One work class per case type, its starting stage/process flow, its case-wide fields
Building Data Objects (×3)	Customer, Account, Application as real classes with their property definitions
Building Embed Objects	Identity Document, Risk Profile, Screening Result as embedded page / page-list classes, not top-level classes
Preparing Fields for Case Types / Data Objects / Embed Objects	The actual property rules and their auto-generated capture views
Building Application Data Model	The overall schema graph tying case classes to their referenced data classes, exposed for reporting

By the time the build reached roughly two-thirds complete (all five case types and the three primary Data Objects finished), we'd already crossed 395 rules created — a useful gut-check figure for CLSA candidates estimating build effort: a modest five-case-type application with three core data entities and four embedded objects is not a small rule count once you account for every property, every auto-generated capture view, and every flow action underneath the case lifecycle.

The build finished cleanly:

A walk through Dev Studio's class explorer confirmed the corrected hierarchy end to end — base class Alph-Nexus-Work with all five case classes nested underneath it, completely independent of the original HR application (see the class explorer screenshot at the top of this post).

This is exactly why Blueprint's value proposition (and Pega's broader low-code pitch) is scaffolding that volume of boilerplate correctly on the first pass — and exactly why reviewing its output before accepting it (sections 1 and 4 above) matters more, not less, as that scaffolded volume grows.

8. The 11 warnings we're carrying forward

The Review step's “View Warnings” panel surfaced the same 11 issues in both the failed Extend attempt and the successful New Application build — confirming these are Blueprint-generation defects, not artifacts of which wizard path we used:

Decision Table	Reason
Decision Routing	Unsupported comparator type for its columns, under the Blueprint import module version in use
Identify Gaps (×2 instances)	Malformed: row column count doesn't match header column count
Flag High-Risk	Malformed: row column count doesn't match header column count
Flag Suspicious	Malformed: row column count doesn't match header column count

At the rule level, a Decision Table is a grid where each column after the conditions is a header-defined field, and every row must supply exactly that many values — it's structurally a fixed-width table, not a sparse one. Blueprint's GenAI generation produces these tables from natural-language business rules (“flag as high-risk if screening result is Positive AND risk score exceeds threshold”), and when the generated condition logic uses a comparator the import module doesn't yet support (a range test, a list-membership test), or when the AI-authored rows don't perfectly match the AI-authored header it just wrote, the table imports as damaged metadata rather than failing the whole build. (This is a limitation of the Blueprint import tooling at the version we used — it may well improve in later releases, so don't treat the specific defect count as a permanent ceiling.)

The fix is manual, in Dev Studio, post-import: open each flagged Decision Table, reconcile the row/column counts against the headers (or rebuild the table from the business rule description), and replace any unsupported comparator with an equivalent supported one (typically decomposing a range comparator into two explicit conditions). This is intentionally left as a to-do rather than something to chase down mid-build, because Blueprint's checker already told us these are non-blocking to the case/data/persona structure — the case types, stages, and flows all function without these five decision tables; they're a refinement layer (automated risk flagging) sitting on top of a structurally sound application, which is exactly the kind of prioritization judgment CLSA expects: ship the sound skeleton, then iterate the decisioning logic, rather than blocking the whole application on GenAI output that needs a human pass.

9. Mapping this exercise to CLSA exam domains

CLSA domain	What this session covered
Application Design	Case decomposition rationale; Extend vs. New Application as an architectural decision, not a UI choice; class-layer/ruleset structure and org-prefix naming
Data Model	System of Record declaration and its effect on Data Object generation and integration assumptions
Security Design	Least-privilege persona access matrix and its realization as Access Group / Access Role / Privilege
Integration Design	Built-on application as a ruleset-prerequisite mechanism for inheriting pre-built integrations rather than re-authoring them
Platform Design / Enterprise Class Structure	Why a base class inheriting directly from Pega's own case base is the correct signature of a cleanly separated application, versus the coupling risk of inheriting through another application's base class

The throughline across all five: almost none of these are Pega “features” you memorize as menu paths. They're architectural decisions the tooling exposes through menu paths, and the exam — and real production work — rewards understanding the decision, not the click sequence.

What's next: rebuilding the five flagged Decision Tables directly in Dev Studio, verifying the generated Access Role privilege grants against the intended matrix rather than assuming a 1:1 mapping, wiring the real Core Banking connector, and moving into Constellation and the DX API next in this series — specifically how the case-type and data-class design choices made here surface (or don't) through the DX API to a headless front end.

Take the quiz: Nexus Blueprint architecture (CLSA level)

Six questions on the architectural decisions covered in this post, not click-paths - the reasoning behind them.