Infrastructure teams are increasingly using Infrastructure-as-Code to define, review, and deploy cloud resources. Terraform makes infrastructure repeatable and version-controlled, but compliance review often still depends on manual checks, late-stage audit activity, or reviewer experience. That creates a gap between how fast infrastructure code moves and how quickly teams can validate security and compliance expectations.

This automation initiative was built to close that gap. The objective was to automate Terraform compliance review during the Azure DevOps pull request process, before code is merged or deployed. The result is a working shift-left audit flow that detects changed Terraform files, audits the content, maps findings to CIS and SOC2 context, uses AI to express the finding clearly, and sends PASS, FAIL, or SKIPPED notifications to reviewers.

Why This Automation Was Needed

In a traditional process, infrastructure code is written, reviewed, merged, and deployed before deeper compliance issues are discovered. A reviewer may catch obvious mistakes during pull request review, but detailed compliance checks are hard to perform manually. This becomes even more difficult when a pull request contains multiple Terraform files or mixed changes such as README files, YAML files, scripts, and infrastructure code.

The risk is both technical and operational. A small Terraform setting can become a security or audit finding if it violates a control expectation. If this is discovered after merge or deployment, the team must revisit the code, redeploy the infrastructure, and manually collect evidence. The automation solution was designed around a simple question: can we give reviewers meaningful compliance feedback while the pull request is still open?

The Logic Behind the Automation Flow

The logic behind the automation solution is intentionally simple: treat every infrastructure pull request as an opportunity to validate compliance before risk enters the environment. The workflow does not try to audit everything blindly. It first understands what changed, filters only relevant Terraform files, and then audits the actual Terraform content from the pull request commit.

This makes the workflow practical. If a pull request has only documentation changes, the audit is skipped. If the pull request has Terraform files, the workflow processes each file. If one file fails and another passes, the result is aggregated into one pull-request-level decision. This keeps the result easy for reviewers to understand.

Trigger → Validate → Execute → Decide → Notify

The trigger is the Azure DevOps pull request event. The validation step checks changed files and keeps only Terraform content. The execution step sends Terraform content to the audit backend. The decision step determines PASS, FAIL, or SKIPPED. The notification step sends a clean email to reviewers with the result and context.

Where AI and RAG Add Value

The most important part of this automation solution is not only automation. The value increases when automation is combined with RAG and AI. Traditional automation can tell whether a rule passed or failed. RAG and AI help explain why the result matters and turn raw compliance checks into readable, evidence-backed findings.

RAG, or Retrieval-Augmented Generation, is used to bring relevant compliance knowledge into the audit process. Instead of asking the AI model to answer from general knowledge, the workflow retrieves related CIS and SOC2 context from a knowledge store. This allows the audit response to be grounded in the controls that matter for the resource being reviewed.

AI then uses the Terraform configuration and retrieved compliance context to generate a structured finding. For example, if a storage account does not enforce HTTPS-only traffic, the AI-assisted finding can explain the failed setting, the current value, the expected value, the risk, and the relevant CIS/SOC2 mapping. This makes the output easier for both engineers and reviewers to act on.

• RAG improves context by retrieving relevant CIS and SOC2 control information.
• AI improves readability by converting raw audit results into clear findings.
• The combined approach helps produce evidence-backed, reviewer-friendly notifications.

AI/RAG Request and Response Flow

The backend does not send only raw Terraform code to the language model. It builds a controlled audit context that includes the resource configuration, the applicable CIS rule, the mapped SOC2 controls, and strict output instructions. This keeps the AI response grounded in known compliance evidence instead of open-ended reasoning.

Backend request context sent to the AI model

• Role: act as a SOC2 and CIS Azure compliance auditor.
• Strict rules: use only provided CIS rules, do not invent control IDs, use severity from metadata, and return valid JSON.
• Resource: azurerm_storage_account.bad_storage with enable_https_traffic_only set to false.
• Applicable CIS rule: cis-3.1 expects enable_https_traffic_only to be true and marks severity as HIGH.
• Mapped SOC2 controls: soc2-CC6.6 and soc2-CC6.7 for logical access and security controls.

Compact prompt context

RESOURCE: azurerm_storage_account.bad_storage

CONFIG: enable_https_traffic_only = false

CIS RULE: cis-3.1 | expected_value = true | severity = HIGH

SOC2: soc2-CC6.6, soc2-CC6.7

TASK: Evaluate resource against provided CIS rules only.

OUTPUT: JSON with resource, findings, status, risk, current_value, expected_value, overall_risk.

AI-generated audit response

The AI model returns a structured finding that the backend can parse and pass back to n8n. The result is not free-form text; it is a predictable JSON response that supports aggregation, branching, and notification formatting.

{

  "resource": "bad_storage",

  "resource_type": "azurerm_storage_account",

  "findings": [

    {

      "cis_id": "cis-3.1",

      "soc2_controls": ["soc2-CC6.6", "soc2-CC6.7"],

      "status": "FAIL",

      "finding": "Storage account does not enforce HTTPS traffic only",

      "risk": "Unencrypted HTTP traffic allows potential interception and unauthorized access to storage account data in transit",

      "attribute": "enable_https_traffic_only",

      "current_value": "false",

      "expected_value": "true"

    }

  ],

  "overall_risk": "HIGH"

}

This design is important because the AI is used as an audit reasoning layer, while the backend still controls the source of truth. The CIS and SOC2 context is retrieved first, then the model explains the finding using only the provided rules and controls.

Representative Backend Structure

The backend is structured as a small audit service. The exact folder names can evolve, but the separation of responsibility keeps the system easier to maintain and extend.

backend/

├─ app/

│  ├─ api/

│  │  └─ api.py                  # FastAPI routes for health, ingestion, retrieval, and audit endpoints

│  ├─ parsers/

│  │  └─ terraform_parser.py     # Extracts Terraform resources and attributes from .tf content

│  ├─ services/

│  │  └─ audit_service.py        # Orchestrates parsing, retrieval, AI request, and final audit response

│  ├─ rag/

│  │  └─ retriever.py            # Retrieves relevant CIS and SOC2 context from the vector store

│  ├─ llm/

│  │  └─ claude_client.py        # Sends controlled audit prompt to the LLM and receives JSON findings

│  ├─ ingest/

│  │  ├─ cis_loader.py           # Loads CIS rules into the knowledge base

│  │  └─ soc2_loader.py          # Loads SOC2 controls into the knowledge base

│  └─ models/

│     └─ schemas.py              # Defines request/response models for API contracts

├─ data/                         # Sample CIS and SOC2 source files

├─ chroma_db/                    # Local vector store persistence

├─ tests/tf_samples/             # Terraform examples used for validation

└─ requirements.txt              # Python dependencies

In this structure, FastAPI exposes the service, the parser understands Terraform, the retriever brings compliance evidence, the LLM client generates structured findings, and the audit service ties everything together into one response.

Where n8n Fits in the Automation Flow

n8n is the workflow automation layer in this automation solution. It does not replace Azure DevOps, FastAPI, or the AI layer. Instead, n8n connects these systems and controls the end-to-end sequence from pull request trigger to audit notification.

The main value of n8n is orchestration. It receives the Azure DevOps PR event, extracts metadata, calls Azure DevOps APIs, applies conditions, loops through Terraform files, calls the audit backend, aggregates the results, and sends the final email notification. This makes the process easier to visualize, modify, and extend without hard-coding every integration into one application.

In the workflow, n8n also acts as the decision engine. If no Terraform files are found, n8n sends a SKIPPED notification. If the audit backend returns high-risk findings, n8n sends a FAILED notification. If the audit passes, n8n sends a PASSED notification. This branching logic turns raw automation into a usable audit process.

