Back to the Prolego reference library

Performance-Driven Development, building reliable AI from the start

Reliability has two parts:

1. Getting organizational consensus on what the AI should do. During development, business, operational and technical stakeholders work through concrete examples and agree on the behavior the organization wants.
2. Ensuring that it does it correctly. In production, the system must perform that agreed work reliably across real situations, with review and improvement as the business and technology change.

Performance-Driven Development, or PDD, is our methodology optimized to mitigate this risk. We build reliability into the system from the start, with performance measures and expert feedback directing the engineering.

PDD is an emerging methodology that we keep refining through enterprise work. AI capabilities and the ways to use them are changing continuously, so the practices will keep evolving. The organizing purpose remains reliability: establish agreement on what the AI should do and engineer the system to do it correctly.

Why this requires a new playbook

AI coding tools and LLM reasoning make software cheaper and easier to build, shifting the biggest risk toward agreeing on the behavior and ensuring the system delivers it correctly. PDD addresses that shift while retaining the obligations of secure, scalable, well-tested software, as the new AI playbook explains.

From agreement in development to reliability in production

The first two checkpoints structure the project and build the system around shared expectations. The next two scale production review and turn findings into evaluated improvements. Together, they connect agreement on what the AI should do with the ongoing work of ensuring it does it correctly.

Checkpoint 1: Structure the project

This is delivery planning after we have chosen a starting opportunity together. We work with the client to agree the business problem, KPI, executive sponsor, business owner, dedicated subject-matter expert and technical operations counterpart. The business owner and expert provide the judgment needed for a reliable feedback loop.

Do the reliability work before the scale work. Getting started takes a company name and an initial idea. Planning delivery with Prolego establishes the responsibilities and conditions for the selected project.

Checkpoint 2: Build a reliable system

During the first 30 days, we build the workflow and evaluation framework with every stakeholder: business, operations, legal, compliance, security, technology, infrastructure and training. Their concerns become examples. The same examples become the automated test suite.

The client evaluates the results, not Prolego. Its experts help write the cases, define correct outputs and confirm that the LLM judge applies their standards. A working framework often has roughly 100 well-scoped cases, covering ordinary work and important exceptions. A manager typing a few questions into a chatbot cannot provide that coverage.

Agree on what the system should do

Development makes organizational agreement concrete. People responsible for the work define the behavior they want, and engineers build and evaluate the system against those expectations.

A request to answer policy questions may sound straightforward. In practice, experts can disagree about which source governs, what a rule means, whether an exception applies and what the employee should do next. A source document may be incomplete or inconsistent with current practice. An employee's question may omit the fact that determines the answer.

Concrete examples make those disagreements visible. The business owner, relevant experts and product team examine ordinary work, difficult cases and stakeholder concerns. They decide which behavior is acceptable and who can resolve an open question.

Legal, compliance, security and other responsible functions contribute where the work affects their requirements. Their concerns become specific cases or controls: what should happen when information is missing, a user asks for something outside their authority, or retrieved material conflicts with approved guidance?

In a debt-consolidation workflow, three or four stakeholders had to agree on the calculation method. Engineering could not decide that for them. The evaluation work made the disagreement visible and gave the team an agreed behavior to build toward. Our delivery accounts describe the work.

The agreement can evolve. Changes should be explicit so the team can distinguish a better implementation from a changed definition of the task.

Represent the work people will actually do

We develop a set of representative inputs and expert-reviewed expected outcomes. For a document workflow, those can be source documents and completed work products. For policy assistance, they can be realistic questions and acceptable answers. For structured-data analysis, they can include the source records, question, calculation and expected result.

The set should cover common work and important exceptions. Real users ask short, incomplete and ambiguous questions. They change requirements. They bring unfamiliar formats. A useful evaluation includes those behaviors rather than only well-written questions that give away the answer.

Expected outcomes need enough detail to judge the actual result. They may specify required evidence, calculations, exceptions, review responsibilities and the required deliverable. They can allow several acceptable expressions when exact wording does not matter.

