Lesson 5 of 10

What a record of failures is worth

When does writing down what went wrong make the next decision better, and when does it only cost?

The problem

The same failure, paid for twice

In the spring, the Warranty Claims team tried an AI document reader on scanned contract annexes. It failed. Not quietly: it missed exclusions, which is the one thing Warranty Claims cannot afford. Someone spent two days finding out why. The answer was mundane and fixable. The annexes used for the trial were clean digital files; the real ones are crooked photocopies with handwritten notes. Wrong sample, not wrong idea.

In the autumn, the Field Repair Dispatch team asks for help with a reader for scanned service manuals. Its first trial has failed too. Is it the same problem? If someone remembers the annex story, the answer takes ten minutes, and the help goes to a cheap fix. If nobody does, Dispatch either pays for the same two days of diagnosis, or — worse — gives up on a good idea.

A third request arrives with a beautiful demo: a vendor tool that summarizes service logs fluently. Last year, a different team found that this kind of tool could not meet its acceptance rules with the data it was allowed to use. Fluent, and a dead end. A reviewer who remembers that says no quickly. A reviewer who does not says yes to the demo.

So there are four kinds of request a reviewer meets, again and again:

A — a known useful case: someone has done this before and it worked.
B — a new useful variation: its first trial failed, but a diagnosis found a fixable cause, like the crooked annexes.
C — a known dead end.
D — a new dead end with a convincing demo.

A team working alone remembers its own A and C cases. The B and D lessons usually live in another team's head. This lesson asks what those records are worth: how much better the next decision gets, what it costs to keep and move the records, and what happens when a record is wrong or a failure is never reported at all.

The intuition

One memory or many, and why the answer is not obvious

Keep memory local and each team learns from its own trials. Nothing needs to be written up for strangers, nobody pays to maintain a shared archive, and a wrong lesson stays where it was learned. The price is that every team discovers the crooked-annex problem for itself.

Share memory and the reviewer sees everyone's lessons. One diagnosis can stop five teams from repeating a dead end, or rescue a good idea that failed for a boring reason. But three things can go wrong. First, a record is not free: someone has to check the diagnosis, keep it current and get it to the person who needs it. Call that cost the upkeep. Second, a wrong lesson travels just as fast as a right one, and it looks just as precise. Third, the reviewer only sees what gets reported. If failures go unrecorded, the archive looks like a list of successes.

Two kinds of reasoning are needed. The first is a game, like lesson 4. Each team knows which kind of case it has before deciding whether to pitch. A reviewer who recognizes D cases changes the odds for D teams, and so changes who bothers to pitch. Better memory works partly by changing behavior, not only by changing verdicts. The second is planning under uncertainty. Before the next trial, the reviewer can pay for a small test. Is it worth it? Only if some possible answer would change what happens next. That is an optimization over every answer the test could give — including no answer at all.

The model

Coverage, upkeep and silence

How a record changes the test

Keep lesson 4's test, but let it learn. When no record covers a case, the test passes it with a baseline chance $\beta$ , here one half — a coin. When a correct record covers the case, the test gets it right: a covered strong idea always passes, a covered weak idea never does. Let $\mu_{\text{strong}}$ be the share of strong cases covered by a correct record, and $\mu_{\text{weak}}$ the share of weak cases.

Checked in Lean · coverage sets the pass chances

\begin{aligned}p_{\text{strong}} &= \beta + (1-\beta)\,\mu_{\text{strong}}\\ p_{\text{weak}} &= \beta\,(1-\mu_{\text{weak}})\end{aligned}

In words: each correct record covering a strong case lifts its pass chance from the coin to certainty; each covering a weak case drops it from the coin to zero. Coverage means the share of future cases a correct record applies to, not the number of records.

A team's local memory covers its own A and C cases: half of each kind. That gives pass chances of 3/4 for strong ideas and 1/4 for weak ones — exactly the test of lesson 4. A shared memory that also holds the B and D lessons covers everything: 1 and 0. A duplicate record adds no coverage. An unrelated record adds none. A wrong record moves the pass chance the wrong way.

