Exception Economics

The share of back-office work items the system carried to a final state with no human action. The unit is a work item, which may span several documents, several lookups and several writes, which is why it is defined separately from the document-level rate in section 3.4.

Automation rate = items completed with no human action ÷ items admitted to processing.

Items that reached a final state, posted, matched, closed or rejected by rule, with no human action of any kind, including no reviewer opening the item. The sampled-audit convention in section 3.4.2 applies unchanged: an audited item counts as automated if the audit changed nothing.

Items admitted to processing in the window: items received, less items rejected before processing by a rule named in the statement of work. Both counts are reported.

Items still open at the end of the window, counted and reported as in flight. Items abandoned because an upstream system was unavailable, counted and reported as upstream failures. Items the partner withdrew.

Automation rate is never published, quoted or contracted alone. It is meaningless without section 3.15 beside it, because a system that automates every item and is wrong on a tenth of them can cost more than one that automates half and is right. Every table carrying an automation rate carries the wrong-automation figure on the same row.

"Automation rate means the number of Items carried to a final state with no human action, divided by the number of Items admitted to processing in the measurement window. The Provider shall achieve an automation rate of not less than placeholder percent while keeping wrong-automation rework at or below the ceiling in clause [X]. The automation rate is not satisfied in any month in which the rework ceiling is exceeded."

The labour needed to find and put right the items the system completed automatically and wrongly, expressed in minutes per one thousand automated items, and then in money at the reviewer cost the labour model states.

Rework minutes per 1,000 automated items = (the sum over wrong automated items of detection minutes plus correction minutes plus downstream correction minutes) ÷ automated items × 1,000.

Minutes taken from the labour model published with the dataset, which states, per error class, the expected minutes to detect the error by its detection route and the minutes to correct it and to correct anything downstream that consumed it. In production the minutes come from the time recorded against the correction. Where an error class has no detection route inside the window, it is not given a minute figure. It is reported as an open exposure count, with the class named. Inventing a detection time for an error nobody would find is exactly the kind of number this charter exists to prevent.

Items completed automatically, that is the numerator of section 3.14, scaled to one thousand.

Rework on items that went to human review in the first place, which is reviewer time under section 3.16. Rework caused by a source-data error the system could not have detected, reported separately as an input-quality class. Rework caused by a partner-side change outside the statement of work.

Cost = rework minutes × the fully loaded reviewer cost per minute stated in the dataset labour model, reported in INR and USD, both marked placeholder until a partner supplies the rate. Net cost per item, which is the figure a chief financial officer reads, combines this with section 3.16 and with cost per document from section 3.7, and is reported at three confidence thresholds so that the trade between automation and rework is visible rather than argued.

"Wrong-automation rework means the sum of detection, correction and downstream correction minutes attributable to Items completed automatically and incorrectly, divided by the number of Items completed automatically and expressed per one thousand such Items, using the labour model in Schedule [X]. The Provider shall keep wrong-automation rework at or below placeholder minutes per one thousand automated Items. Error classes with no detection route within the measurement window shall be reported as an open exposure count with the class named, and shall not be assigned an estimated minute figure."

The reviewer time taken to bring an exception to a final state. Reported as the mean and the median, and always broken down by queue entry code, because a low-confidence check and a processing failure are different pieces of work.

Mean reviewer minutes per exception = total reviewer minutes recorded on exceptions closed in the window ÷ exceptions closed in the window.

Reviewer active time from the reviewer opening the item to its final state, summed across every reviewer who touched it, including second review and escalation to a senior reviewer. In production, taken from queue timestamps with an idle cut-off, placeholder seconds, after which a reviewer's session is closed and further time is not counted. In the benchmark, taken from the labour model published with the dataset.

Exceptions closed in the window, not exceptions opened. Counting the ones that opened would let the slowest items sit outside the figure forever.

Waiting time in the queue, which is queue age. Training and calibration time. Time on items rejected as out of scope before review, reported separately. Sampled-audit reviews, which are a measurement device and are reported separately as audit minutes.

Reviewer time is usually the partner's staff cost, not ours, so this is not a metric a supplier can promise on its own. It is contracted as a reporting duty with a redesign trigger, and Clause 15 in contract-clauses.md is written that way.

"Reviewer minutes per exception means the total reviewer active time recorded against exceptions closed in the measurement window, divided by the number of exceptions closed, reported as a mean and a median and broken down by queue entry code. The Provider shall report this measure in every Monthly Report. Where the mean exceeds placeholder minutes for two consecutive months, the Provider shall, at no charge, analyse the causes and propose a change to thresholds, validation rules, queue design or the model, and shall implement the agreed change within placeholder Business Days."

The change in a tracked metric between the acceptance baseline and the same metric measured ninety days later. Two figures are required, and neither is complete without the other.

Drift = the metric at day 90 minus the metric at acceptance, in percentage points for rates and in percent of baseline for cost and latency. The report always shows both endpoints. A difference published without its endpoints hides which one moved.

Those of the underlying metric, unchanged. Drift is a difference between two measurements of the same metric, not a metric of its own, and the underlying sample size is printed at both endpoints.

The ninety-day drift is simulated by re-scoring under a shifted input distribution defined in the dataset manifest, with new vendor formats and new item categories at a share the manifest states. It is labelled a simulation everywhere it appears, in the table, the chart and the prose. A simulated drift is evidence about a system's sensitivity, not a record of what happened to a deployment.

Change caused by a scope change agreed under change control, which is reported with its change reference and then excluded from the drift figure. The hypercare period stated in the statement of work, because thresholds are still being set in it; the baseline is the acceptance measurement, not the first day of production.

"Ninety-day drift means the change in a tracked measure between the acceptance measurement and the measurement taken ninety days later, reported both on the frozen labelled set version used at acceptance and on a fresh labelled sample drawn from the preceding thirty days of live input, with both endpoints and both sample sizes stated. The Provider shall report both figures in the Monthly Report. A fall of more than placeholder percentage points on the frozen labelled set, or any fall that takes a tracked measure below its floor on the live sample, is a Severity 2 Incident under the Retainer Schedule clause 4."