• Receives Azure DevOps PR events through a webhook.
• Filters changed files and selects only Terraform .tf files.
• Loops through one or many Terraform files in a PR.
• Calls FastAPI to audit Terraform content.
• Aggregates file-level findings into one PR-level result.
• Sends a clear email notification to reviewers.

How the Automation Solution Works

The automation solution connects several components into one automated flow. Azure DevOps provides the source repository and pulls request event. n8n receives the event and manages the workflow. FastAPI receives Terraform content and performs the audit logic. ChromaDB and RAG provide compliance context from CIS and SOC2 controls. Claude helps generate structured audit findings. The final result is delivered by email.

The workflow audits the actual Terraform content from the pull request commit, not a stale local file. This is important because the audit result should reflect the exact code being reviewed. The workflow also supports multiple Terraform files in one pull request, which makes it useful for realistic infrastructure changes.

Key n8n Workflow Logic

The key workflow is the Azure DevOps PR Terraform Audit workflow. It receives a pull request event, extracts metadata, gets changed files, filters only .tf files, fetches file content, calls the audit backend, aggregates results, and sends the final notification.

• No Terraform files changed: send a SKIPPED notification.
• One or more compliance findings detected: send a FAILED notification.
• Terraform files audited with no high-risk finding: send a PASSED notification.

What the Automation Successfully Demonstrated

The completed automation solution validated the end-to-end automation path. Azure DevOps PR events successfully triggered the n8n workflow. n8n identified changed files, filtered Terraform files, ignored non-Terraform changes, and handled multiple Terraform files in the same pull request. The FastAPI backend audited Terraform content and returned structured results. The workflow generated professional email notifications for PASS, FAIL, and SKIPPED outcomes.

The strongest scenario was a mixed pull request with one failing Terraform file, one passing Terraform file, and one README change. The workflow ignored the README file, audited both Terraform files, detected the failing resource, and generated one pull-request-level result. This proved the automation solution could support realistic review scenarios rather than only a simple single-file example.

Business and Engineering Benefits

The main benefit of the automation solution is earlier feedback. Reviewers can see compliance issues before code is merged, which reduces the chance of deploying non-compliant infrastructure. It also reduces manual review effort by automating repetitive checks and surfacing only the relevant findings.

• Reduces late-stage compliance rework by checking Terraform during pull request review.
• Improves consistency by applying the same audit logic across pull requests.
• Provides evidence-backed findings using CIS and SOC2 context.
• Uses AI to make audit results easier to understand and act on.
• Supports realistic pull requests with multiple Terraform files and mixed file types.
• Creates a reusable automation model for broader SDLC workflows.

Beyond Terraform Compliance

Although this automation solution focused on Terraform audit, the automation pattern is reusable. The same model can support automated testing, deployment validation, security checks, PR quality gates, release approvals, audit evidence reporting, and team notifications. The real value is the pattern: integrate triggers, validation, execution, decisioning, and notification into a repeatable workflow.

As a next step, this automation solution can be extended by adding a full CIS Azure Benchmark dataset, broader SOC2 control mappings, Azure DevOps PR comments, merge gates, remediation suggestions, and a reporting dashboard. The AI and RAG layer can also be improved over time by adding richer compliance knowledge, historical findings, internal standards, and remediation guidance.

Conclusion

This automation solution shows that infrastructure compliance does not need to remain a manual or post-deployment activity. By combining Azure DevOps, n8n, FastAPI, RAG, CIS/SOC2 context, AI reasoning, and email notification, compliance feedback can be delivered earlier and in a format that reviewers can act on quickly.

The result is a practical shift-left audit flow: faster feedback, reduced manual effort, better audit readiness, and a reusable automation foundation for modern DevOps and cloud governance. Most importantly, the use of RAG and AI turns compliance automation from a simple rule-checking process into an intelligent, contextual, and reviewer-friendly experience.

The post Shift-Left Infrastructure Compliance Automation appeared first on Perficient Blogs.

The Problem Nobody Talks About

Your organization has rolled out a new AI assistant. Your team is excited. Someone asks it, “What is our leave policy?”. It responds quickly and confidently, but the answer misses the mark.

This does not mean the model is broken. It means the model only knows what it has been trained on and what information it can access at the moment of the request.

LLMs are trained on broad data sources up to a cutoff date. Unless they are connected to your enterprise content, they do not know your internal systems, policies, documents, or processes.

Think about everything an LLM may not know about your company:

• Your SharePoint intranet and HR policies
• Your product documentation and release notes
• Your Jira tickets and project history
• Your internal PDFs, SOPs, and compliance documents
• Any update that happened after the model’s training cutoff

For consumer chatbots, this may not matter as much. For enterprise AI, it creates a clear need for trusted, company-specific context.

Enter RAG: Retrieval-Augmented Generation

RAG is the architecture pattern that solves this problem. The name tells you exactly what it does:

Retrieval — Search your private enterprise knowledge base to find relevant content.

Augmented — Add that content as context to the LLM’s prompt.

Generation — Let the LLM generate an answer grounded in YOUR data.

Instead of relying solely on what the model was trained on, RAG dynamically fetches the right information at query time and hands it to the LLM. The result: accurate, current, enterprise-aware answers.

RAG is not a product. It is an architecture pattern. It works with GPT-4, Claude, Llama, and virtually any LLM.

A Simple Analogy

Imagine hiring a brilliant consultant who has read every book ever published but has never worked at your company. If you ask them about your internal processes, they’ll guess, improvise, or politely say they don’t know.

Now give that consultant access to your company’s document library before every meeting. They can look up the right information, cite the exact source, and give you a confident, accurate answer.

That’s RAG. The consultant is the LLM. The document library is your vector database.

How RAG Works — The Architecture

Every enterprise RAG system — whether built on Azure, AWS, or Oracle Cloud — follows the same five-stage architecture. The diagram below shows the complete flow from raw enterprise data to a grounded, cited answer.

Figure 1: Enterprise RAG Architecture — 5-Stage Flow (Data Sources → Ingestion → Vector DB → RAG Layer → LLM Response)

Stage 1 — Data Sources

Enterprise documents from SharePoint, websites, PDFs, Word files, and Jira are the raw knowledge base. These are ingested automatically whenever content changes.

Stage 2 — Ingestion Pipeline

Each document is extracted, cleaned, and split into small chunks (typically 512 tokens). Every chunk is then converted into a vector embedding — a list of numbers that encodes its semantic meaning — using an embedding model such as Azure OpenAI text-embedding-3-small, Amazon Titan, or OCI Embed.

Stage 3 — Vector Database

Each chunk, its embedding vector, and its metadata (source, page, date) are stored in a Vector Database. On Azure this is Azure AI Search; on AWS it is OpenSearch; on Oracle Cloud it is Oracle DB 23ai with native VECTOR support.

Stage 4 — RAG Layer

When a user asks a question, it is embedded using the same model. The vector database returns the Top-5 most semantically similar chunks. These are injected into the LLM prompt as grounding context.

Stage 5 — LLM Response

The LLM (GPT-4o, Claude, or Llama) generates an answer constrained to the retrieved context only. Every claim in the answer can be traced back to a source document — which helps reduce unsupported or inaccurate responses.

The LLM is instructed: ‘Answer ONLY using the provided context. If the context does not contain the answer, say so.’ This instruction helps ensure responses stay grounded in provided information.

RAG Components at a Glance

Why This Matters for Enterprises

RAG is now the standard architecture for enterprise AI. Here is why organizations are adopting it at scale:

Accuracy: Answers are grounded in real, current company data — not stale training data.

No retraining required: Add new documents and they’re immediately searchable. No expensive fine-tuning.

Source attribution: Every answer can cite which document it came from — enabling full auditability.

Cost efficiency: Retrieval is cheap. You only send relevant chunks to the LLM, saving tokens.

Data security: Your private data stays in your infrastructure — never sent to train external models.

RAG doesn’t replace the LLM’s intelligence. It gives the LLM the right information to be intelligent about YOUR business.