A correct outcome may be a clarification question or a hold. If a claims file lacks a controlling policy endorsement, an invented interpretation should not earn credit because the summary looks complete.

Make performance visible in a report people can inspect

An evaluation framework connects four parts: representative data and tasks, the actual AI solution, a workflow that runs and assesses the cases, and a performance report. The AI solution includes prompts, information preparation, retrieval, tools, orchestration and other components needed for the task.

The report lets experts and engineers examine the same work. A useful case record includes:

A spreadsheet can be enough to start. As the work develops, scripts and evaluation tools can run cases, capture results and help compare changes. The method does not require a particular evaluation platform.

Example performance reports

These fictional examples from our teaching materials show what an expert can inspect in a report. The policies, outputs, scores and resource figures illustrate the method, rather than client results or current model benchmarks.

The report exposes the actual answer and the judge's reasoning, so a high or low score can be investigated and corrected.

The slide's two policy Q&A rows are reproduced here in text:

The report also preserves the source documentation and resource use for each answer:

The batch contract example in the image uses the same method: one redline correctly adds and explains the required liability cap, while another misses an automatic-renewal risk in both the redline and the analysis.

The low-scoring examples give the team something specific to fix. Experts inspect whether the source, expected behavior and judge reasoning are right, then the engineering work addresses the failure.

Judge the consequence, not just the wording

A single score can hide an important failure. A minor formatting problem differs from an incorrect customer commitment. A mostly correct answer can still omit the exception that controls the decision.

We choose task-specific measures and rubrics. These may examine completeness, factual accuracy, citations, unsupported claims, missed requirements, inappropriate actions, false alarms, useful escalation or specialist review effort. Deterministic checks can verify totals, required fields, schema rules and authorization conditions where appropriate.

In the lending example above, the answer allowing a $75,000 approval against a $50,000 limit is fluent and responsive, but it invents authority the employee does not have. The judge gives it a low score because of that operating consequence, regardless of how well it is written.

Use model judges with expert calibration

An LLM judge can help assess many outputs against an agreed rubric. It should apply the standard the client and engineering team have defined. It does not establish the standard by itself.

We compare model judgments with expert reviews, investigate disagreement and revise the rubric or evaluator where needed. We preserve enough information to understand which judge and instructions produced a score. Important failure dimensions may need separate assessment instead of one overall number.

People remain necessary, particularly for ambiguous expert judgments and consequential errors. Conventional checks are often better for exact calculations or required conditions. A combination of expert review, software checks and model assessment can provide more coverage than any one alone.

Diagnose before adding complexity

The evaluation directs the next engineering choice. A failure may have several causes:

• The user's task is ambiguous or missing an essential fact.
• The source is absent, stale, contradictory or outside the user's permissions.
• Document preparation lost a heading, exception or table relationship.
• Retrieval selected the wrong material or missed a relevant definition.
• A calculation or specialist function belongs in a suitable tool.
• The prompt, model or workflow fails despite having the right information.
• Business owners have not agreed on the intended behavior.

These causes call for different actions. Better retrieval will not resolve an unclear question. A larger model will not choose the company's calculation policy. More orchestration can increase cost and failure opportunities without solving a missing-information problem.

We make a targeted change and compare performance. We also check working cases so an improvement does not quietly break another part of the system. The architecture guide explains the shared capabilities behind these workflows; Workbenches and Coaches bring them into everyday work.

Treat hallucinations as reliability failures

A hallucination is false or unsupported generated content, such as an invented policy, fact or source. It is one form of unreliable behavior. Applying the wrong rule, omitting a controlling exception, using stale information or exceeding the user's authority can be just as consequential.

PDD addresses these failures through the same engineering process: establish the expected behavior with the client's experts, include the relevant cases in the evaluation and diagnose what caused the failure. Preserve source versions, retrieved evidence, tool results and outputs so the team can identify the correction. A citation needs to support the actual claim; a fluent answer or confident model judgment is not enough.