Who pitches, given what the reviewer knows

A team knows its own kind of case before it pitches, and it can anticipate how the reviewer will treat that kind. As in lesson 4, pitching costs the team effort $\kappa$ , the slot is worth B to the winner, and two passing pitches share the slot by a coin:

Definition · gain from pitching, case by case

\text{gain from pitching a case of kind } A, B, C \text{ or } D \;=\; p_{\text{case}}\left(1-\tfrac12\,\bar p\right)B-\kappa

In words: the pass chance for this kind of case, times the chance of not having to share, times what the slot is worth, minus the effort. Here $\bar p$ is the chance the other team both pitches and passes.

With only local memory, the stable rule is: A, B and D cases pitch, C cases stay home. D pitches because the reviewer cannot recognize it, so its coin-flip pass chance is worth the effort. With the shared memory, only A and B pitch. The reviewer now funds the fixable B case and turns away the D demo, and D teams, seeing that, do not even try. In the worked case (a strong project worth 8 to the company, a funded weak one losing 4, a test costing 1), the company's expected value from the award rises from 9/4 to 5.

That gain has to pay the upkeep, $u$ : the extra cost of keeping the B and D records correct and getting them to the reviewer. The comparison is simple once the game has done its work:

Derived by hand · the shared memory pays when

V_{\text{shared}} - V_{\text{local}} - u \;>\; 0

In words: the shared route wins when the better awards it makes possible are worth more than the upkeep of the records it needs. In the worked case, 5 minus 9/4 is 11/4, so the upkeep must stay below 11/4.

Lesson 5 · Figure 1

Correct shared records pay until their upkeep reaches 2.75. Wrong ones never pay.

Shown at Upkeep of the shared records: 0.50 illustrative units. Turn on JavaScript to move the values.

With upkeep at 0.5, correct shared records win by about 2.25: the reviewer now funds the fixable B case and turns away the D demo. Below 2.75, sharing records pays.

Correct records, gain over local: 9/4
Wrong records, gain over local: −9/4
Break-even upkeep: 2.75

Both routes see the same past cases and face the same one-slot limit; the shared reviewer may also use the B and D records. Lean checks the gains at upkeep 1/2 (9/4 for correct records, −9/4 for two wrong ones) and −1/4 at upkeep 3. The lines are computed by the tested model code.

Model result · checked in Lean

Silence is evidence

Now the third danger: failures that nobody reports. Take one project, worth +4 if it is good and −8 if it is not. Three in four projects like it are good, so the share of good ones is $\rho = 3/4$ . Launching blind is worth 3/4 × 4 − 1/4 × 8 = 1. A quick test reports a pass on a good project 3 times in 4 and on a bad one 1 time in 4. But here is the catch: every failed test goes unreported. The reviewer hears either "pass" or nothing.

What does nothing mean? If you know the reporting habit, silence is just a failed test that nobody wrote down. Bayes' rule — reweigh each possibility by how likely it was to produce what you saw — gives:

Derived by hand · what silence tells you

P(\text{good}\mid\text{silence}) \;=\; \frac{\rho\,(1-p_{\text{strong}})}{\rho\,(1-p_{\text{strong}})+(1-\rho)\,(1-p_{\text{weak}})} \;=\; \frac{3/16}{3/16+3/16} \;=\; \tfrac12

In words: before the test, 3 in 4 projects are good; after hearing nothing, only 1 in 2 is. Silence is mild bad news, and with these numbers it is enough to change the decision.

With a project worth +4 or −8, a coin-flip chance of being good means launching loses on average. So the careful reviewer tests, launches after a pass, and holds back after silence. Should it test at all? A test costing $\gamma$ is worth running only if the best plan after each possible answer, averaged over the answers, beats the best plan now by more than $\gamma$ :

Checked in Lean · test only if the answer can pay for itself