What’s Coming in This Series

This is part 1 of a 5-part series on building, deploying, and testing enterprise RAG systems:

  In Part 2, we’ll walk through exactly how documents get ingested, chunked, and stored in a vector database — the foundation your RAG system’s quality depends on.

The post Why Your LLM Doesn’t Know Anything About Your Company And How RAG Fixes That appeared first on Perficient Blogs.

Testing software is no longer enough. In the age of generative AI, quality engineers must learn to test intelligence itself. 

Executive Summary 

Generative AI is transforming enterprise software at an unprecedented pace. 

Organizations are rapidly deploying: 

• AI chatbots 
• AI-powered search systems 
• Document assistants 
• Coding copilots 
• Autonomous AI agents 

Unlike traditional applications, generative AI systems are non-deterministic. The same prompt can produce multiple valid answers. 

This introduces new quality challenges, including:

• Response accuracy issues  
• Retrieval failures 
• Prompt sensitivity 
• Agent workflow failures 
• Toxicity and bias 
• Non-deterministic outputs 

To address these challenges, organizations are increasingly turning to three widely adopted platforms for AI testing and evaluation: 

The Evolution of Software Testing 

Phase 1: Manual Testing

Focus Areas:

• Functional Validation
• User Acceptance Testing
• Defect Identification

Phase 2: Automation Testing

Popular Tools:

• Selenium
• JUnit
• TestNG
• Playwright

Focus Areas:

• Regression Testing
• CI/CD Integration
• Cross-Browser Validation

Phase 3: AI-Assisted Testing

AI started helping engineers generate:

• Test Cases
• Test Data
• Automation Scripts

Popular Examples:

• GitHub Copilot
• Cursor
• ChatGPT

Phase 4: GenAI Testing

The challenge is no longer generating tests.

The challenge is:

How do we validate AI-generated responses?

This is where evaluation frameworks become essential.

Why Traditional Testing Fails for AI Systems

Traditional Software

Input

Expected Output 

Simple and deterministic. 

Generative AI System 

Question 

What are the benefits of opening a savings account? 

Response A 

| A savings account helps you earn interest while safely storing your money. 

Response B 

| Savings accounts provide liquidity, security and interest earnings. 

• Both responses are correct. 

This creates a new testing model: 

Understanding the GenAI Quality Engineering Stack 

Each platform operates at a different layer of the AI ecosystem. 

DeepEval: Bringing Unit Testing to LLM Applications 

What is DeepEval? 

DeepEval is often called: 

“PyTest for LLM Applications” 

It allows QA teams to create automated evaluation suites for AI systems. 

Core Evaluation Metrics 

Banking Chatbot Example

DeepEval helps catch these issues before production. 

Strengths 

• Excellent Regression Testing 
• CI/CD Friendly 
• Rich Evaluation Metrics 
• Familiar with QA Engineers 

Limitations 

• Requires Evaluation Datasets 
• Limited Production Monitoring 
• Basic Observability 

Ragas: The Gold Standard for RAG Evaluation 

What is RAG? 

RAG stands for: 

Retrieval-Augmented Generation 

Instead of relying solely on model training data, the system retrieves relevant information before generating an answer. 

Example 

Question: 

What is our refund policy? 

Retrieved Sources: 

• Refund Policy PDF 
• Knowledge Base Articles 
• Support Documentation 

Critical Question: 

Did the system retrieve the right information? 

This is where Ragas shines. 

Core Metrics 

Strengths 

• Purpose Built for RAG 
• Open Source 
• Industry Adoption 
• Powerful Retrieval Metrics 

Limitations 

• Limited Agent Testing 
• Minimal Observability 
• Mainly RAG-Focused 

LangSmith: Observability for AI Systems 

Why LangSmith? 

Imagine an AI Agent receives this request: 

| Create a Jira defect and send a Slack notification. 

The agent will: 

If something fails, identifying the root cause becomes difficult. 

LangSmith provides full execution visibility. 

What LangSmith Tracks 

Strengths 

• Exceptional Observability 
• Agent Debugging 
• Root Cause Analysis 
• Production Monitoring 

Limitations 

• Fewer Evaluation Metrics 
• Advanced Features May Require Paid Plans 

Head-to-Head Comparison 

Feature	DeepEval	Ragas	LangSmith
LLM Evaluation
RAG Evaluation
Hallucination Detection
Faithfulness
Agent Testing
Tracing
Monitoring
QA Friendly

Which Tool Should QA Teams Choose? 

If You’re Testing LLM Applications 

       > Choose DeepEval 

Best for: 

• Prompt Regression Testing 
• Hallucination Detection 
• Automated Quality Validation 

If You’re Testing RAG Systems 

     > Choose Ragas 

Best for: 

• Retrieval Evaluation 
• Knowledge Assistants 
• Enterprise Search Solutions 

If You’re Testing AI Agents 

    > Choose LangSmith 

Best for: 

• Agent Debugging 
• Tool Call Visibility 
• Production Monitoring 

Enterprise Recommendation 

The most mature organizations use all three together. 

Traditional QA vs GenAI QA 

The Future of AI Testing 

Over the next 3 years, we are likely to see: 

• Autonomous testing agents 
• Continuous LLM evaluation 
• Synthetic evaluation dataset generation 
• AI governance platforms 
• Agent observability frameworks 
• Dedicated AI quality engineering teams 

The future of testing is moving beyond software validation to intelligence validation. 

Recommended Learning Resources 

Official Documentation 

• DeepEval Documentation: https://deepeval.com/docs 
• Ragas Documentation: https://docs.ragas.io/en/latest/ 
• LangSmith Documentation: https://docs.smith.langchain.com/ 

YouTube Tutorials (Hands-on Use Cases) 

DeepEval 

• RAG Evaluation Using DeepEval & Confident AI (Full Tutorial) – https://www.youtube.com/watch?v=402EyLS59ho 
• DeepEval Tutorial: Unit Testing LLM AI Applications – https://www.youtube.com/watch?v=ZHiJ12MhfQ8 
• Evaluate LLMs in Python with DeepEval – https://www.youtube.com/watch?v=HAoKJT3af7Y 

Ragas 

• RAG Evaluation Metrics Tutorial using RAGAS – https://www.youtube.com/watch?v=f8zMrSysnjY 
• How to Evaluate RAG Models Using RAGAS (Step-by-Step) – https://www.youtube.com/watch?v=ahDqIQb3\_8w 
• RAGAS: Evaluate a RAG Application Like a Pro – https://www.youtube.com/watch?v=5fp6e5nhJRk 

LangSmith 

• Getting Started with LangSmith: Tracing – https://www.youtube.com/watch?v=fA9b4D8IsPQ 
• LangSmith Tutorial: Observability and Tracing for AI Agents – https://www.youtube.com/watch?v=EdzAH5\_PppM 
• LangSmith + LangChain: Full AI Agent Tracing & Debugging Tutorial – https://www.youtube.com/watch?v=DmEEZ2TiKfY 

Final Thoughts 

Generative AI introduces a new set of different quality considerations. 

Traditional testing frameworks remain important, but they are no longer sufficient on their own: 

• DeepEval helps validate LLM quality. 
• Ragas ensures retrieval systems work correctly. 
• LangSmith provides visibility into complex AI workflows. 

For modern QA engineers, understanding these platforms is rapidly becoming a core skill rather than a nice-to-have capability. 

The post DeepEval vs Ragas vs LangSmith appeared first on Perficient Blogs.

Pix already processes 42% of the total online purchases made in Brazil and is anticipated to have 50% of the total ecommerce economy in Brazil by 2028. 

What Is Pix? 

Pix is a Brazilian instant payment ecosystem designed to allow individuals and businesses to send and receive money in seconds, regardless of the time of day. Users can initiate payments through mobile banking applications using a phone number, email address, taxpayer identification number, random key, or even a QR code. The government supported platform supports person-to-person transfers, retail purchases, bill payments, payroll distributions, insurance settlements, and gig-economy payouts. 

