Probability of default in plain language

How to study this topic

Probability of default, or PD, is the bank's estimate of how likely it is that a borrower or counterparty will default within a defined time horizon under a defined default rule. The phrase may sound technical, but the banking meaning is practical. A bank uses this concept to decide how much risk it is taking, how much loss it may face, how to price or limit exposure, when to refer a case, how to monitor portfolios and how to explain credit decisions.

Keep the scope banking-first. This chapter is about lending, borrowers, counterparties, credit obligations, portfolios, limits, collateral, repayment, arrears, provisions, capital, governance and customer treatment. It is not a payments chapter. Transaction behaviour may appear only as account conduct evidence where it genuinely supports credit risk.

A learner should finish this topic able to explain it to a credit analyst, business analyst, data engineer, model validator, underwriter, collections manager and auditor. Plain language matters because credit-risk models are not useful if only modellers understand the answer.

The plain language meaning

PD answers the question: how likely is this borrower or counterparty to default within the horizon we are measuring? It is not the amount the bank will lose. It is not the exposure amount. It is the likelihood of default, given a definition of default and a time horizon.

The concept must always be tied to purpose. A number without purpose is dangerous. A PD used for application decisioning may differ from a PD used for IFRS 9, capital or portfolio monitoring. An LGD used for pricing may differ from a downturn LGD view. An EAD for stress testing may differ from day-to-day exposure monitoring. Scorecards also differ by product, portfolio and decision point.

Plain language does not mean weak explanation. It means the explanation should remain accurate without hiding behind formulas.

Source systems and evidence

Useful source areas include borrower identity, credit application data, income and affordability evidence, repayment history, arrears status, risk rating, bureau attributes, account conduct, financial statements, sector data, macroeconomic variables, and watchlist indicators. A credit-risk chapter depends on controlled data because every input can change the risk view. Income evidence, arrears data, utilisation, collateral value, limit data, customer identity, bureau information and case outcomes all need clear source ownership and timing.

The bank must know which source is authoritative. A front-end application may show what the customer declared. A document-verification platform may show what was evidenced. A core loan system may show what was booked. A collections system may show what happened after stress started. A risk engine may show the rating and score. Finance may show impairment treatment. These views must be mapped, not casually mixed.

The source question becomes sharper when AI and ML are used. If a model learns from a field, the bank must know whether that field is complete, stable, corrected, overridden, refreshed and legally usable for the purpose.

Key inputs and calculations

Key inputs include borrower identity, credit application data, income and affordability evidence, repayment history, arrears status, risk rating, bureau attributes, and account conduct. The calculation must define the time horizon, observation period, product scope, customer population, exclusion rules and treatment of missing values. Without these, the same concept can be calculated in several different ways and produce conflicting results.

For PD, the bank needs a clean default definition, a reliable observation window, good historical outcomes, rating or score calibration, and clarity on whether the model is point-in-time, through-the-cycle or hybrid. A PD that looks mathematically neat but uses weak default labels is not trustworthy.

The formula is only one part. Banking interpretation, data quality and governance decide whether the output is safe to use.

Controls before use

Controls should include default definition, observation window, rating philosophy, calibration sample, through-the-cycle or point-in-time view, and outcome label quality. These controls must run before the concept feeds a model, decision engine, risk report, provisioning process or strategy review. Technical checks are not enough. The bank must check whether the value makes sense in credit terms.

Important checks include population coverage, source reconciliation, date alignment, treatment of overrides, treatment of outliers, missingness analysis, validation against realised outcomes and monitoring of drift. Credit-risk models can fail slowly. They may not throw a system error. They may simply become less aligned with borrower behaviour or economic conditions.

The bank should also define who can override the model, how overrides are recorded, and how override performance is reviewed. Human judgement can improve credit decisions, but undocumented override culture can damage validation.

How it supports bank decisions