Calculations, authoritative lookups and access checks belong in controlled tools where appropriate. Tool failures and missing information need explicit handling. A timeout is not a zero balance, and an incomplete search does not establish that no record exists.

The agreed behavior includes how the system recovers: clarify the request, identify missing information, hold a draft, retry an operation or escalate to an expert with the evidence and decision needed. Production review feeds those findings back into the system and its evaluations. Hallucinations are part of the continuing reliability work, rather than a separate problem with a separate methodology.

Reduce the burden on client experts

Expert participation is essential, but we make it easier to contribute. Engineers can prepare representative work, expected and actual results, source evidence and a concise explanation of the unresolved question. Experts can review familiar documents or tables instead of learning a new technical environment just to give feedback.

Word, Excel, Teams and other approved tools can support that review. A complex task may also benefit from a maintained context file. The useful choice is the one that lets the responsible person inspect the evidence and make the needed decision promptly.

The client still needs to provide time and authority. An unavailable reviewer or unresolved disagreement can become the real constraint on progress.

Pull the risk forward for an informed investment decision

Our goal by the end of the first 30 days is a performance report that helps every major stakeholder understand how the system is expected to work in production. Product, operations, compliance, security, executive leadership and the CTO can inspect actual inputs, expert-validated expectations, system outputs and the evaluation reasoning.

The question is whether the organization sees the potential impact, understands the remaining risks and wants to pursue the work. Missing data, conflicting expectations or inadequate behavior should surface now, while the investment is manageable. The client can continue, adjust the approach, narrow the scope or redirect effort to another opportunity.

This is risk mitigation through reliability engineering. The client should not have to wait six months to make an informed decision. Pulling AI risk forward explains the purpose of the first-month review and how it differs from negotiated cancellation terms.

The same framework supports technology decisions. Switch the model, rerun the cases and compare performance and cost side by side. Changes to prompts, tools, sources or interfaces go back through the agreed cases.

Checkpoint 3: Scale reliability in production

Our approach is to launch when the system mostly works, with human review of critical decisions, then improve rapidly from real production feedback. The often-used 80% to 95% progression is a mental model for that learning, not a universal threshold or promised result. Why we launch and improve in production explains the reasoning and the changes teams can make in days and weeks.

We launch to a small initial group once the workflow and operating controls are ready. Humans review all critical decisions before they reach customers or operations. We do not wait for perfection across every future case; we define a useful scope and keep consequential decisions under review.

Production introduces real questions, documents and exceptions that the development examples could not anticipate. Expert review improves the system and trains an LLM auditor, or SME agent, to check live work against the expert's standards. In a batch process, it can compare the input, the AI draft and the expert's final output. In question answering, it reviews interactions, retrieved sources and supporting context.

The auditor flags likely problems at scale. Experts review exceptions and samples and improve its guidance. Without production review, the team is waiting for user complaints to discover failures.

Checkpoint 4: Turn production feedback into improvements

Three layers of automation let a small specialist team maintain several applications:

1. Regression evaluation: agreed cases run when prompts, tools or workflows change, catching regressions before release.
2. Production review: the LLM auditor checks live output, with expert review of exceptions, samples and scoring.
3. Developer assistance: a developer agent clusters recurring issues and proposes changes to context, retrieval, prompts, tools or code. Developers approve the fixes and rerun validation before release.

A feedback signal is not an automatic policy change. The responsible expert and engineer decide whether to correct the source, guidance, workflow, tool or individual output. Useful new failures become evaluation cases. This is continuing reliability engineering as the business changes.

What a client learns

PDD gives a client a practical way to ask where the system works, why it fails, which improvement matters and whether a change is safe to release. That capability belongs with the delivered system and supports subsequent applications.

It also separates engineering performance from business performance. Reliability, cost and review measures guide the system; business reinvention connects the work to its wider economic purpose. Both inform continuing investment.

The dated public PDD guide includes an example performance report and implementation material. Our research record places that guide in the history of the method. The engagement guide describes how the client and Prolego share the work.