Lore

Learning rate is the speed at which uncertainty becomes better understanding, and better understanding changes what we do next. It is not the same as working faster. A team can produce a great deal of activity while learning almost nothing.

High learning rate means exposing important assumptions to reality early, getting useful feedback, finding contradictory evidence, testing what matters, and carrying what we learn into the next iteration. When someone says, “Increase the learning rate on this,” the instruction is usually simple: shorten the distance between what we currently believe and the evidence that could confirm, weaken, or change that belief. Talk to the user. Run the evaluation. Test the inference. Show the prototype. Inspect the failure. Find the missing evidence.

When the right answer is not yet obvious, learning rate is how we measure progress.

This question asks two things: what are we trying to reduce, and will our iterations move us toward a better state? In machine learning, a loss function defines the error the system is optimising against. Without one, there is no meaningful way to say whether an update improved the model or merely changed it.

We use the phrase more broadly at ASUME. The loss may be an incorrect inference, weak evidence, a false positive, a missed opportunity, wasted computation, an irrelevant output, user distrust, unnecessary complexity, or a decision made from an incomplete understanding of a company.

Naming the loss gives an iteration direction. After making a change, we should be able to ask whether the relevant loss decreased, stayed unchanged, or moved somewhere else. This matters because iteration alone is not progress. A team can move quickly while oscillating, optimising the wrong metric, or repeatedly changing a system without getting closer to the outcome that matters.

When someone asks, “What’s the loss function here?”, they are asking us to define what improvement means before we optimise. And once the loss is explicit, another question follows naturally:

Are we converging?

The goal is not simply to produce more iterations. It is to make each useful iteration reduce uncertainty or error enough that the system moves toward a better understanding, product, or decision.

This is shorthand for: make the next useful thing inspectable.

When an idea becomes too large, too abstract, or too discussed, we reduce it to one meaningful iteration. That might be one inference test, one customer workflow, one revised definition, one evaluation, one interface, one company example, or one change to the evidence structure.

The purpose is not to ship careless work. It is to produce something concrete enough that reality can respond to it.

An idea in conversation can survive indefinitely. An implementation, example, or test gives us something that can succeed, fail, surprise us, or reveal the next question. One iteration creates evidence. Then we decide what the next iteration deserves to be.

ASUME did not begin because there was already a recognised category waiting for another product. Companies already had search tools, databases, enrichment products, analytics platforms, AI assistants, and increasingly capable agents. What remained unresolved was the distance between having information about a company and actually maintaining an understanding of it.

There is no guarantee that market inference, Assumptive Understanding Models, or an understanding layer for agents would become established language. We started anyway.

That phrase has come to represent a broader instinct: the absence of an existing category, established terminology, perfect architecture, or complete certainty is not in itself a reason to avoid a problem that appears real. Sometimes the language follows the work. We build, observe, define, test, revise, and allow the structure to become clearer through use.

“Started anyway” does not mean ignoring evidence against an idea. It means not requiring the world to have already named the thing before we are willing to investigate whether it should exist.

Uncertainty tells us where understanding can still improve. It may appear as an evidence gap, a weak assumption, contradictory signals, an unstable inference, an unclear customer need, or a question for which the available information is simply insufficient. The instinct should not be to hide that uncertainty behind a confident answer. The instinct should be to locate it.

Ask what is missing. Identify which assumption carries the uncertainty. Determine whether additional evidence could reduce it. Decide whether it should remain explicitly unresolved or whether the claim should not yet be used. Some uncertainty can be reduced. Some cannot. Both are useful to know.

This principle matters beyond the product. Uncertainty about a market, customer, architecture, strategy, or decision is also information. Once it is made explicit, we can decide what evidence would be worth acquiring next. Known uncertainty is actionable. Hidden uncertainty is not.

Lore should not become doctrine. A phrase survives at ASUME because it continues to compress something useful about how we think or work. If the company changes, our understanding improves, or a phrase stops helping, we should change it or let it disappear.

That is part of the point. The ideas underneath the lore are more durable than the wording: learn quickly, make assumptions visible, understand the cost of being wrong, expose work to evidence, make uncertainty explicit, and revise when reality gives us a better explanation.

The rest can evolve with ASUME.