\sum_{\text{answers}} P(\text{answer})\times\big(\text{value of the best plan after that answer}\big) \;-\; \gamma \;>\; \text{value of the best plan now}

In words: list every answer the test could give, including silence; for each one, find the best next move; average; subtract the cost of the test. Run the test only if this beats deciding now. Repeat the same reasoning for a second test after the first, and so on.

At a test cost of 1/4, the careful reviewer earns 3/2 against 1 for launching blind. A reviewer who wrongly believes silence means nothing — that half of all results go missing at random, whatever they say — keeps its 3/4 prior after silence and launches anyway. It has paid for a test that never changes its choice. It earns 3/4, less than if it had never tested.

Lesson 5 · Figure 2

A test pays only if you read the silence correctly.

Shown at Cost of one test: 0.25 illustrative units. Turn on JavaScript to move the values.

At 0.25 per test, reading silence as bad news pays: test, launch only after a pass, and earn about 1.5 against 1 for launching blind. A reviewer who reads silence as "no news" earns about 0.75, less than not testing at all.

Careful reviewer: 1.5
Misreading reviewer, what it actually earns: 0.75
Launch without testing: 1

One project worth +4 if good, −8 if bad; 3 in 4 are good; failed tests go unreported. The misreading reviewer plans as if silence were uninformative, then is scored on what really happens. Lean checks 3/2, 3/4 and 1 at a test cost of 1/4.

Model result · checked in Lean

What each letter stands for

$\beta$: the baseline chance the test passes a case that no record coversprobability
$\mu_{\text{strong}},\ \mu_{\text{weak}}$: the share of strong cases, of weak cases, covered by a correct recordshare of future cases
$p_{\text{strong}},\ p_{\text{weak}},\ p_{\text{case}}$: the chance the test passes a strong idea, a weak idea, a case of one kind (as in lesson 4)probability
$\bar p$: the chance the other team both pitches and passesprobability
$B,\ \kappa$: what the slot is worth to the winning team; the effort of pitching (as in lesson 4)team's illustrative units
$V_{\text{shared}},\ V_{\text{local}}$: the company's expected value from the award with shared memory, with local memoryillustrative units
$u$: the upkeep: the extra cost of keeping the shared records correct and getting them to the reviewerillustrative units
$\rho$: the share of projects that are good (as in lesson 4)probability
$\gamma$: what one test costs (as in lesson 4)illustrative units

What Lean checks

Lean is a program that checks every step of a proof. Each result below is exactly as strong as its statement; the sentence under it says what it does not cover.

Checked in Lean

If every stored record is correct for the future cases it is applied to, the pass chance for strong cases is the baseline plus the gap to certainty times the share of strong cases covered.

sensitivity_from_coverage in AssessmentLearning.lean

Show the Lean statement

theorem sensitivity_from_coverage (base : Rat) (m : Memory) (hs : SoundMemory m) :
    pHigh base m = base + (1-base)*highCoverage m

Its twin, false_positive_from_coverage, gives pLow base m = base * (1-lowCoverage m). Both rest on the assumption SoundMemory: a record is right about the future cases it is applied to. A reviewer's sign-off does not establish that; it is the most important assumption in this lesson. The companion sound_update shows a new record keeps the memory correct only if its own label is correct.

Checked in Lean

In the worked case, with the stated pitching rules, the shared memory beats local memory by 9/4 after an upkeep of 1/2.

shared_gain_after_cost in AssessmentLearning.lean

Show the Lean statement

theorem shared_gain_after_cost :
    sponsor (1/2) (1/2) 8 (-4) 1 sharedMemory highOnlyEntry -
    sponsor (1/2) (1/2) 8 (-4) 1 localMemory localEntry - 1/2 = 9/4

Lean also checks that both pitching rules are strictly stable (local_signature_equilibrium, shared_signature_equilibrium), that an upkeep of 3 turns the gain into −1/4 (overhead_reverses_shared_gain), and that two wrong records lose 9/4 (harmful_memory_loses). That these are the only stable rules among the 16 possible "which kinds pitch" rules is checked by the tested model code, not by Lean; rules where teams randomize or follow different rules were not studied.