Pix vs. Other Payment Platforms 

The table below compares Brazil’s Pix payment system with UPI, Zelle, PayPal, and Visa/Mastercard across key dimensions including speed, cost, accessibility, and adoption. 

The Drivers Behind Pix’s Success 

The biggest reason for Pix’s success was that the Brazilian government regulators wanted it to. In a rather pro-consumer and proactive decision, on November 16, 2020 (less than 6 years ago) the Central Bank of Brazil – Banco Central do Brasil (BCB) launched the instant payment system. Most significantly, BCB required major financial institutions to participate, ensuring broad availability from day one.  

Because nearly every bank and fintech supported Pix, network effects grew rapidly. From the start, Pix eliminated many of the delays and fees associated with traditional bank transfers. The free, quick settlement encouraged millions of Brazilian citizens to open and use bank accounts, meaning a positive unintended consequence of bringing more Brazilians into the formal financial system as it spread beyond just wealthier urban areas in Brazil. Pix was adopted by over 62% of Brazil’s population within a year. Its accessibility helped it spread beyond affluent urban users. 

From a merchant perspective, merchants pay less than they would for many card transactions because Pix bypasses much of the traditional card-payment chain. Of more significance, the real time settlement improves the cashflows of the merchants, as they do not have to wait until the following month to receive their net Interchange proceeds from multiple card issuers. This lowers the working capital costs of businesses. 

To avoid stagnation, BCB has continued to improve and enhance Pix’s capabilities through new features such as recurring payments, stronger security mechanisms, QR code innovations, and integrations with Brazil’s Open Finance ecosystem. 

The Result 

Pix achieved adoption at a scale rarely seen in payments: 

• Roughly 170 million users, about 80% of Brazil’s population, use the system.  

• It accounts for more than half of all transactions in Brazil by volume.  

• Per Reuters, Pix surpassed the combined number of credit and debit card transactions in Brazil within three calendar years of launch.  

Conclusion 

Pix has attracted worldwide attention as a model for real-time payments. Policymakers and financial institutions across the globe study its success as they seek to modernize payment infrastructure, promote competition, and accelerate financial inclusion. 

Pix represents far more than a payment platform. It is a transformative digital infrastructure that has reshaped commerce and financial services in Brazil through speed, accessibility, low cost, and continuous innovation. As countries increasingly move toward real-time payments, Pix offers a compelling regional blueprint for the future of digital transactions. 

If you are interested in speaking with one of Perficient’s payment experts, reach out to us here. 

The post Pix: How Brazil’s Instant Payment Revolution Is Reshaping Digital Commerce appeared first on Perficient Blogs.

Adobe Experience Manager continues to lead the enterprise content management space, combining proven enterprise-grade tooling with flexible delivery, powerful extensibility, and dependable performance. But leadership doesn’t stand still. Newer Adobe Experience Manager offerings embrace a highly flexible and scalable serverless architecture, built from the ground up and crafted from Adobe’s 20+ years of content management experience. Adobe has been working diligently on a new delivery architecture that leverages edge-based scaling and recommends serverless edge workers in place of application servers and services. This solution is called Edge Delivery Services (EDS).

“Wait, I thought EDS was document authoring?”

Not necessarily. The important thing to understand about Edge Delivery Services is that, as its name suggests, the solution is primarily a change in the content delivery tier. That in turn, once you adopt it, you’re faced with a new set of decisions to make about where you want to store the content and which UI you want to use to author it.

When you move to EDS, you always have the same Adobe-managed Delivery and Services tiers, but you can bring your own CDN to sit on top of them and the tiers that come before are flexible. When we talk about the Platform tier, there are two primary content store and management options.

1. Document Authoring
   This newer approach can use Adobe’s DA.live product, Google Docs, or SharePoint as a content store. (You may recognize DA.live by its previous names — Dark Alley, Project Franklin, or Project Helix.) Adobe heavily recommends DA.live and Document Authoring via Experience Workspace for new AEM implementations.
2. AEM as a Cloud Service (XWalk)
   When AEMaaCS is used in EDS, it’s called AEM XWalk (crosswalk). It continues to have all of the content storage and management benefits of AEM as a Cloud Service, but the content is delivered quite differently. Instead of the traditional approach where web requests come to the AEM Publish instance via Apache Sling, Adobe’s Edge Delivery Service constructs a traditional HTML hierarchy and serves it at the CDN. There’s no more Sling resource mapping and page compilation at the time of an end user’s request.

Now, to further paint this picture, I think it’s helpful to compare pieces of the classic AEM headful stack and their equivalent headful options in the Edge Delivery Services model.

As Adobe has moved to a more decoupled architecture, you may have noticed that the number of options per stack capability has also grown. This is important as selecting a platform type forces you into a set of content stores, which then forces you into a set of compatible authoring UIs.

Before you do anything else, you need to decide if you want a Headful or Headless AEM implementation. If you’re not sure how to decide, I recommend my previous blog on the topic.

One important amendment based on insights from Adobe Summit is that Adobe is making a large investment in agentic AI and tooling for the experience layer. While choosing headless will decouple the CMS from the presentation layer and have a higher degree of freedom, you’re also limiting Adobe’s ability to add value at the presentation layer. New presentation-layer features and agents will only work in a headful experience.

With user-driven web experiences on the horizon, this is an increasingly important consideration. You may ultimately find it more valuable to cater to user interests with adaptable, personalized experience rendering than stick with traditional business-driven experiences.

Once you’ve made the Headful vs Headless call, the next set of capability decisions becomes clearer.

Headful Decisions

If you decide on a headful approach, you’re implicitly picking EDS. From there you decide between XWalk or Document Authoring as the content source. While the exact pros and cons of each solution are beyond the scope of this blog post, I will offer a few light comparisons.

1. XWalk utilizes all of the existing AEM content management tooling, security, workflows, WYSIWYG authoring, and content policy controls.

2. Document Authoring focuses on author empowerment in the document-style authoring that most users already understand.

Decision – Headful with XWalk

If you decide on XWalk, the AEMaaCS Java Content Repository will be your primary content authoring store, just like in a traditional AEMaaCS implementation. The AEM Sites Admin will continue to manage your page content. What changes are the following:

• You will need to utilize AEM blocks instead of Touch UI components
• Universal Editor will be your primary component and page editor.

Decision – Headful with Document Authoring

If you decide on Document Authoring, you have several choices for a primary content authoring store. I highly recommend DA.live as the primary source as it contains CMS tooling, though you may have existing documents in Google Docs and SharePoint you want to integrate. Document Authoring implementations require AEM blocks. Then you have a choice about how your authors edit content:

1. Edit directly in the Document UI.
2. Edit in Universal Editor for a more WYSIWYG experience.

Headless Decisions

If you decide on a headless approach, you have a different series of decisions to make. Both the AEMaaCS JCR and Document Authoring can be a headless content store. As I said earlier, the exact pros and cons of each headless solution are beyond the scope of this blog post, so let’s focus on the subsequent decisions.

Decision – Headless with AEMaaCS

If you decide to use AEMaaCS, do you utilize:

1. Content fragments
2. Page-based resources
3. Both?

I covered these pros and cons in my last blog post. If you use page-based resources, you will always use the Universal Editor as the authoring UI. If you use content fragments, you will use the content fragment editor and optionally the Universal Editor if you want WYSWYG-style authoring.

Now, there’s one caveat with AEMaaCS to be aware of. If you use page-based resources, as of mid-2026, there is no OOTB schema definition available for AEM Blocks (EDS-style components).  If you want small headless payloads, you will have to utilize classic Sling Models as described in my last blog post or develop a custom solution.

Decision – Headless with Document Authoring