Common uses include credit approval, risk-based pricing, limit setting, IFRS 9 staging, CECL analytics, capital calculation, portfolio monitoring, early warning, and collections strategy. Each use has a different control requirement. A model used for internal portfolio insight may need one level of governance. A model used for credit approval, regulatory capital, provisioning or customer treatment needs much stronger evidence, validation and monitoring.

PD is central because it influences the likelihood side of credit loss. It can affect approval, pricing, limit decisions, IFRS 9 staging, capital and early warning. A small calibration error across a large portfolio can become material.

The output should be explainable to the decision owner. If a credit manager cannot understand why the model changed a view, the bank has a governance problem even if the statistical result is strong.

Provisioning, capital and portfolio view

Credit-risk concepts matter beyond individual decisions. They feed portfolio monitoring, risk appetite, concentration review, stress testing, capital planning and expected credit loss. The same borrower-level evidence can roll up into management and regulatory views.

IFRS 9 expected credit loss uses credit-risk movement to decide whether a financial asset remains in a 12-month expected loss view or moves into lifetime expected loss because credit risk has increased significantly. That makes data timing, default definition and risk movement important. A poor risk signal can affect provisions and reported performance.

Capital frameworks also care about credit-risk parameters. PD, LGD and EAD are not classroom abbreviations. They are part of how banks understand expected and unexpected loss, risk-weighted assets, portfolio quality and risk-adjusted return.

Customer and conduct impact

Credit-risk models affect customers. They can approve credit, restrict credit, increase price, reduce limit, refer for manual review, trigger collections activity or identify customers needing support. A wrong model can harm a customer by granting unaffordable credit or by denying reasonable credit without a fair basis.

Fairness is not solved by removing obvious sensitive fields. Proxies can appear through income, geography, employment type, channel usage, account history, product access or missing data. The bank should review whether the model treats customer groups fairly and whether limitations are visible to decision-makers.

Human review is important where impact is high. A score can support judgement, but the bank remains accountable for the decision.

Validation and monitoring

Validation should review concept, data, methodology, calibration, discrimination, stability, limitations and use. It should not only ask whether the model predicts. It should ask whether the model is suitable for the bank's portfolio, product, policy, customer population and decision purpose.

Monitoring should compare predicted outcomes with actual outcomes. For PD, defaults should be compared with predicted default rates. For LGD, realised loss and recovery experience should be reviewed. For EAD, drawdown and exposure at default should be tested. For scorecards, approval quality, referral rates, override outcomes and portfolio performance should be monitored.

If performance deteriorates, the bank may need recalibration, redevelopment, policy adjustment, overlays, tighter controls or temporary restrictions. Model monitoring must have a response path.

Common mistakes

The first mistake is confusing the parameter with the whole credit decision. PD, LGD, EAD and scorecards are decision inputs, not the entire decision. The second mistake is using weak labels. The third mistake is ignoring data timing. The fourth mistake is assuming a score remains valid after products, policy or economic conditions change.

Another mistake is treating a model as neutral because it is quantitative. Credit models reflect historical data, policy decisions, source availability, customer access and economic cycles. The bank must challenge whether the model learned credit risk or learned old operating patterns.

The final mistake is failing to explain limitations to users. A model can be useful with limitations if users understand them. A model becomes dangerous when limitations are hidden.

Practical banking example

A bank reviews a personal loan application. The applicant has stable income, low existing debt and clean repayment history. The PD model estimates a low likelihood of default. That does not automatically approve the loan. The bank still checks affordability, policy rules, fraud indicators, bureau data freshness and any manual referral conditions.

The practical point is that credit-risk models support judgement. They should make banking decisions more consistent and evidence-based, but they should not remove responsibility from the bank.

Bank-ready checklist

Before using this concept in production, ask: is the definition clear, is the population right, are sources authoritative, are time windows correct, are labels validated, are overrides governed, are missing values explained, are customer impacts reviewed, and can the result be reproduced later?

Then ask: is the model calibrated, independently reviewed, monitored, documented and approved for this exact purpose? Is it being used for approval, pricing, provisioning, capital, collections or internal insight? Has the bank matched controls to impact?