Checked in Lean

Over a fixed number of rounds, no testing plan that respects the budget and the available tests does better than the plan built by working backwards from every possible answer.

bellman_dominates_policy in AdaptiveExploration.lean

Show the Lean statement

theorem bellman_dominates_policy (m : Model S A O D) (n : Nat) (s : S)
    (p : Policy A O D n) (hp : Feasible m n s p) :
    evaluate m n s p ≤ value m n s

This covers every feasible plan, not a short list of candidates; bellman_attained shows the best value is actually reached by a feasible plan, and optional_stop_nonnegative that stopping is always allowed, so the best plan is never worth less than doing nothing. It does not check that the assumed test reliabilities are true.

Checked in Lean

In the silence example, a plan chosen under the belief that silence means nothing, then scored under the true reporting habit, earns 1/4 less than launching without a test.

misspecified_learning_harms in AdaptiveExploration.lean

Show the Lean statement

theorem misspecified_learning_harms :
    evaluate (binaryModel trueKernel) 1 binaryInitial misspecifiedPolicy -
    binaryPayoff binaryInitial .deploy = -1/4

The plan is fixed before it is scored, so there is no rescue after the fact. calibrated_optimum checks the careful reviewer's 3/2.

What it means

A record is worth what it changes. The B record rescues a good project; the D record stops a bad one and, just as usefully, stops the D team from pitching at all. A record that changes no decision — a duplicate, an unrelated lesson, a diagnosis nobody can apply — is worth nothing, however complete the archive looks.

Upkeep is the honest price. In the worked case the shared memory wins comfortably at an upkeep of 1/2 and loses at 3, even though its reviewer still makes the better choice. Better judgment is not automatically better value. Someone has to check that a diagnosis is right, keep it current and move it to where it is needed, and that someone costs money.

Wrong lessons are worse than no lessons. Two records that passed review but got B and D backwards turn the reviewer against the good project and toward the bad one. They lose 9/4 before any upkeep. Nothing in the record itself warns you; a wrong lesson is written in the same confident tone as a right one.

An archive of what was reported is not an archive of what happened. If failures go unreported and you know it, silence is evidence and you can use it. If you do not know it, the test makes your decisions worse. A shared reviewer sees approved projects, reported results and teams that stayed; it misses rejected ideas, abandoned attempts and quiet repairs. Researchers call this the selective labels problem. Logging more of the same reported cases does not fill the gap. A small, deliberate look at cases that would otherwise never be seen can.

A shared service that teams may skip cannot lose; a mandatory one can. The same planning model shows it. If the shared testing service costs a fee of 1/8, it beats a team limited to its own tests by 1/8. Raise the fee to 1/2: a team forced to use the service loses 1/4, while a team allowed to skip it simply goes back to its own value (high_fee_mandatory_loses, high_fee_optional_bypasses). Making a good thing compulsory is one of the three ways a shared route loses.

Memory has no owner's premium. Give a local reviewer the same records and it makes exactly the same choices. That is true by construction, not a finding (Lean's same_records_same_assessment simply records it), and the research index states it once as a design rule for every model. What a shared owner can add is reach: getting B and D records from the teams that learned them to the teams that need them, and paying for the upkeep that nobody pays for alone.

What the model leaves out. Records here never decay, and a covered case is classified perfectly. Real lessons go stale as tools, vendors and documents change; studies of industrial learning find that knowledge depreciates and transfers incompletely. The reliabilities of the tests are assumed, not measured. And we have taken for granted that teams report their failures at all. Writing up a dead end costs the team that found it, and the reward goes to someone else. Why would anyone do it?

Next: why anyone would file the record

Every number in this lesson assumed the records exist. But the team that discovers a dead end pays to write it up, and may fear that admitting it weakens its next request. Lesson 6 asks what it takes to make telling the truth worth it — and why a sponsor's promise to reward it has to survive the moment when breaking it looks tempting.