- Article ID: NU54-047
- Section: Hot
- Slug: public-benefits-algorithm-decision-audits
- Prepared: 31 October 2026
- Evidence checked: 31 October 2026
- Dek: Buying an eligibility engine means buying its mistakes, too. A public agency needs to reconstruct how a decision happened, explain it to the person affected and repair every case touched by the same defect.
<!-- ARTICLE_BODY -->
The decision that has to survive a challenge
A public-benefits system can process a million records and still be unable to answer one person's question: why did you stop my payment? The database may contain the outcome. The supplier may retain the software. The agency may possess a policy manual. None necessarily preserves the chain connecting this person's circumstances, the applicable rule, the information available that day and the action actually taken.
That missing chain is not merely a transparency problem. It is a product defect in a system whose outputs change people's access to money, care or other essential support. An eligibility decision has to be administratively usable after the processing job finishes. Someone must be able to examine its basis, contest an incorrect fact, distinguish a calculation error from a policy disagreement and implement a correction without starting the entire application again.
A recent federal audit supplies a timely reminder that the problem is broader than fashionable artificial intelligence. In a Medicaid report publicly released on September 17, 2026, the U.S. Government Accountability Office described weaknesses in oversight of states' corrective action plans for eligibility errors. Its findings concerned caseworkers, processes and eligibility systems, not a finding that AI caused every error. That distinction matters: a complete audit follows the decision process rather than stopping at the component advertised as intelligent. GAO's Medicaid eligibility review.
The procurement question is therefore not simply whether software can predict or calculate accurately. It is whether the agency can explain and repair the administrative consequences when something goes wrong. This article examines that design question, not the merits of any individual's benefits claim or jurisdiction-specific legal advice. Rules and appeal deadlines differ across programs. A sound technical architecture makes it possible to apply the right rules; it does not replace the legal work of identifying them.
First distinguish the systems hiding inside the word algorithm
An eligibility platform may contain several kinds of automation with radically different functions. A rules engine compares facts against a policy. A matching service links a record to another database. A statistical model ranks cases for review. A document system extracts numbers from uploaded evidence. A workflow scheduler decides which queue receives the case. A notice generator converts an outcome into a letter. Calling the whole package an algorithm obscures where discretion and error enter.
Consider a hypothetical applicant who reports irregular earnings. Optical character recognition reads a payslip incorrectly. A data transformation treats a weekly amount as monthly. A matching service adds earnings belonging to another person. The eligibility engine faithfully applies its configured threshold. Finally, the notice generator displays a generic income reason. The rules engine may have performed exactly as designed while the resulting decision is wrong. Testing its arithmetic alone would miss the failure.
The agency needs a component map tied to administrative actions. Which components can recommend investigation? Which can hold payment? Which can change the amount? Which merely display information? An inconspicuous queue rule that postpones a case indefinitely may have a more serious practical effect than a sophisticated classifier whose output is never used. Measuring model accuracy while ignoring workflow delay mistakes the technical centerpiece for the whole service.
GAO's 2021 AI accountability framework separates governance, data, performance and monitoring. Those categories offer a useful starting point for asking questions across the system rather than demanding one magic accuracy number. They are an accountability framework, not a certification that a particular procurement is lawful or effective. GAO's AI accountability framework.
A supplier inventory should also identify conventional code. If attention is confined to machine learning, ordinary tables, interfaces and scheduled jobs can escape review despite making the legally consequential calculation. The appeal trail has to cross component boundaries because the person challenging the decision experiences one agency action, not a collection of separately warranted software modules.
A risk score is not an eligibility finding
A model can be useful for deciding where to look without being qualified to decide what happened. Ranking applications by suspected irregularity is a resource-allocation task. Determining whether a person satisfies a statutory condition is a different task. Finding intentional deception is different again. The distinctions should appear in both the architecture and the language used by staff.
The United Kingdom's published record for its Universal Credit Advances model illustrates one possible separation. The record describes a classifier that refers potentially high-risk advance requests for human examination. It says reviewers are not shown the risk rating or told that a referral came from the model, and distinguishes an advance decision from eligibility for the associated Universal Credit claim. Those are descriptions by the department of its own process, not independent proof that every intervention works as intended. DWP's algorithmic transparency record.
The design lesson is specific. A referral should create a question to investigate, not silently manufacture an answer. If the downstream interface labels the person fraudulent before evidence is assessed, the nominal separation between model and decision collapses. If the payment hold lasts until the applicant disproves an unexplained suspicion, a supposedly advisory tool may have acquired decisive power through workflow design.
Procurement testing should trace a flagged case through to its actual consequence. Does the flag prompt an evidence request? Does it automatically stop a payment? Who can remove it? Can the reviewer see the underlying records? Does the system preserve a difference between suspected inconsistency, verified discrepancy, ineligibility and fraud? These categories should not be interchangeable database values.
Nor should a non-flag be treated as proof that a case is correct. A screening system has both false positives and false negatives. A complete quality program examines some unflagged cases as well as flagged ones, while respecting the burden imposed by extra checks. Otherwise the agency learns only about the cases its own system has already chosen to scrutinize.
The smallest useful decision record
The appeal trail is not a demand to retain every byte forever. It is a demand to retain the evidence needed to reconstruct a consequential action. A practical decision record begins with the decision identifier, person or case identifier, program, action, effective date and time. It then links the applicable policy version, software configuration and relevant facts to the calculation or reasoning that produced the action.
Facts need provenance. An income amount should not appear as an unexplained number. The record should identify whether it came from a declaration, a payslip, an employer feed or another agency, the period it describes, when it was obtained and whether it was verified or disputed. A value copied between systems should retain enough lineage to discover that two apparently independent confirmations actually originated from the same erroneous source.
The distinction between event time and processing time is essential. A wage payment may concern work performed in one month, be reported in another and reach the eligibility system later still. Which date matters is a policy question. The system must preserve the dates rather than force reviewers to infer them from the order in which database rows happen to appear.
The decision record should also show the human contribution. A reviewer may accept an extracted value, correct a household relationship or override an automated recommendation. Recording only the final status hides these interventions. Recording an intervention without its reason hides the basis for learning whether it was justified. Neither approach produces meaningful accountability.
A useful record is structured enough for systematic analysis and readable enough for a caseworker. A massive technical log can be as unusable as a terse outcome code. The contract should require an export that joins the relevant pieces into a coherent case chronology, with clear distinctions among original evidence, machine-produced suggestions, staff findings and later corrections. The resulting record must remain intelligible after the supplier's interface changes.
Explanations must identify something the person can contest
There is a difference between describing a model and explaining an administrative action. A technical document may list input variables and overall performance. A person whose benefit was reduced needs to know which facts and rules were applied to their case. A statement that an automated process detected inconsistency does not reveal whether the dispute concerns an address, a payment period, a household member or a missing document.
For Medicaid notices covered by the provision, 42 CFR 431.210 requires specified information including the intended action, its effective date, specific reasons and supporting regulations, alongside hearing-related information. That is a program-specific legal requirement, not a universal template for every public service. It nevertheless makes the engineering challenge concrete: the notice system has to receive usable reasons, not merely a numerical score. Current eCFR text of the Medicaid notice provision.
A hypothetical adequate explanation might identify the earnings period and amount used, explain how that amount affected a named eligibility condition and tell the applicant how to dispute the underlying information. It need not disclose another person's protected records or the detailed mechanics of a fraud-detection model. It does need to make the actual basis of the action understandable enough to challenge.
Feature-importance charts are rarely a substitute. A variable can influence a statistical score without establishing a legally relevant fact. A local explanation may also change when correlated variables are represented differently. The agency should not confuse a model's sensitivity analysis with the evidentiary reasons for withholding support.
Notice testing should therefore include people outside the development team. Ask them to identify the action, the disputed fact, the next available step and the time boundary. If readers cannot do so, the system has not explained the decision merely because the correct legal vocabulary appears somewhere in the document.
Human review needs authority, information and time
A human signature is weak evidence of human judgment. Reviewers can be present in the workflow yet unable to change the result, see relevant records or obtain clarification. They can also face production targets that make independent assessment practically impossible. A process diagram showing a person between model and decision is not enough to establish a meaningful safeguard.
Review authority should be explicit. Can a reviewer reject the recommendation without supervisory permission? Can they correct a source value? Can they pause an adverse action while a mismatch is resolved? When an exception requires escalation, is there a functioning route with a defined response time? These questions concern the operational power of the reviewer, not the title on their badge.
Information design matters too. Showing a large red risk indicator before any evidence may anchor judgment. Hiding all machine involvement can create other problems if staff cannot understand why a case was selected. The appropriate arrangement depends on the task, but it should be tested rather than defended with the phrase human in the loop. Reviewers need relevant facts, known limitations and a way to record disagreement.
The Department of Labor's 2021 identity-verification guidance for unemployment insurance expressly addresses adjudication where identity is questionable. Among other things, it says fraud determinations may not be made by an automated system. This is specific guidance for that administrative setting, not a ban on every automated operation in benefits administration. DOL's identity-verification program letter.
Procurement acceptance should include a realistic workload exercise. Give reviewers difficult cases, contradictory records and a system outage. Observe whether they can reach and document a defensible conclusion. Count the time required. If the proposed staffing model cannot accommodate that work, the promised safeguard has not been funded. Automation may reduce clerical effort, but it cannot make legally significant ambiguity disappear by shortening the appointment slot.
A database match is an allegation about identity and time
Matching is often presented as a simple integrity measure: compare one file with another and investigate discrepancies. The technical difficulty is that names, addresses, identifiers and reporting periods are imperfect. A match can be technically correct at one level and misleading at another. Two records may belong to the same person but concern different months. A payment may be genuine but already corrected. A household relationship may have changed.
The match record needs to preserve its basis. An exact identifier match is different from a fuzzy name match. A partial birth-date match is different from verified identity. A supplier's confidence score should not erase those distinctions. Reviewers also need to know when the source was refreshed and whether the source agency later amended the record.
DOL's 2015 guidance on unemployment-compensation overpayment procedures discusses independent verification of information from federal computer cross-matches or other automatic processes before specified adverse actions. It also addresses investigation and the opportunity to be heard. The underlying lesson for system design is that ingestion and verification are separate states, even where the precise legal duties differ between programs. DOL's overpayment and individual-rights guidance.
A hypothetical matching error shows why. An employer feed reports a corrected wage record, but the receiving system appends the correction instead of replacing the earlier amount. The resulting total appears to show concealed income. The applicant cannot solve the problem by resubmitting the same payslip if the platform continues to trust the duplicated feed. The case requires a correction to data handling, not another demand for cooperation.
Acceptance tests should include duplicate records, late corrections, inconsistent date formats, reused addresses and incomplete identifiers. The goal is not to promise perfect linkage. It is to ensure uncertain matches remain uncertain until resolved, and that an upstream correction can propagate to every downstream decision that relied on the original information.
Measure the errors that the appeal system does not see
Appeal outcomes provide valuable evidence, but they are a selected sample. Some people do not recognize that an action is appealable. Some cannot obtain help. Some miss a deadline, abandon the process or find a different source of support. The proportion of appealed decisions overturned therefore cannot be read as the error rate among all decisions.
Suppose, hypothetically, an agency issues 10,000 adverse decisions. Five hundred are appealed and 200 are reversed. The reversal rate among appealed cases is 40 percent. It does not establish that 40 percent of all adverse decisions are wrong. Nor does the other calculation, 200 reversals divided by 10,000 decisions, establish a two-percent error rate. Both denominators answer narrower questions than the headline might imply.
A quality program needs independent sampling. It can select cases randomly, oversample specific risk areas and then use appropriate weights when estimating population rates. A targeted sample is excellent for finding a suspected defect but cannot automatically estimate how common that defect is. Sampling design, missing records and unresolved cases should be reported alongside the result.
The reference judgment also needs scrutiny. If auditors merely ask the original team whether its own decision was correct, the review can reproduce the same misunderstanding. Difficult cases may require a second reviewer, documented disagreement and adjudication against the applicable policy. Agreement between reviewers is useful evidence about consistency, but agreement alone does not prove substantive correctness.
Audits should distinguish incorrect approvals, incorrect denials, incorrect amounts, excessive delay and defective notices. Combining them into one score can hide a serious access problem behind a large volume of easy approvals. The cost of an error also depends on its duration and consequences. One wrongly delayed essential payment should not disappear statistically because thousands of routine status updates were processed correctly.
Fairness analysis begins with what can actually be observed
Group comparisons are necessary in many public-service evaluations, but missing data and selective observation complicate them. If the agency observes final outcomes only for people referred to investigation, it cannot assume those outcomes represent everyone who applied. If demographic information is incomplete, the people who disclosed it may differ from those who did not. A fairness table can look precise while answering only a restricted question.
DWP's July 9, 2026 effectiveness assessment of its Advances model is instructive about both claims and limits. The department reported that the model identified high-risk advances more effectively than its random comparison group and emphasized human decision-making. It also explained limitations in available equality data, including why some optional responses could not support its analysis. These are the department's assessment and experimental statistics, not a general guarantee of fairness or a finding about all benefits algorithms. DWP's 2026 effectiveness assessment.
An agency should identify the stages at which disparity can arise: application completion, identity checks, referral, requests for evidence, decision, payment and appeal. Equal final approval rates do not rule out unequal burdens earlier in the process. One group might need more appointments or wait longer to reach the same outcome. Conversely, a difference in referral rates does not by itself establish the cause or legal meaning of the difference.
Statistical significance is not a complete policy judgment. Large datasets can make tiny differences detectable. Small groups can experience substantial harms that a low-powered test fails to distinguish from chance. Report effect sizes, uncertainty and the administrative context. Where data cannot answer the question, identify that limit rather than treating absence of measurement as evidence of equal treatment.
Buy access to the evidence, not only access to the interface
A procurement can leave the agency dependent on its supplier for every contested case. The agency may own the data in principle yet lack the documentation, export tools or runtime environment needed to interpret it. A contract that promises transparency without specifying deliverables can fail precisely when a disagreement makes cooperation difficult.
Required deliverables should include the rule configuration, version history, data dictionary, interface mappings, decision-event schema and reproducible test cases. For statistical components, the agency needs a defined route to relevant model documentation and evaluation evidence. The necessary access may differ between public disclosure, authorized auditors and case adjudicators. Treating every audience as identical creates a false choice between publishing everything and revealing nothing.
Source code can help, but it is not sufficient. A source repository without the deployed configuration, dependencies and input transformations may not reproduce the system that made the decision. A proprietary external service can change behavior without the agency changing its own code. The contract should identify these dependencies and require change notification, version identification or another defensible way to preserve the historical decision basis.
Commercial confidentiality should be addressed before award. If a supplier cannot support the disclosure necessary for an agency's administrative obligations, that is a procurement incompatibility to resolve, not an excuse to discover after deployment. The agency also needs rights to obtain assistance during an appeal, inspect relevant records and continue operating if the contract ends.
Canada's Algorithmic Impact Assessment offers an example of a structured public-sector risk assessment that considers the system, decision, impact and data. Its requirements operate within the Canadian federal policy framework and should not be transplanted as universal law. For buyers elsewhere, its practical value is to demonstrate how impact questions can be made explicit before the tool is treated as ordinary office software. Canada's Algorithmic Impact Assessment.
Test the appeal before signing off the platform
The most revealing acceptance test may begin after the system has made a wrong decision. Create a deliberately flawed but realistic case. Send the notice. Have a tester challenge the fact. Ask a reviewer to locate the evidence, identify the applicable rule and correct the outcome. Then confirm that the payment, case status and future processing all reflect the correction.
This is not a demonstration with a rehearsed happy path. The case should include the complications that matter operationally: a record corrected after the original decision, a document uploaded under the wrong category, an inaccessible notice format, an interpreter request or a claimant who cannot use the online portal. The exercise tests whether the whole service can recover from error rather than merely issue decisions quickly.
Measure handoffs. How many teams must act? Where does the case wait? Does the appeal unit see the same evidence as the eligibility unit? Can a corrected value be overwritten by the next nightly import? Does a payment release require a separate action that nobody owns? The result is often a more useful performance measure than another benchmark on clean historical data.
The test should include a supplier exit scenario. Export a closed case and reconstruct it without the vendor's live interface. If the agency cannot do that, long-term accountability depends on a commercial relationship remaining available indefinitely. Records retention and archival obligations cannot safely depend on a subscription screen continuing to function.
The agency should also verify that corrections do not erase history. A reviewer needs to see what was known at the original decision and what changed later. Maintaining that distinction supports fair review and helps distinguish a genuinely wrong initial decision from a later change in circumstances. Both may require action, but they are not the same type of error and should not be counted as though they were.
One successful appeal can reveal a population-wide defect
An appeal is usually organized around one person's case. A software defect rarely respects that boundary. If a rule table uses the wrong date, a transformation drops a category or a matching routine doubles an amount, many people may have been affected. Correcting the successful appellant without looking for related cases leaves the underlying failure active.
Every substantiated systems error should trigger a scope investigation. Which versions were affected? During what dates? Which inputs activate the defect? Which actions depended on the faulty output? Can the agency identify the affected population reliably, or does incomplete logging require a broader review? The appeal trail becomes the basis for a repair campaign rather than a record of isolated exceptions.
A hypothetical example makes the distinction clear. An applicant proves that a change in household composition was received before a decision but ignored by a nightly job. The immediate remedy concerns that applicant. The systems question concerns every case with the same event ordering. Searching only for people who filed appeals would identify the most persistent challengers, not necessarily everyone harmed.
The repair process needs its own evidence. Record the affected cohort, the review method, corrected decisions, payments or other remedies, unresolved cases and notices issued. Re-run the relevant tests after the fix. A code change is not proof that the administrative consequences have been repaired; old incorrect states can remain in databases long after the triggering bug disappears.
Root-cause categories should be useful rather than defensive. Assigning every failure to user error can conceal an interface that predictably invites the mistake. Assigning every failure to the algorithm can conceal inadequate policy translation or staffing. The question is what combination of design, data, procedure and oversight allowed the wrong action, and what observable change will reduce recurrence.
Policy changes require temporal discipline
Benefits rules change. Thresholds are adjusted, definitions are clarified and emergency provisions begin or end. The system must apply the right policy to the right period, including when a case is reviewed retrospectively. Updating a single current rule table can make historical decisions impossible to reproduce and can silently apply today's policy to yesterday's circumstances.
Versioning should therefore include effective dates, not merely release numbers. A software release may contain several policy versions, each applicable to different periods. A later correction may need to recalculate only part of a claim. The system should distinguish the date a rule was approved, the date it took effect and the date the software implementing it was deployed.
Regression tests should cover boundary dates and transition cases. A payment period that straddles a change may require treatment different from either neighboring period. Rounding rules, frequency conversions and household changes can interact. These are not glamorous machine-learning problems, but they can determine whether an automated decision is right.
The change process should also preserve the policy interpretation. When an ambiguous instruction is translated into code, record who made the interpretation and what evidence supports it. Otherwise a future reviewer may see only the implementation and mistake a developer's assumption for an authoritative rule. Policy specialists and technical staff need a shared representation that can be examined without reverse-engineering production software.
An appeal trail should make it possible to answer two separate questions: did the system follow its configured rule, and was that rule the correct one to apply? A system can pass the first test and fail the second. Procurement warranties focused entirely on software conformity can miss that gap. The agency remains responsible for deciding which policy the product is supposed to implement and verifying that the decision survives translation into executable logic.
Privacy and auditability are not opposites
Detailed records can improve accountability while creating privacy and security risks. A benefits case may contain sensitive health, family, financial or identity information. The answer is not to abandon the appeal trail. It is to design access, retention and disclosure around specific purposes, so the people who need evidence can obtain it without exposing an entire case history unnecessarily.
Separate operational access from audit access. A quality reviewer may need a limited sample with masked identifiers. An appeal adjudicator may need the complete relevant record. A public performance report generally needs aggregate results rather than personal files. These are different products, and the system should not force staff to create them through improvised spreadsheet copying.
Logs themselves require protection. They can reveal who applied, what issues were investigated and which staff viewed a record. Access should be attributable, and changes to consequential records should be detectable. Retention decisions should consider the applicable legal obligations and the period during which a decision may need to be reconstructed. Keeping everything indefinitely is not a substitute for making those decisions.
Data minimization also improves reasoning. If the agency cannot explain why a field is needed for a decision, review or legally required record, collecting it may expand risk without improving the service. A large model input set can make a procurement look sophisticated while making provenance, correction and fairness analysis harder.
The appeal trail should be designed as a controlled evidence system, not a surveillance archive. Its purpose is to establish what action was taken, on what basis and how it can be corrected. Public accountability does not require broadcasting a claimant's circumstances. It requires an agency capable of producing the appropriate evidence to the appropriate person, with enough structure that privacy is protected by design rather than by refusing every request.
Delay belongs in the definition of error
A decision can eventually be correct and still arrive too late to perform the program's intended function. Automation often promises faster processing, but average turnaround can conceal a small group stranded in exception queues. Those cases deserve explicit measurement because complicated records are precisely where both human review and procedural protection matter most.
Track time from application to each meaningful event, not just from assignment to closure. A case can spend weeks waiting for assignment while the measured handling time looks excellent. Separate time awaiting information from time awaiting agency action, but examine whether the information request was necessary, understandable and deliverable. A clock stopped by an impossible request is not evidence of efficient administration.
Percentiles and aging distributions are more informative than a mean alone. Identify cases beyond a defined service threshold, repeated requests for the same evidence and referrals that have no assigned owner. Compare delay by case type and access channel. An online-first workflow may process uncomplicated applications quickly while creating severe barriers for people who need alternative routes.
The procurement should specify how the system detects and escalates stalled cases. A scheduled alert is useful only if someone can act on it. The agency needs a path for urgent review, a way to prevent duplicate work and a method for correcting the status that caused the blockage. Otherwise the software can produce an immaculate dashboard of overdue cases without changing their outcome.
Delay also belongs in model evaluation. A fraud screen might improve the yield of investigations while increasing the waiting time for legitimate applicants. The relevant question is the combined effect on accurate payment, improper payment prevention and access, not whether one classifier metric improved. Those tradeoffs should be visible to the officials making the decision rather than concealed inside a supplier's definition of success.
Test the boundaries, not just the historical average
Historical test data are useful, but they can preserve the blind spots of the process that produced them. If past decisions were treated as unquestionable truth, a new system can score highly by reproducing old mistakes. A procurement evaluation should identify which labels were independently verified, which reflect administrative convenience and which remain uncertain.
Boundary tests provide another line of evidence. Construct hypothetical cases that differ in one legally relevant fact and confirm that the result changes only when the applicable rule says it should. Change an irrelevant formatting detail and confirm that the outcome remains stable. A harmless extra space, an accented character or a different document order should not silently become an eligibility condition.
These tests must be designed with policy experts. Two cases that appear similar to a developer may differ in a legally decisive way. Conversely, a field that looks important in historical data may be irrelevant to the actual eligibility rule. The point is not to impose an abstract mathematical notion of sameness. It is to test the relationship between the lawfully relevant facts and the system's action.
A useful suite includes values just above and below thresholds, missing versus zero income, unknown versus false answers, corrected versus duplicate records and households with changing membership. It also tests what happens when a dependency fails. Does an unavailable external database produce a pending verification state, an error message or an adverse decision? Failure behavior should be an explicit requirement, not an accidental consequence of a default value.
Keep these tests under the agency's control. The supplier can provide additional examples, but the buyer needs cases that were not used to tune the demonstration. Preserve expected outcomes and their reasoning so future releases can be checked consistently. Where the correct outcome is disputed, resolve the policy question rather than forcing the test to match whatever the software currently does.
This approach does not eliminate the need for real-world evaluation. It catches a different class of problem: a system that performs well on common cases but violates an essential rule at a boundary. In public benefits, those boundaries are not obscure technical corners. They are often the exact points at which a person's entitlement changes.
The public buyer is buying a repairable decision process
The strongest procurement requirement is not a promise that the system will never make a mistake. It is a demonstrable capacity to find mistakes, explain them, correct them and learn how far they spread. That capacity has technical components: versioned rules, traceable data, reproducible calculations, accessible records and reliable correction workflows. It also has administrative components: independent judgment, usable notices, properly resourced review and lawful remedies.
A bidder should be able to demonstrate a contested case from beginning to end. The agency should see the original evidence, the transformation into decision inputs, the rule or model output, the human finding, the notice and the correction. The demonstration should include a difficult case and an error deliberately introduced by the buyer. Confidence built on that exercise is more meaningful than confidence built on a slide declaring the product explainable.
The public report can then be equally concrete. It can describe what the system does, which decisions it supports, what evidence is retained, what errors have been found, how performance is measured and how a person can obtain review. Legitimate limits on disclosure can be stated specifically rather than used to turn the entire process into a black box.
The appeal trail is where procurement promises meet administrative reality. A fast system that cannot reconstruct its own actions transfers the cost of its uncertainty to the people who depend on it. A repairable system treats challenge as part of normal operation, not as an unexpected exception to an otherwise frictionless service.
When a person asks why their support changed, the agency should not have to ask a supplier to guess what an old model probably meant. It should be able to open the record, identify the facts and rule, hear the challenge and make the necessary correction. That is the practical standard against which the purchase should be judged. <!-- /ARTICLE_BODY -->