Confirm that the agreed outcome remains recognizable

Before assessing fidelity, create an import decision trace for each item supporting the outcome. This makes the expected consequences of import choices visible before differences are classified as design or implementation issues.

Use the trace to separate expected import results from differences that require Authoring, business-design review, or joint evaluation.

After the trace identifies the expected import effects, use this review to confirm what the resulting application foundation now contains and what still needs evaluation.

Establish whether the combination of Blueprint design and import decisions produced a coherent foundation for the agreed outcome. A difference from Blueprint Preview may be an expected result of using established capability or inheritance, an implementation refinement, a business-design change, or a question requiring joint evaluation. Differences may also result from new feature support in Blueprint that is not yet recognized by the import module, requiring configuration in Pega Infinity Studio™.

In the U+ Travel scenario, the Solution Designer and Solution Builder run Tour Booking from its starting event through the imported Case journey. They first confirm that the working application tells the agreed business story before reviewing individual refinements.

As they review the running Case, they confirm that the Tour Booking outcome, meaningful progression, required data and information, participant responsibilities, and connected Case, Decision, integration, and access relationships remain recognizable.

Authoring can refine interactions, connect live integration data, and complete advanced logic. The validated outcome and its supporting rationale provide the reference for that work.

The following figure shows the transition from a validated outcome to a refined and complete application foundation through iterative authoring and implementation activities:

Fidelity transfer is the preservation of business meaning from Blueprint into the working application. It is a business-design judgment:

The Solution Designer helps determine whether the application continues to express the outcome, data and information meaning, Decisions, participant responsibilities, results, relationships, and Workflow progression established in Blueprint.

For U+ Travel, Determine Tour Viability provides a meaningful thread for evaluating that transfer. The Decision exists to establish whether a tour can proceed using the agreed weather, tide, tour, and participant information. Following that thread across the application shows whether the connected design has become coherent behavior.

This review goes beyond confirming that a Decision Step, Business Rule, Data Object, or View exists. It evaluates whether purpose, data, information, policy, participation, results, and progression work together to support the outcome.

The Blueprint establishes what the application needs to achieve. Pega Infinity can express that intent through richer implementation patterns. Authoring increases implementation fidelity while preserving the validated business design.

A richer View, clearer Field presentation, or more suitable interaction pattern can be an implementation refinement. A different outcome, changed policy, new participant responsibility, altered information meaning, or new Workflow path represents a business-design decision.

When the working application differs from the validated design, the team needs to determine what that difference represents and how it should be addressed. Use the table below to determine whether the difference is an implementation refinement, a business-design change, or a question requiring further evaluation:

A difference discovered during Authoring can lead to one of three responses, each directing the team toward a different course of action. The Solution Designer determines whether the observed difference changes the agreed business design, while the Solution Builder evaluates the technical response. Use the following examples to determine where each difference should be addressed:

The Solution Designer contributes judgment about the outcome, policy, information meaning, participant need, and stakeholder expectation. The Solution Builder evaluates the technical and architectural response.

Import establishes the beginning of a working application and continued design collaboration. As Authoring introduces real users, meaningful data, refined Case behavior, automation, and integrations, the working application continues to evolve. The team continues to evaluate that application against the business intent represented in Blueprint. 

Import also provides a starting body of Authoring work. Known future work should retain enough context to explain its purpose and expected result. Notes and descriptions in Blueprint allow refinement to begin from validated intent rather than recreating requirements from a blank backlog. 

Simple implementation refinements can progress through live collaboration where the expected result is clear and business intent remains stable. More significant questions return to the relevant design conversation. Validated business changes are reflected in Blueprint so that the design and working application continue to tell the same story. 

Alignment keeps the outcome, business policy, information meaning, participant responsibilities, and stakeholder expectations recognizable as implementation fidelity increases, while allowing generated details to be refined.  

The following figure shows an iterative design and implementation approach that preserves alignment between Blueprint intent and the evolving application foundation:

Evaluate the working application against the validated business design by asking: 

• Is the business outcome recognizable from start to result? 
• Do the required information, policy, participation, and progression work together? 
• Did import and reuse decisions create the intended relationships? 
• Which differences are implementation refinements? 
• Which differences change approved intent? 
• Which differences require joint evaluation? 
• Are validated business changes visible in Blueprint? 

Confirm that the running Case preserves the validated outcome, then follow a meaningful business thread to evaluate whether its purpose, data, information, policy, participation, results, relationships, and Workflow progression remain coherent. When differences emerge, determine whether they reflect the expected import choice, an implementation refinement, a business-design change, or a question requiring joint evaluation.

Carrying the outcome into Authoring means evaluating more than whether Blueprint elements were generated. Follow a meaningful business thread through the running application and confirm that purpose, information, policy, participation, recognized results, and progression still support the validated outcome. 

When Authoring reveals a difference, determine whether it changes business intent, improves implementation expression, or exposes a question requiring joint evaluation. This judgment allows the team to refine the working application while keeping Blueprint and the delivered outcome aligned. 

Blueprint import brings validated business design and implementation decisions together. Experienced Solution Designers consider what the Solution Builder needs to decide, identify the connected design required for the next outcome, and make the business rationale clear enough to inform those decisions. 

Designing for reuse extends the value of that work by locating shared business value at the appropriate level and preserving the variation each outcome needs. After import, the Solution Designer follows the validated outcome into the running application, distinguishes business intent from implementation refinement, and helps keep Blueprint and the working solution aligned through Authoring.