If you decide on a headless approach with Document Authoring, I would highly encourage you to use DA.live and not Google or SharePoint. In a headless use case, you need a schema-based JSON export. Of the previously mentioned document stores, only DA.live offers that out of the box. Document Authoring implementations require AEM blocks implementations. Then you have a choice to make about how your authors edit content. You can have them edit directly in the document view or utilize the Universal Editor for a more WYSIWYG experience.

Wrap-up

With an increasingly decoupled AEM architecture, there are more options than ever before to meet the needs of your organization. Still need help deciding? Be on the lookout for a future blog post that walks through the paradigm shift that is Document Authoring. Or reach out directly! For more information on how Perficient can implement your dream digital experiences, we’d love to hear from you. We’re certified by Adobe for our proven capabilities, and we hold an Adobe Experience Manager specialization (among others).

Contact Perficient to start your journey.

The post At the Speed of Content: Adobe’s Lightning Fast Product Offerings appeared first on Perficient Blogs.

JMeter is a free tool made by Apache that helps you test how well your website, app, or API performs when lots of people use it at the same time. It acts like many users hitting your system all at once to see how it handles the pressure.

It’s great for testing:

• Websites and web apps
• REST and SOAP APIs
• Databases

Other services like FTP, JMS, LDAP (though most people use it for web and API testing). JMeter runs on Java, so make sure you have Java installed — version 8 or higher (Java 17+ is even better). The latest version of JMeter is around 5.6.3.

#2. Apache JMeter Working

JMeter is a Java based application or tool that simulates a group of users and sends requests to a target server. And hence, return statistics which show the functionality and performance of the server.

Working of Apache JMeter is explained in the image below:

#3. JMeter Test Plan Structure

Everything in JMeter lives inside a Test Plan — think of it as your test notebook.

Basic tree structure looks like this (from top to bottom):

• Test Plan (the root / main folder)
  • Thread Group (your virtual users — most important!)
    • Samplers (what action each user does — e.g. HTTP Request to open google.com)
    • Logic Controllers (if/loop/while — optional for now)
    • Pre/Post Processors (prepare or clean data — optional)
    • Assertions (check if response is correct — optional)
    • Timers (add think time between clicks — very useful!)
    • Config Elements (HTTP Header Manager, Cookies, etc.)
  • Listeners (how you see results — tables, graphs, reports)

Most beginners start with just: Test Plan → Thread Group → HTTP Request → Listener.

#4. Create Your First Test Plan (Step-by-Step)

Step 1: Download and open JMeter

1. Download JMeter from the official Apache page:
   https://jmeter.apache.org/download_jmeter.cgi
2. Download the binary file (ZIP or TGZ). For example, Apache JMeter 5.6.3 has both apache-jmeter-5.6.3.zip and apache-jmeter-5.6.3.tgz.
3. Unzip / extract it anywhere on your machine.
4. Open the bin folder:
   1. Windows: double‑click jmeter.bat
   2. Mac/Linux: run jmeter.sh
      
5. JMeter GUI opens and you will see a blank Test Plan.

Step 2: Add a Thread Group (users)

1. Right‑click Test Plan → Add → Threads (Users) → Thread Group

Thread Group controls how many users run your test and how the load starts.

Step 3: Create a GET API test (List objects)

3.1 Add HTTP Request sampler

Right‑click Thread Group → Add → Sampler → HTTP Request

3.2 Fill HTTP Request fields (IMPORTANT) 

Use these values: 

• Name : HTTP Get Request 

• Protocol: https 

• Server Name or IP: api.restful-api.dev (only domain, not full URL)  

• Method: GET  

• Path: /objects  

 The real endpoint is:  https://api.restful-api.dev/objects 

Common mistake: Don’t put https://api.restful-api.dev/objects inside “Server Name”. If you add path there, JMeter can fail with host errors (UnknownHost). Use domain in Server Name and endpoint in Path.

3.3 Add Listeners

Right-click Thread Group → Add → Listener → View Results Tree (best for debugging)

• Add Summary Report or Aggregate Report (for final numbers)

3.4 Save Your Test Plan

Save your file as something like FirstGetApiTest.jmx

3.5 Run the Test

Click green Play button (or Run → Start)

3.6 Watch the Results

Watch the results in View Results Tree!

Step 4: Create a POST API test (Add an object)

4.1 Add another HTTP Request sampler

Right‑click Thread Group → Add → Sampler → HTTP Request

4.2 Configure POST sampler fields

• Name: HTTP Post Request
• Protocol: https
• Server Name or IP: api.restful-api.dev
• Method: POST
• Path: /objects

4.3 Add JSON Body (Body Data)

Inside the POST HTTP Request sampler, go to Body Data and paste this JSON:

JSON : {

“name”: “Apple MacBook Pro 16”,

“data”: { “year”: 2019,

“price”: 1849.99,

“CPU model”: “Intel Core i9”,

“Hard disk size”: “1 TB”

} }

This sample object structure matches the API style shown by restful-api.dev (objects contain name and flexible data).

4.4 Add Header (Content-Type)

For POST requests, you should send JSON with correct header.

1. Right‑click the POST HTTP Request (or Thread Group) →
   Add → Config Element → HTTP Header Manager

2. Add header:

• Content-Type = application/json

This tells the server your request body is JSON.

Step 5: Add Listeners (to see results)

For debugging (best for beginners)

• Right‑click Thread Group → Add → Listener → View Results Tree

For final numbers (report-style)

Add one of these:

• Summary Report or Aggregate Report

Listeners show your execution results in table/tree/graph formats and can save results too.

Step 6: Save your test plan

Save file: JMeter recommends saving your test plan before running.

Step 7: Run the test

Click the green Play button (or Run → Start).

Now open View Results Tree to see:

• Request details
• Response body
• Status code (200/201)
• Any error message

You now understand how to create GET and POST API tests in JMeter.
Next, let’s take your learning one step further with two practical real‑world challenges.
The first covers JWT Authentication Testing in JMeter, and the second focuses on Data‑Driven Testing at Scale with JMeter (CSV + Groovy).

Challenge A: JWT Authentication Testing in JMeter Using DummyJSON API

This section provides a simple, production-friendly approach to testing JWT authentication in Apache JMeter using the DummyJSON Auth API. It demonstrates how to build a minimal test plan that performs a complete authentication flow with only the essential JMeter components. The guide walks through sending a login request to generate a JWT accessToken, extracting the token using a JSON Extractor, and finally invoking a protected endpoint (/auth/me) using the required Authorization: Bearer <token> header. With a focus on clarity and minimalism—no timers, assertions, or extra plugins. This blog serves as an ideal starting point for understanding token-based authentication testing in JMeter.

Step 1: Create a New Test Plan

1. Open Apache JMeter 5.6.3+
2. Go to File → New
3. Rename it to: DummyJsonAuthTest

Step 2: Add HTTP Request Defaults

1. Right‑click Test Plan →
   Add → Config Element → HTTP Request Defaults
2. Enter the following values:

• Server Name or IP: dummyjson.com
• Protocol: https

This sets the base URL so you don’t repeat it everywhere.

Step 3: Add Global HTTP Header (Content-Type)

1. Right‑click Test Plan →
   Add → Config Element → HTTP Header Manager 
2. Add only one header:

• Name: Content-Type
• Value: application/json

This ensures your JSON login body is posted correctly.

Step 4: Add a Thread Group

1. Right‑click Test Plan →
   Add → Threads (Users) → Thread Group 
2. Configure the following settings:

• Number of Threads: 1
• Ramp-Up Period: 1
• Loop Count: 1

This keeps the test extremely lightweight.

Step 5: Add Login API (POST /auth/login)

1. Right‑click Thread Group →
   Add → Sampler → HTTP Request
2. Set the following:

• Name: Login – POST /auth/login
• Method: POST
• Path: /auth/login

3,  Go to Body Data tab → paste:

