The four stages of authoring in Blueprint Delivered
The Authoring phase follows a structured, outcome-driven sequence built around one organizing principle: a bias toward working software. Rather than treating Authoring as a single event or a free-form build, Blueprint Delivered™ defines four discrete, sequential stages. Each stage builds on the last, and each produces an outcome in Pega Blueprint™ that the team can test, demonstrate, and validate. This is not a sequence to observe loosely; it is a discipline. The biggest anti-pattern in Authoring is abandoning the Blueprint after import and rebuilding from scratch in App Studio. The four stages exist precisely to prevent that
The core mindset that drives the entire sequence is straightforward:
- Treat the Blueprint as the source of truth.
- Do not start from a blank slate or reimagine the application.
- Maintain a bias toward working software at every stage.
Stage 1: Foundation (import and validation)
The Foundation stage transforms the Blueprint into a working application. The team imports core assets, including Case Types, Data Models, and Personas, and then validates them against the Blueprint preview to confirm accuracy and completeness. The goal is a clean, stable baseline from which all subsequent development runs.
Tip: Set up CI/CD pipelines before import begins. This is not a nice-to-have. The import branch must be mergeable from day one so that the team can establish a clean, verified baseline. Delaying CI/CD setup creates a dependency that blocks every feature branch that follows.
Stage 2: Security and data integration
The second stage activates real users and real data as early in delivery as possible. The team configures secure access, both authentication and authorization, and connects external data sources so that cases can run with live information. Prioritizing security and data integration at this stage is a deliberate choice that lets practitioners and stakeholders work with realistic conditions instead of sample data, which surfaces integration issues early when they are least costly to resolve. Validating a Case Type that runs with real Persona data and real records is fundamentally different from validating one that runs on placeholders.
Stage 3: Case and usability configuration
Stage 3 focuses on the user experience and Case Management elements that the Blueprint does not yet automate. Critically, the team drives these refinements from actual usage and feedback gathered in a live environment, not from assumptions made during design. This feedback loop keeps the application evolving in response to real behavior rather than theoretical requirements. When Stage 3 reveals that the team must significantly modify key Blueprint-generated components, that signals a Blueprint fidelity issue upstream, not a configuration problem downstream.
Tip: Refine what Blueprint cannot model. The Blueprint captures business intent, but some details can only be configured once the application is real and running.
Stage 4: Automation and integration
The final stage layers advanced business logic, decision logic, and complex integrations onto the stable foundation that Stages 1 through 3 establish. The team delivers these capabilities incrementally to keep the application operational and testable at all times. Deferring complexity to this stage helps delivery teams avoid building sophisticated logic on an unstable or unvalidated base.
Because the team sequences and gates every stage, the build is fully traceable. The team can see exactly what was built, when, and why. That traceability is a differentiator when AI-generated output is otherwise ungoverned.
The leadership shift
The Blueprinting phase belongs to the Solution Designer. The Solution Designer leads discovery, value framing, the high-fidelity Blueprint, Data Model identification, and stakeholder feasibility. The Solution Builder participates in a supporting role: scanning for reuse opportunities, flagging integration constraints, and contributing to estimations.
When Authoring begins, leadership shifts. The Solution Builder now leads. The mandate changes from designing the right thing to building the thing right. The Solution Designer remains in the process, but the role shifts from directing to supporting. In Authoring, the Builder leads import decisions (inherit, reuse, or new), implementation tasks, CI/CD, and testing and quality. Designers support with backlog refinement, scope trade-offs, and guardrails to protect value.
Why this sequence matters
The four-stage model reflects a core delivery truth: working software is the measure of progress. Each stage produces something testable and demonstrable, which maintains momentum and stakeholder confidence throughout the engagement. Teams that skip the sequence or collapse stages lose that signal and typically discover the loss too late.
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?