AI-Based Report Definition Performance Analyzer using GenAI Connect

Hi everyone,

I wanted to share an approach I recently implemented to proactively identify performance risks in Report Definitions using GenAI in Pega.

In most projects, Report Definitions are created primarily to meet functional needs, but performance considerations such as join complexity, filter usage, and data access patterns are often not evaluated during development. These issues usually surface later during testing or production.

To address this, I built a small utility-driven solution that analyzes Report Definitions and provides an LSA-style performance assessment.

Implementation Overview:

  1. Fetching Report Definitions

    • Built a utility (Activity) to retrieve all instances of Rule-Obj-Report-Definition

    • Filtered based on ruleset/application context

    • Iterated through each RD for analysis

  2. Metadata Extraction
    For each Report Definition, extracted key attributes such as:

    • .pyRuleName (Report Name)

    • .pyClassName (Applies-To Class)

    • Join count

    • Filter count

    • Associations and sub-reports

    • (Optionally) index awareness

  3. Dynamic Input Construction

    • Constructed a structured string using Property-Set:

      Report Number - X 
      Report Name - <name> 
      Report Class - <class> 
      Filter Count - <n> 
      Join Count - <n>
      
      
  4. GenAI Integration

    • Used GenAI Connect to pass the constructed input

    • System prompt designed to behave like a Pega LSA

    • Enforced strict output format:

      Risk Assessment: <LOW/MEDIUM/HIGH> | Reason: <...> | Fix: <...>
      
      
    • Limited response to ~200 characters for UI readability

  5. Evaluation Logic (via AI prompt)
    The analysis is based on common performance heuristics:

    • Join count > 3 → High risk

    • No filters → Full table scan risk

    • Combination of high joins + no filters → Critical

    • Consideration of overall structure and data volume

  6. Result Persistence

    • Stored output along with RD metadata in a database table

    • Enables tracking, reporting, and future dashboarding

Sample Output:

Risk Assessment: HIGH RISK | Reason: No filters and high joins causing full table scan | Fix: Add indexed filters and reduce joins

Key Learnings:

  • Many RD performance issues are design-related rather than infrastructure-related

  • Simple heuristics (joins + filters) can identify a majority of risks

  • GenAI works best when:

    • input is clearly structured

    • output is tightly controlled

  • This approach helps bridge the gap between development and LSA-level performance thinking

Next Steps / Enhancements:

  • Introduce risk scoring (0–10 scale)

  • Build a dashboard for high-risk RDs

  • Integrate with PDC for runtime validation

  • Extend analysis to Data Pages and data access patterns

RD Risk Intelligence AI.docx (17.8 KB)

Techinical Doc- RD Risk Intelligence AI.docx (541.9 KB)

Hello Pooja,

Nice approach to use gen ai for rule analysis based on the design time aspects. This clearly proves Pega gaurdrails engine has huge potential in analysing and suggesting improvements and enforce governance on regular basis across ruletypes. But for this particular scenario I feel, Pega alert analysis using genai might be even more fruitful and realistic. For eg., some of the RDs without filters may perform better than some RDs with one filter which is on a bigger table. So inclining more towards the Pega alerts would be more accurate. You mentioned PDC in next steps which makes perfect sense. Nevertheless love the creativity here on using genai for rule analysis. Thanks for sharing.

Thanks for sharing this — it’s a strong example of design‑time AI applied responsibly.

What works particularly well here is that:

  • The input is structured

  • The output is constrained

  • The AI is advising, not enforcing

You are also right to call out that heuristics alone are not enough, and your note about integrating with PDC and alerts is important. Runtime evidence should always complement design‑time analysis.

This pattern aligns well with how Pega positions GenAI: augment expert judgment, not replace it. I’d be interested to hear how others balance design‑time heuristics with runtime telemetry when using GenAI for quality or performance analysis.