If the answers are strong, the concept is bank-ready. If not, the model may still produce numbers, but the bank should not treat those numbers as trusted credit-risk evidence.

The contract behind a PD number

A probability of default (PD) needs a borrower or facility population, a default event, a horizon, an observation date, and a use. "PD 2%" without those fields is an incomplete statement. The number could describe a one-year risk grade for capital, a point-in-time estimate for a lending decision, or part of an expected-credit-loss calculation. The model owner should say what the estimate applies to, how it is calibrated, when it was produced, and what conditions make it unreliable.

Consider an illustrative unsecured personal-loan portfolio. At application, the bank has verified identity, income, existing commitments, repayment history and information available from permitted sources. A credit policy checks eligibility and affordability. A separate model may estimate the chance of a defined default event over the next 12 months. The policy then decides whether to approve, refer or decline, using the model alongside other controls. The estimate is neither a promise that one person will default nor a substitute for affordability. A 2% PD describes risk across comparable exposures under the model's assumptions, not a prediction that two particular borrowers in a hundred can be identified with certainty.

The contract should identify whether the PD attaches to a customer, account, facility or group. A borrower with two loans may have one obligor rating but different facility terms. A lender may use distinct models for a new application and an existing account because the available evidence and decision differ. Analysts should avoid copying a PD from one use into another merely because both fields share the name. The purpose determines the population, time horizon, calibration and required evidence.

Constructing a dated development cohort

A bank can start with applications observed over a defined period. Each record needs an observation date, the information available on that date, a decision outcome and a later performance window. For an application model, the source data should represent the applicant before the lending decision. A collections status recorded months later is an outcome or an investigation fact, not an input that could have been known at application.

Suppose the illustrative cohort has 1,000 booked loans that can be followed for a full 12 months. If 30 meet the bank's documented default rule within that window, the observed default frequency is 30 divided by 1,000, or 3%. That calculation is a portfolio observation, not automatically the calibrated PD for every loan. Individual estimates can differ by grade, and the cohort may not represent today's applicants. The example also has selection bias: rejected applicants were never booked, so their repayment outcome is not observed in the same way. A model built only from approved cases cannot assume the rejected population behaves like the accepted population.

The analyst records exclusions before estimating a rate. Accounts with incomplete observation, duplicate facility identifiers, a changed product definition or uncertain default dates require a stated treatment. Removing every account that closed early can distort the cohort; counting every short-lived account as a non-default can do the same. The denominator and follow-up rule must be reproducible. A back-test must compare estimates made at the cohort's observation dates with outcomes that had time to mature, rather than scoring the current surviving book and treating missing historical accounts as good.

Defining default without moving the target

A PD is only as clear as its default event. The institution's applicable prudential, accounting and internal definitions can differ, so the model documentation must name the one used for each purpose. A definition may include specified delinquency, an unlikely-to-pay assessment, restructuring or other qualifying event under the governing framework. An analyst should not infer the rule from a dashboard label such as "bad" or "delinquent". They need the exact source status, effective date, treatment of cures and mapping from operational events to the model target.

Imagine a loan that becomes seriously overdue, is restructured and later returns to regular payments. The event date and later cure need separate records. Erasing the original event because the account recovered would change the training target. Conversely, counting a temporary data-feed delay as a default would inflate it. Credit operations, finance and risk may record different milestones for the same account. The bank needs a reconciled event history, with each definition applied consistently to the corresponding model use.

A default label can be corrected after investigation. The training dataset should retain the earlier value, correction reason and effective date. For performance reporting, the owner should explain whether results use the first published labels or the corrected final labels. That distinction prevents a seemingly improving model from being an artifact of revised case coding. The Basel Framework's internal ratings-based chapters define risk components and minimum requirements for banks permitted to use that approach. A training example must not imply that every lender uses an internal ratings-based capital model or that one internal default flag automatically satisfies every regulatory definition.