{

“username”: “emilys”,

“password”: “emilyspass”,

“expiresInMins”: 30

}

This request matches DummyJSON’s official documented example.

Step 6: Extract JWT accessToken

This is the most important step.

1. Right‑click Login sampler →
   Add → Post Processor → JSON Extractor
2. Configure the following:

• Variable Name: accessToken
• JSONPath Expression: $.accessToken
• Default Value: NOT_FOUND

Why $.accessToken?
Because DummyJSON returns this exact field name in the login response.

 Step 7: Add Protected API (GET /auth/me)

1. Right‑click Thread Group →
   Add → Sampler → HTTP Request
2. Configure the following:

• Name: Protected – GET /auth/me
• Method: GET
• Path: /auth/me

Step 8: Add Authorization Header (Bearer Token)

1. Right‑click Protected sampler →
   Add → Config Element → HTTP Header Manager
2. Add:

• Name: Authorization
• Value: Bearer ${accessToken}

DummyJSON explicitly states that /auth/me must receive the accessToken via the Bearer header.

Step 9: Add View Results Tree (Optional but Useful)

1. Right‑click Thread Group →
   Add → Listener → View Results Tree

This will allow you to see the response body and confirm that the token extraction works correctly.

Step 10: Run the Test

Click the green Start button ().

Expected Behavior

• Login API returns 200 with a JSON containing accessToken.
• The JSON Extractor captures the token.
• Protected API returns 200 with authenticated user details.

If you see:

401 Unauthorized

Check the View Results Tree → Request headers → Authorization must look like:

Authorization: Bearer eyJhbGciOiJIUzI1NiIs…

Challenge B: Data‑Driven Testing at Scale with JMeter (CSV + Groovy)

This section explains an easy and practical way to run large‑scale API load tests in JMeter without errors or data conflicts. When many virtual users use the same username or repeated IDs, tests often fail because of server caching or duplicating data issues. To avoid this, the blog shows how to give each virtual user its own unique data using a CSV file, small random values, and Groovy scripts.

You’ll learn how to create a clean and simple JMeter test plan that reads login details from a CSV file, skips the header row, adds random values, and generates unique fields through a Groovy PreProcessor. The test then logs in, extracts an access token, and uses that token to call a protected endpoint. This guide helps you build reliable, scalable, and realistic API tests in JMeter.

1) Prepare Your CSV Data

Create a file named users.csv. Include a header and tab or comma as your delimiter. Two examples:

Option A — Tab‑separated

username        password

emilys emilyspass

michaelw         michaelwpass

sophiab            sophiabpass

Option B — Comma‑separated

username,password

emilys,emilyspass

michaelw,michaelwpass

sophiab,sophiabpass

We’ll configure JMeter to ignore the first line so the header is not treated as credentials.

2) Create a New JMeter Test Plan

1. Open JMeter → File → New.
2. Rename Test Plan to: DummyJsonAuthTest_data_driven

3) Add HTTP Request Defaults

• Test Plan → Add → Config Element → HTTP Request Defaults
  Set:
  • Protocol: https
  • Server Name or IP: dummyjson.com

(Prevents repeating the base URL for every request.)

4) Add Global HTTP Header Manager

• Test Plan → Add → Config Element → HTTP Header Manager
  Add: Content-Type : application/json

5) Add CSV Data Set Config (Critical)

• Test Plan → Add → Config Element → CSV Data Set Config

Configure:

• Filename: users.csv
• Variable Names: username,password
• Delimiter:
  • \t if your file uses tabs
  • , if your file uses commas
• Ignore first line: True  (ensures the header row is not treated as data)
• Recycle on EOF: False
• Stop thread on EOF: True
• Sharing mode: All threads

With Ignore first line = True, JMeter reads username,password strictly as variable names, and your data rows become proper user credentials.

Setting Recycle=False / Stop on EOF=True ensures each row is used once per thread and unused threads stop when data runs out.

6) Add a Thread Group

• Test Plan → Add → Threads (Users) → Thread Group
  Example settings (tune to your needs):
  • Number of Threads (users): 5
  • Ramp‑Up (sec): 5
  • Loop Count: 1

Each thread will pick the next row from users.csv.

7) Add the Login Request (POST /auth/login)

• Thread Group → Add → Sampler → HTTP Request
  • Name: Login – POST /auth/login
  • Method: POST
  • Path: /auth/login

Body Data:

{

“username”: “${username}”,

“password”: “${password}”,

“expiresInMins”: 30,

“note”: “rnd_${__Random(1000,9999,)}”

}

Why this helps

• ${username} / ${password} come from the CSV row for that thread.
• ${__Random(1000,9999,)} appends a small random number per request (handy when you want trivial uniqueness).

8) Generate Unique Variables (JSR223 PreProcessor, Groovy)

We’ll create values that are globally unique per sampler execution, perfect for payload fields like emails or order names.

• Right‑click Login – POST /auth/login → Add → Pre Processors → JSR223 PreProcessor
• Language: groovy
• Script:

// Unique email and order name per sample

import org.apache.commons.lang3.RandomStringUtils

String random = RandomStringUtils.randomAlphanumeric(8)

vars.put(‘uniqueEmail’, ‘test’ + random + ‘@example.com’)

vars.put(‘uniqueOrderName’, ‘Order_’ + System.currentTimeMillis())

“

You can now use ${uniqueEmail} and ${uniqueOrderName} in any downstream JSON body or header to avoid caching/collisions.

If you see a class not found error for RandomStringUtils, add Apache Commons Lang to JMeter’s /lib folder and restart JMeter. Most distributions already include it, but environments vary.

9) Extract the Token (JSON Extractor)

• Right‑click Login – POST /auth/login → Add → Post Processors → JSON Extractor
  Configure:
  • Names of created variables: accessToken
  • JSONPath expressions: $.accessToken
  • Default Values: NOT_FOUND

The login response should return accessToken. This extractor exposes it as ${accessToken} for the next step.

10) Add a Protected Request (GET /auth/me)

• Thread Group → Add → Sampler → HTTP Request
  • Name: Protected – GET /auth/me
  • Method: GET
  • Path: /auth/me

Add a Header Manager (child of this sampler):

• Authorization : Bearer ${accessToken}

11) Add One View Results Tree (for quick verification)

• Thread Group → Add → Listener → View Results Tree

Run a small test (1–5 threads) and verify:

• Login → 200 OK, response contains accessToken.
• Debug Sampler (optional) shows username, password, uniqueEmail, uniqueOrderName, and accessToken.
• /auth/me → 200 OK with user details.
• No more Invalid credentials due to the header row being treated as a login attempt.

The post JMeter Performance Testing appeared first on Perficient Blogs.

1. Why Testing Is Required

Traditional software is predictable; LLMs are probabilistic. Responses may vary depending on prompts, context, and available information. DeepEval addresses this through automated test cases, evaluation metrics, benchmarking, and continuous reporting.

2. Types of Test Cases

Single-Turn, Multi-Turn, and Arena Test Cases provide increasing levels of evaluation coverage.

3. End-to-End LLM Evaluations

Treat the application as a black box and evaluate final user outcomes.

4. Confident AI Platform Features

Confident AI extends DeepEval with Test Runs, Datasets, Arena comparisons, Experiments, Prompt Studio, Reporting, Observability, Governance, and collaborative evaluation workflows.

5. Why This Matters for Business

Objective quality measurement reduces risk and increases trust in AI systems.

Conclusion

DeepEval converts subjective AI evaluation into measurable engineering metrics.

6. Evaluation Report Screenshot

Figure 1. DeepEval / Confident AI Test Runs dashboard.

7. Python Installation

pip install deepeval

pip install –upgrade deepeval

deepeval –help

pip show deepeval – Get the version of deepeval

8. Running DeepEval Locally 

One important observation from my testing:

