Generalization

Generalization asks whether a rule learned from observed cases still works on new cases. You can get every example in your sample right and still fail on the next client request, because fitting what you’ve already seen isn’t the same as handling what comes next.

Bennett’s paper asks which rule is more likely to do that, one that leaves more possibilities open or one you can write in fewer words. Those sound like similar ideas, but the difference matters, and the paper’s answer has limits we need to keep with it.

What does generalization mean?

The research calls the rule a hypothesis. That might be something a model learned, an operating instruction you wrote, or a rule for deciding which kind of case you’re looking at, and it generalizes when it gives the right result beyond the examples used to form it.

Imagine you write a proposal instruction from ten requests and it handles all ten cleanly. Then a new client arrives with a different industry, scope, or approval path, and you need the same instruction to produce a correct and checkable result.

If it can only reproduce the patterns in those first ten requests, you’ve shown a good fit to the sample, not that it will work on new cases. Even a separate test can be misleading if its examples are too much like the ones you started with.

So keep the cases used to write the rule out of the test set. An eval gives you the repeatable scoring method, and generalization is one of the questions you’re asking it to answer.

Why is a weak hypothesis different from a short hypothesis?

A weak rule leaves more possibilities open. In Bennett’s formal setup, weakness is the size of the rule’s extension, written as |Z_l|, while shortness counts how few words, symbols, or bits describe it.

You don’t need the notation to see the difference. Bennett writes that “a simple statement need not be weak, for example ‘all things are blue crabs’,” which is short but rules out nearly everything else.

A longer statement can leave more possibilities open and still explain what you’ve observed. So weak doesn’t mean careless or vague, the rule still has to be correct on the observed cases, it just avoids ruling out things those cases didn’t require it to rule out.

His Proposition 3 makes that distinction with a shortest hypothesis {z} and a weaker one {j,k}. The shorter option leaves fewer possibilities for unseen cases and loses in that comparison, which doesn’t mean longer rules always win, only that length alone doesn’t settle it.

What did Bennett actually prove?

Bennett’s proof works under stated assumptions, including uniformly distributed tasks and a formal model of enactive cognition. Within that setup, the probability of generalizing is 2^|Z_Sα ∩ Z_h| / 2^|Z_Sα|.

The weakest hypothesis that is still correct on the observed cases maximizes that probability. Basically, it leaves the most possibilities open while still explaining the cases it had to explain.

The paper makes three propositions, weakness is sufficient to reach that maximum, weakness is necessary to reach it, and minimum description length is neither sufficient nor necessary. The {z} and {j,k} comparison is the counterexample behind that last point.

Those conditions are part of the result, not something to drop when applying it. The proof isn’t an unconditional law about every model, prompt, workflow, or service business, and the paper doesn’t give us an algorithm for maximizing weakness in our own systems.

Bennett lists implementing the idea inside neural networks as future work. So we need to keep what the paper proves separate from what we’d like to build with it.

What did the experiment find?

The experiment tested 8-bit string prediction for binary addition and multiplication. A program saw part of a truth table, chose a rule using either weakest or shortest selection, and then faced the full table, with 75 to 256 trials per setting.

Task	Examples	Weakest generalizes	Shortest generalizes
Addition	6	.11	.10
Addition	10	.27	.13
Addition	14	.68	.24
Multiplication	6	.05	.01
Multiplication	10	.16	.08
Multiplication	14	.46	.21

Across those settings, Bennett reports the weakest hypothesis generalizing at 1.1x to 5x the rate of the shortest. The partial-generalization extent was 1.03x to 1.56x, and both ranges belong to the tasks and sample sizes in that experiment.

That isn’t a multiplier for your firm’s workflow. The experiment didn’t test client work or establish that a less specific prompt always gives a safer answer, so any business application still needs its own test.

What is Bennett’s Razor?

Bennett’s Razor says “Explanations should be no more specific than necessary.” Among rules that explain what you’ve observed, it favors the least specific one, because under the paper’s assumptions that rule has a better chance of holding on an unseen case.

The paper contrasts that with Occam’s razor and minimum description length, approaches associated with choosing simpler or shorter explanations. Its particular distinction is between a brief description and one that leaves more possibilities open, which is why the blue-crab example helps.

I can use that idea when writing an operating rule, but that’s my application of the paper, not a finding from its experiment. If the work requires the approved price list, put that restriction in the rule, but don’t require one particular filename just because the first few examples happened to use it.

What can an operator take from the result?

Start by testing the instruction on cases you didn’t use to write it. Vary the client, input, document, and exception in ways that represent your actual work, then score whether the result is still correct.

When something fails, look at why before adding another instruction. You may have made the rule too narrow by adding a restriction the evidence didn’t require, or the source, standard, or owner may be missing.

Those need different repairs. Remove the unnecessary restriction in the first case, and fix the missing part of the process in the second, because calling both “the model got it wrong” doesn’t tell your team what to change.

That’s where documenting the process before an agent runs it helps. Write down what starts the work, what counts as correct, which exceptions need judgment, and who owns the decision, based on the work rather than one convenient example.

And keep the controls the work really needs. “No more specific than necessary” doesn’t mean removing approvals, source permissions, output checks, or ways to refuse a request, it means you should be able to explain why each restriction belongs there.

Where does generalization sit on the Delivery Model Ladder?

Generalization sits at Stage 2, Augmented, on the Delivery Model Ladder. A written workflow uses AI for part of delivery and tests cases that represent what it’s expected to handle, while a person owns exceptions and reviews consequential results.

At Stage 1, a person applies the rule case by case. Stage 2 makes it repeatable and tests it beyond the original examples, while Stage 3 would make broader testing and exception handling part of how the firm operates.

Those are this glossary’s placements, not stages Bennett named or measured. The term belongs under The Production Gap because fitting a sample is only the start of making a rule dependable in live work.

The next useful step is to run your current rule on cases it hasn’t seen and inspect the failures before adding more instructions. You still need a defined task, a separate test set, and somebody who can judge the result, because without a stable standard you cannot tell whether the rule generalized.