Ranking borrowers and calibrating probabilities

A score can rank applicants without producing a reliable PD. Imagine two risk bands. Band A has lower observed defaults than band B in a test cohort, so the score discriminates in the expected direction. If the model assigns 1% to A but 5% of mature A exposures default, its probability calibration is weak even if the ranking is useful. Calibration asks whether estimated frequencies align with observed outcomes for comparable, sufficiently mature groups. Discrimination asks whether higher-risk cases tend to receive higher predicted risk. Both matter, and neither proves a credit policy is fair.

A validator may compare predicted and observed frequencies by score band, product, origination period and other relevant segments. Small bands have noisy observed rates; one event can move the percentage sharply. A chart should show the count of accounts and defaults as well as the rate. Averages may conceal that a model works on established customers but miscalibrates borrowers with limited history. If the production population differs from the development sample, the validator should investigate the change before applying a global recalibration.

A PD can be a point estimate, a grade-level estimate or part of a term structure. The bank should document whether it uses a point-in-time view sensitive to current conditions or a longer-run view intended to smooth a cycle. Neither phrase gives a free pass to change definitions without approval. A one-year PD estimated for a particular date cannot be stretched mechanically into a lifetime default probability by multiplying it by the number of years. Survival, changing borrower condition, prepayment, maturity and competing events alter the path. A term structure needs a method and validation suitable for its intended use.

Three different uses of the same language

Credit decisioning may use a PD estimate to sort cases into approved policy bands, set review priority or support pricing. The bank still tests affordability, identity, legal eligibility and product rules. A high PD can trigger a referral without itself becoming the legal reason communicated to a customer. Where U.S. Regulation B applies, 12 CFR 1002.9 requires specific principal reasons for adverse action. A model's internal probability is not an adequate substitute for the actual factors and policy findings that produced the decision. Local notice rules differ outside that jurisdiction.

Expected-credit-loss accounting uses default risk as part of an estimate of cash shortfalls. Under IFRS 9's impairment approach, 12-month expected credit losses reflect lifetime cash shortfalls associated with default events possible in the next 12 months. They are not simply the cash shortfalls expected to arrive during that year. A significant increase in credit risk since initial recognition generally moves the measurement to lifetime expected credit losses. IFRS 9 does not mandate one explicit PD model for deciding whether risk increased significantly. Finance also needs exposure, loss severity, discounting, forward-looking information and accounting policy. The PD alone is not the provision.

Prudential capital under the Basel internal ratings-based approach has its own permission, definitions, calibration and supervisory framework. Its PD may not be interchangeable with an application score or the forward-looking estimate used in an IFRS 9 impairment model. A bank can use a common data foundation while maintaining separate transformations and controls for each purpose. The analyst should label reports by use: "application decision PD", "impairment PD" and "IRB capital PD" are not duplicate fields merely because they share a mathematical form. The applicable jurisdiction's implementation of Basel standards governs actual capital treatment.

A worked decision with controlled assumptions

Take a fictional applicant, Noor, seeking an unsecured loan. The verified application shows stable income, existing monthly commitments and a short repayment record. The approved model returns a one-year PD of 2.4% with model version M4. The bank's illustrative policy does not approve solely on that number. An affordability calculation finds sufficient capacity under the bank's own rules, while a thin-file flag calls for human review. The underwriter requests additional evidence and records a referral. These values are teaching examples, not a recommended cut-off, a universal affordability test or a real customer's data.

An audit trail for Noor's case should show the application timestamp, sources and dates of income evidence, product requested, feature values as available at decision time, model version, score-to-PD mapping, policy version, referral reason and final underwriter action. If a bureau response arrives after the initial score, the bank either re-scores under its approved process or preserves the earlier result and treats the later evidence separately. It should not overwrite the first decision record and then claim the new data explains the original action.