I successfully performed local DeepEval testing without using an OpenAI API key by executing custom Python-based evaluation logic and creating evaluation reports locally.

This demonstrates that evaluation concepts and reporting can be validated locally using Python implementations. However, DeepEval also supports advanced LLM-as-a-Judge metrics.

Arena Test Case Diagram

Model A Answer —-> Compare —-> Winner
Model B Answer —-^

End-to-End Evaluation Flow

User Query -> AI App -> Response -> DeepEval Metrics -> Report -> Improvement

LLM Evaluation Lifecycle

Datasets -> Test Cases -> Evaluation -> Metrics -> Test Runs -> Optimization

• Test Runs: Benchmark and track evaluation results over time.
• Datasets: Manage golden datasets and evaluation samples.
• Arena: Compare prompts, models, and responses side-by-side.
• Experiments: Measure quality impact before release.
• Prompt Studio: Iterate and validate prompts systematically.
• Reports & Dashboards: Centralized visibility into AI quality.
• Observability: Monitor production traces and quality signals.
• Governance: Standardize evaluation across teams.

References

https://deepeval.com/docs/evaluation-test-cases

https://deepeval.com/docs/evaluation-end-to-end-llm-evals

https://app.confident-ai.com/project

The post DeepEval Explained Simply: Why Testing AI Outputs Matters appeared first on Perficient Blogs.

From EDC systems, laboratory data, clinical trial management systems (CTMS), and safety data to operational and real-world sources, the volume of information flowing through clinical programs continues to grow.

At the same time, AI is creating new opportunities to analyze that information at a scale that wasn’t previously possible. Organizations can no longer afford to treat quality as something that gets evaluated at the end of a study. Increasingly, they need to identify risks, signals, and data issues while there is still time to act.

That’s creating a new challenge for clinical teams. The industry’s problem is no longer access to data. It’s deciding where experts should focus their attention.

More Data Hasn’t Made Review Easier

For years, life sciences organizations have invested heavily in data platforms, automation, and analytics. Yet clinical trial delays remain stubbornly persistent.

According to the Tufts Center for the Study of Drug Development, approximately 80% of clinical trials still miss their planned enrollment timelines. If the industry has more data, more technology, and more AI than ever before, why do delays remain so persistent?

A core reason is that visibility alone doesn’t create action. Data may be available, but it’s not always organized, prioritized, or presented in a way that helps teams determine what requires attention first. Clinical data managers, medical reviewers, and biostatisticians still spend significant time reconciling information across multiple systems, reviewing discrepancies, and tracking down answers before meaningful analysis can even begin.

Clinical teams are being asked to do all of this at once:

• Review growing volumes of study data
• Identify potential data issues and safety or efficacy signals earlier
• Resolve discrepancies faster
• Support increasingly complex protocols
• Deliver cleaner, submission-ready datasets

The result is a familiar pattern. Teams accumulate more information than ever before, while the people responsible for reviewing it face increasing pressure to move faster without sacrificing quality, safety, or compliance.

The Shift Toward Risk-Based Clinical Data Review

One of the most important changes happening in clinical development today is the move toward more proactive and risk-based approaches.

The goal isn’t simply reviewing data faster. It’s bringing quality, oversight, and risk identification earlier into the trial lifecycle. Instead of treating every data point equally, organizations are asking a different question: Where should we focus first?

As data volumes continue to grow, that question becomes increasingly difficult to answer. Clinical teams can’t scale review activities in direct proportion to the amount of information flowing through a study. They need better ways to prioritize attention, identify meaningful risk, collaborate, and focus effort where it can have the greatest impact.

Why AI-Driven Clinical Review Is Becoming a Competitive Advantage

When people think about clinical trial performance, they often focus on enrollment, protocol design, or study execution. But clinical data review plays an equally important role.

The faster teams can identify anomalies, review discrepancies, detect potential safety or efficacy signals, and align around a common view of study performance, the faster they can make informed decisions. Instead of spending time searching for information, teams need critical signals surfaced in the moments they matter most. That shift is already underway across the industry.

Quality is becoming part of the process from the beginning rather than something that gets evaluated after the fact.”
— Prabha Ranganathan, Associate Vice President, Life Sciences

Organizations are increasingly moving quality and oversight earlier in the trial lifecycle rather than relying on downstream review and remediation. As a result, clinical data review is becoming less about finding issues after they occur and more about identifying risks while there is still time to act.

Better Decisions Require More Than Visibility

Which discrepancies represent meaningful risk? What signals may indicate a developing safety concern? Which issues can wait, and which require action right now?

These are the questions that can’t be answered by another dashboard alone. They require a trusted view of data, clear prioritization, and the ability to connect signals to action while there is still time to influence the outcome.

That’s why clinical data review is evolving from a process focused on finding issues to one focused on identifying risk sooner.

Perficient’s Clinical Data Repository and Review solution was designed to support that shift. By combining a unified clinical data foundation with agentic AI capabilities, it helps organizations move beyond data aggregation and turn growing volumes of clinical information into faster, more informed decisions.

As data volumes continue to grow, competitive advantage increasingly comes from finding critical signals sooner—not reviewing more data.

The Next Challenge Isn’t More Data

The life sciences industry has spent years solving the problem of data collection. The next challenge is helping clinical teams keep up with what that data is trying to tell them.

Organizations that gain an advantage won’t necessarily be the ones generating more information. They’ll be the ones that help their experts find the right signals faster, make better decisions sooner, and act before risks impact study outcomes.

Interested in seeing what that could look like in practice? Reach out to schedule a demo with Perficient’s Healthcare & Life Sciences team to explore how AI-driven clinical review can help your teams focus less on administrative work and more on the decisions that move studies forward.

The post Faster Decisions Start With AI-Driven Clinical Review appeared first on Perficient Blogs.

Health plans are losing Star ratings because insights arrive too late to change outcomes. AI closes that gap by getting the right insight to the right person while there is still time to act.

At this year’s Databricks Data + AI Summit (DAIS), health plan leaders consistently pointed to the same challenge: improving outcomes in an increasingly complex data environment. I spoke with Matthew Giglia, Healthcare and Life Sciences Forward Deployed Engineer at Databricks, about how AI is helping healthcare organizations get more value from their data.

More Data Isn’t the Missing Piece

Health plans no longer have a data problem. Most already have access to claims and clinical data, social determinants, member engagement history, quality measures, and risk scores.

But more data has not automatically translated into better Star ratings, faster interventions, or clearer insight into what is working.

That signals an important shift: the bottleneck is no longer data.

The Gap Between Insight and Action

Data was never the real constraint. Decision latency is. An insight sitting in a dashboard doesn’t close a care gap. A risk score doesn’t improve a measure on its own. A report doesn’t change a member outcome unless it reaches the workflow where decisions are made — while there is still time to act.

In many plans, the distance between knowing and doing is still measured in weeks. By then, the opportunity to intervene has often passed.

The problem is not the model or the report. It’s how long it takes to respond once an opportunity is identified. That’s why a health plan can have sophisticated analytics and still struggle to move its Star ratings.

AI Should Not Mean More Noise

The organizations getting real value from AI aren’t using it to gather more information. They’re using it to shorten the distance between insight and intervention.

In practice, AI helps health plans:

• Prioritize what matters instead of surfacing every signal with the same urgency
• Surface risk earlier so care managers and quality teams can intervene before an outcome is locked in
• Reduce the noise that buries care managers in alerts they can’t work through

While the challenge shows up differently for health plans and providers, Giglia sees the same shift from the technology side:

Health systems used to treat yesterday’s data as good enough. Now, with AI in the mix, they need that data connected across every domain it touches: governed, tagged, and traceable back to its source, but usable the moment it’s needed.” — Matthew Giglia, Databricks

The technology to do this exists. The harder work is making it practical inside the workflows care managers already use every day.

Stars Performance Is a Decision Problem

