Iterations

We deliberately use the word iteration rather than treating execution as a sequence of sprints.

A sprint is usually defined by a period of time and a set of work expected to fit inside it. An iteration at ASUME is defined by what was learned and what changed as a result.

Time still matters. Short cycles prevent speculation from continuing indefinitely and help us expose work to reality sooner. But the calendar is not what makes an iteration complete.

An iteration closes when we have enough new information to make a better next decision.

The rhythm is:

Act → observe → learn → revise → act again.

A useful iteration begins with a question, assumption, problem, or loss that is specific enough to investigate.

What are we trying to improve?

What do we currently believe?

What evidence could support or weaken that belief?

What would count as a better outcome?

Without this clarity, iteration can become movement without direction.

This connects directly to a question we use often:

What's the loss function here?

Knowing what we are trying to reduce gives the iteration something to move against.

Once the problem is clear enough, we look for the smallest action capable of producing useful information.

That might be testing an inference, changing an evaluation, showing a workflow to a user, building a narrow product surface, reviewing evidence, changing a prompt, trying a new architecture, or making one customer-facing improvement.

Small does not mean trivial.

A useful small action exposes an important assumption while limiting the cost of being wrong.

This is what we mean when we say:

One iteration, please.

Do enough for reality to answer back.

Shipping something is not the end of an iteration.

We need to inspect the response.

Did the inference improve? Did the customer understand the output? Did the evidence support the conclusion? Did the workflow become easier? Did an expected signal fail to appear? Did the technical change create another problem elsewhere?

The result does not need to confirm what we expected.

A failed assumption can produce a better iteration than a successful implementation if it changes our understanding early enough.

The important thing is to distinguish what happened from what we hoped would happen.

An observation becomes useful when it changes the state of our understanding.

An assumption may become stronger or weaker. A problem may become more precisely defined. An evidence gap may appear. A proposed feature may become unnecessary. A technical constraint may become visible. A customer behaviour may reveal that we were solving the wrong problem.

We capture the important part of that change so the next decision does not begin from the same uncertainty as the previous one.

The goal is not documentation for its own sake.

The goal is that learning survives the iteration that produced it.

The next iteration should follow from what was learned, not simply from the original plan.

Sometimes the result tells us to continue in the same direction.

Sometimes it tells us to narrow the problem, gather different evidence, change the approach, or stop.

This is why iteration and revisability belong together.

A plan gives us direction. An iteration gives reality an opportunity to change that direction.

The question after each meaningful loop is:

Given what we know now, what is the next smallest action worth taking?

More iterations do not automatically mean more progress.

A system can change repeatedly without getting closer to a useful result. We can optimise the wrong loss, test weak assumptions, oscillate between alternatives, or collect evidence that cannot resolve the question.

We therefore ask whether successive iterations are actually improving something that matters.

Are we converging?

Convergence may mean lower error, stronger evidence, reduced uncertainty, a more stable product behaviour, clearer customer demand, or a better-defined problem.

It does not require perfect certainty.

It means that each useful iteration leaves us in a better position than the one before it.

When repeated iterations do not converge, the answer may not be another iteration of the same kind. We may need to reconsider the loss function, the evidence, the assumption, or the problem itself.

The purpose of short iterations is ultimately to increase the rate at which ASUME learns.

Moving quickly is useful only when movement produces information.

One week of implementation can have a low learning rate if it leaves the important assumptions untouched. One small test can have a high learning rate if it reveals that an entire direction should change.

That is why we try to keep the distance between belief and evidence short.

Action creates evidence. Evidence changes understanding. Understanding determines the next action.

Iteration is the loop that keeps that process moving.