Now imagine the bank later changes the model so the same inputs yield 3.1%. The analyst needs to distinguish a recalibrated probability from a changed ranking, altered input data or a revised default definition. A comparison across model versions should replay identical dated cases and report differences by product and customer segment. A higher PD for Noor does not prove the new model is wrong. It demands evidence about calibration, validation, intended use and the policy effect. If the new model would move many applicants into manual review, operational capacity is part of the release assessment.

Data lineage from a source record to a PD

A PD service often receives derived features rather than raw bank records. An income feature may come from verified documents, payroll credits or declared values, each with different evidence. An arrears feature may come from a servicing system whose status is updated after a payment posting. A credit-bureau attribute may be refreshed on a different schedule. The feature contract should name the source, transformation, observation window, missing-value treatment, effective time and owner. A field called "current arrears" is not point-in-time evidence unless "current" is defined relative to the scoring event.

A validator should be able to trace one scored case backward: output to model version, features to transformation version, transformations to source records, and source records to their effective dates. This is also a software acceptance concern. Tests should include a value exactly at a band boundary, a missing bureau response, an income correction, two facilities for one customer and an account that entered default after the score date. A test with all fields present and no exception is not enough to prove safe deployment.

Privacy and permitted use belong in the lineage. The fact that a transaction or account field exists in the bank does not mean it is appropriate for every credit model. The owner must establish the lawful basis, purpose, retention and access conditions in the relevant jurisdiction. A model may also learn indirect proxies for sensitive characteristics. A fairness review needs to examine outcomes and error patterns across legally and appropriately assessable groups, with limitations recorded where data cannot be used. An explanation method can describe feature contributions without proving fairness or lawful data use.

Monitoring a PD after launch

A PD model can remain technically available while its risk estimates deteriorate. The bank should monitor input completeness, score distributions, override rates, approved population and decision volumes before the outcomes mature. Once enough time has passed, it can compare predicted and observed defaults for dated cohorts. The monitoring plan should state which segments matter, what evidence triggers investigation, who decides an action and how the action is documented. A single population-stability statistic cannot identify whether the cause is data mapping, underwriting policy, economic conditions or customer mix.

Suppose a new digital channel attracts more applicants with limited bureau history. The share of missing bureau values rises, and the model refers more cases. The immediate question is whether the data feed changed or the customer population did. The owner checks channel onboarding, source availability and missing-value treatment, then examines outcomes when they mature. Retraining on the new flow before understanding the missing data could normalize a collection problem. If the model is outside its approved population, the bank may restrict use or route cases through an approved fallback while investigation proceeds.

Governance should be proportionate to the model's use and risk. The Federal Reserve's revised SR 26-2 guidance superseded SR 11-7 in April 2026 and emphasizes risk-based model governance, validation and monitoring for the banking organizations in scope. It is not a universal prescription for every bank or every AI system. A model inventory should record purpose, owner, limitations, validation findings, approval conditions, monitoring results and material changes. An unresolved issue is not closed by a dashboard changing colour; the owner needs evidence of investigation and a decision about continued use.

Uncertainty in small and changing populations

Observed default rates are estimates with sampling uncertainty. Suppose a specialist product has 100 mature borrowers and one recorded default. Its observed rate is 1%, but one additional default would double that rate. Treating the 1% as a precise borrower-level PD would hide how little evidence is available. The model owner should report counts, time window and uncertainty alongside a segment rate. Where the available history is too thin, the bank may use an approved broader pool, external evidence or a conservative treatment, subject to the applicable model and policy framework. The choice should be documented rather than disguised as a fully estimated parameter.

Pooling also has limits. Combining two products merely to obtain more defaults can conceal different borrower behaviour, underwriting standards or collection practices. The analyst compares the candidate pool's definitions and outcomes, then records why cases are similar enough for the intended use. A sudden rise in defaults during economic stress may call for a forward-looking adjustment or a more careful scenario analysis. It does not justify editing historical labels to make a back-test look stable. Conversely, a brief period with no defaults does not establish that the true PD is zero.