Stars ratings are often treated like a measurement problem — they aren’t. The measures matter, of course. So do dashboards, scorecards, and reporting cycles. But performance changes when teams make better decisions sooner.

That means helping teams answer the questions that shape daily work:

• Which members should we prioritize this week?
• Which interventions are most likely to improve a specific measure?
• Where is staff effort going without measurable impact?
• What actions were taken, and what changed as a result?

Whether the measure involves medication adherence, preventive screenings, or member experience, the challenge is often the same: identifying the right intervention early enough to influence the outcome.

These decisions cannot be answered by visibility alone. They require trusted data, clear prioritization logic, workflow integration, and feedback loops that show whether an action worked.

This is where Stars intelligence needs to show up: in outreach planning, care management queues, quality interventions, and resource allocation. Not after the fact and not buried in another report. It needs to be available in the flow of work while the decision still matters.

How We Partner with Databricks to Close the Gap

Perficient and Databricks partner together to help health plans close the distance between data and action.

Databricks provides a governed foundation that brings claims, clinical, and social determinants of health data into a trusted environment for analytics and AI. Perficient helps health plans put that foundation to work. We define the governance, prioritization logic, and adoption strategy needed to move AI from concept to operational impact.

The goal is not another proof of concept. It is to help care managers, quality leaders, and operations teams make faster, better-informed decisions in the workflows that drive Star performance.

Our Databricks Brickbuilder Specialization for Healthcare & Life Sciences reflects that combination. It brings together technical depth on a governed platform with healthcare expertise that translates AI into measurable outcomes.

That’s exactly the kind of work we want partners to lead. We can provide the platform and accelerators, but healthcare expertise is critical to making the solutions real.” — Matthew Giglia, Databricks

The Plans That Win Won’t Be the Ones with the Most Data

Health plans need to prioritize getting trusted information to the people who know what to do with it — while there is still time to change the outcome. That is the practical promise of AI in Stars performance.

Data, models, and platforms all matter. But they are infrastructure. The real advantage is the ability to decide and act faster than the plan next to you.

That’s what will move a Star rating next cycle: not another layer of data, but whether the member who needed the call got it in time.

Curious what else came up in health plan conversations at DAIS this year? See Why AI Stalls for Health Plans: Turning Data Into Action to see how this same issue is playing out across the industry.

Connect with our Healthcare & Life Sciences team to see what closing the distance between data and action could look like for your plan.

The post Why More Data Won’t Fix Your Star Ratings appeared first on Perficient Blogs.

With tools like Figma Make, Copilot, and increasingly capable design assistants, teams can generate layouts, components, flows, and interactive prototypes in a fraction of the time it once took. Work that previously required days can now be accomplished in hours—or even minutes. 

As a result, a question is becoming increasingly common: 

If AI can generate high-fidelity designs almost instantly, why bother with low-fidelity wireframes at all? 

It’s a reasonable question. It’s also the wrong one. 

The assumption behind that question is that UX activities are simply increasingly polished versions of the same thing—that discovery becomes wireframes, wireframes become mockups, mockups become prototypes, and prototypes become products. 

If that were true, skipping straight to polished designs would be an obvious efficiency. But that isn’t how UX works. 

UX Is Not a Screen Production Process 

One of the most persistent misconceptions about UX is that its primary purpose is producing screens. 

It isn’t. The purpose of UX is reducing uncertainty. 

Every activity in the UX process exists because there is a specific question the team needs answered before investing additional time, money, and effort. As those questions are answered, uncertainty decreases and confidence increases. 

Viewed through that lens, the purpose of each activity becomes much clearer. 

These are not interchangeable deliverables. They reduce different types of risk. A team that skips an activity is not simply skipping work. It’s choosing not to answer a particular question. 

Sometimes that’s fine. Sometimes it’s expensive. 

Why Low-Fidelity Wireframes Still Matter 

Consider the debate around skipping low-fidelity wireframes. 

There are certainly situations where moving directly to high-fidelity designs makes sense. If a product already has a mature design system, well-defined requirements, established user workflows, and a library of proven components, much of the structural uncertainty has already been resolved. In those situations, jumping directly into polished designs can be entirely appropriate. 

Those situations exist. They’re just not the norm. 

Most projects begin with incomplete requirements, evolving stakeholder expectations, competing priorities, and unanswered questions about user behavior. In those environments, low-fidelity wireframes provide value for a reason that has nothing to do with artistic skill or speed. 

They make change inexpensive. 

Moving a box on a wireframe takes seconds. Changing a workflow takes minutes. Reworking a polished interface with dozens of components, interaction states, accessibility requirements, and responsive behaviors can take days. 

More importantly, low-fidelity artifacts change the conversation. When stakeholders see sketches and wireframes, they tend to discuss structure, content, priorities, and workflow. When stakeholders see polished interfaces, they often discuss colors, typography, spacing, and visual details. The more finished something looks, the less willing people become to question whether the underlying solution is correct. 

Wireframes help teams evaluate the foundation before decorating the house. 

AI Changes the Speed—Not the Purpose 

This distinction is at the heart of AI’s impact on UX. 

AI can generate ten dashboard concepts in minutes. It can create navigation models, interface variations, onboarding flows, prototypes, and even production-ready code with remarkable speed. 

What it cannot determine is whether users need a dashboard in the first place. 

Before any design should be evaluated, teams still need answers to questions such as: 

• Are we solving the right problem? 
• What is creating friction today? 
• What do users actually need? 
• Which assumptions have been validated? 
• What outcome are we optimizing for? 

Those aren’t design questions. They’re uncertainty questions. And uncertainty is what UX exists to reduce. 

AI is transforming how quickly teams create artifacts. It can generate concepts, suggest layouts, summarize research, automate documentation, produce code, and eliminate countless hours of repetitive work. What it has not changed is the purpose of the UX process. 

The goal was never simply to create screens. The goal was to learn enough about users, problems, and business needs to make informed decisions. AI accelerates execution. It does not eliminate uncertainty. 

The Two Jobs of UX 

One mental model helps explain where AI creates value—and where it doesn’t. Every UX project contains two fundamentally different jobs. 

Job #1: Creating Artifacts 

• Sketches 
• Wireframes 
• Mockups 
• Prototypes 
• Specifications 

Job #2: Reducing Uncertainty 

• Understanding users 
• Identifying problems 
• Aligning stakeholders 
• Evaluating tradeoffs 
• Validating assumptions 
• Testing solutions 

AI dramatically accelerates the first job. The second job remains where UX creates most of its strategic value. In fact, the faster artifact creation becomes, the more important the second job becomes. Producing the wrong thing quickly is still producing the wrong thing. 

A More Useful Question 

The most valuable question organizations can ask is not: 

Can we skip wireframes now that we have AI? 

Instead, ask: 

What uncertainty was this activity intended to reduce, and has that uncertainty already been resolved? 

That question applies to wireframes, discovery research, usability testing, competitive analysis, stakeholder workshops, and every other UX activity. If the answer is yes, eliminating or compressing a step may be entirely reasonable. If the answer is no, the uncertainty hasn’t disappeared. It has simply been deferred to a later—and usually more expensive—point in the project. 

The Real Impact of AI on UX 

AI is reshaping UX processes. Some activities are becoming faster. Some are being combined. Some traditional deliverables are becoming less important than they once were. 

A designer who once sketched on paper may now generate concepts directly in a design tool. A team that previously created dedicated wireframes may move directly into editable prototypes. 

The artifacts may change. The questions do not. And those questions are the reason UX exists. Because the real value of UX has never been creating screens. It has always been reducing uncertainty before uncertainty becomes expensive. 

AI helps us produce answers faster. UX helps us make sure we’re answering the right questions. 

The post AI Can Generate Your Designs Faster—But It Can’t Tell You Which Questions to Skip appeared first on Perficient Blogs.