Uncertainty should travel with the result. A policy owner may decide that a model is suitable for portfolio-level monitoring but insufficient for an automated individual decline in a thin segment. The decision record can preserve a referral rule or extra evidence requirement. The bank should also track whether a model's uncertainty changes as its customer mix, product terms and external conditions move. These decisions depend on the institution's risk appetite and applicable rules; no example rate in this chapter defines a supervisory minimum.

Analyst acceptance cases

The business analyst can convert the PD definition into a set of testable statements. The same source records, feature version and model version should reproduce the same probability. A record with an outcome after the scoring date must not alter historical features. A customer with two facilities should not be double-counted as two borrowers if the target is obligor-level default. A model that returns no score because a required source is unavailable must not silently produce a safe-looking zero. Each failure needs a defined service response and bank-approved referral or contingency action.

The analyst should test changes at the interfaces as well as within the model. A new income code can change an input without breaking the API. A revised default status in servicing can change observed outcomes without changing the scorer. A threshold change in policy can change approval rates even when model PDs remain identical. The monitoring pack must separate these mechanisms so the owner does not attribute a business-policy change to model drift. Test evidence should include a dated sample, expected result, actual result and reviewer sign-off.

A useful PD report ends with its contract: population, default definition, horizon, observation date, calibration method, model and policy versions, exclusions, uncertainty and intended use. It shows the relationship to exposure at default and loss given default without treating any one component as the entire credit decision. A reader can then use a probability as a controlled estimate, challenge its assumptions and trace what the bank actually did with it.

Banking practice note on data definition

For probability of default, data definition matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

The practical discipline is to keep source fact, credit-risk interpretation, model estimate and business action separate. Source facts come from areas such as borrower identity, credit application data, income and affordability evidence, repayment history, and arrears status. The credit-risk interpretation explains what those facts mean. The model estimate turns that interpretation into a score, probability, severity, exposure or ranking. The business action decides approval, referral, monitoring, support, pricing, limit or reporting treatment.

This separation helps the bank challenge the result properly. When a score changes, the bank can ask whether borrower behaviour changed, source data changed, policy changed, model calibration changed or economic conditions changed. That is the kind of clarity serious banking AI needs.

Banking practice note on model use

For probability of default, model use matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on customer impact

For probability of default, customer impact matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on portfolio control

For probability of default, portfolio control matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on validation

For probability of default, validation matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on monitoring

For probability of default, monitoring matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on governance

For probability of default, governance matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on audit evidence

For probability of default, audit evidence matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on economic conditions

For probability of default, economic conditions matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

Banking practice note on human judgement

For probability of default, human judgement matters because credit risk is not only a model output. It is a banking responsibility that connects borrower behaviour, product policy, capital, provisions, customer treatment, collections, finance reporting, risk appetite and audit evidence. If one part is weak, the model result can look precise while the decision remains fragile.

A probability for a defined cohort

An illustrative 4% twelve-month probability of default means that among comparable loans scored under a stated definition and followed for a year, about four of 100 may meet that definition on average. It does not say which four, and it is not a statement that any one customer is 96% safe. The population, horizon, default event and calibration period matter. A 90-day delinquency target and a write-off target are not interchangeable labels.

In a validation exercise, group 1,000 booked loans assigned probabilities around 4% and follow them to a mature twelve-month outcome. If 60 meet the definition, the observed 6% warrants investigation of calibration, cohort change and uncertainty. If only 800 have mature follow-up, treating the other 200 as non-default will bias the comparison. Report counts and exposure, and separate a rank-order measure from calibration. A model can order risk well yet systematically understate absolute probability.

Compare two applicants with similar scores but different missing-income evidence. A PD estimate reflects training data and permitted features, not affordability proof or automatic approval. Inspect population coverage, reason evidence, overrides and later outcomes. If a policy changes which applicants are funded, future booked-loan labels become selected by that policy; document the evaluation limit before claiming improvement.