The I2I Loop: From Intent to Impact With a Universal Control Principle

You set a quarterly goal. Your team understood it. Work was distributed. Three months later, sitting in the review, you realized half the output moved toward the goal. The other half produced something else entirely. Not because people performed poorly. Because no continuous control mechanism existed between your intent and the result.

This is the most common failure in organizations. Not missing strategy. Not missing motivation. The absence of a loop that systematically connects intent to impact.

Why PDCA is not enough

If you have spent any time in quality management, you know PDCA: Plan-Do-Check-Act. Since Deming popularized the concept, it has been the default cycle for continuous improvement. And it works well in manufacturing, where "Plan" means a technical procedure and "Check" means a measurable inspection.

In knowledge work, PDCA breaks at two points.

1. "Plan" is ambiguous. In manufacturing, plan means define the procedure, the tolerances, the acceptance criteria. In knowledge work, plan often means write down what you intend to do. That is a qualitative difference. A plan without verifiable intent and without an explicit decision basis is a wish.

1. "Check" becomes passive. In most organizations, check means look at the result at the end and decide if it was acceptable. If not, do better next time. That is reporting, not a control mechanism. It changes nothing about the system.

The I2I loop solves both problems by defining the four phases more precisely and placing a different consequence at the end.

The four phases in detail

Intent: What needs to be achieved — and what does not

Intent is not "setting a goal." Intent is a verifiable purpose with explicit boundaries.

Concretely: you define not just what should be achieved but the constraints. What budget is available? What timeframe? What quality criteria must the result meet? What is explicitly out of scope?

The boundaries matter as much as the goal. An intent without constraints is an open mandate. And open mandates are the primary reason work expands, priorities blur, and at the end nobody can explain whether the result matched the original purpose.

A good intent answers three questions: What is the expected outcome? Under what conditions? And how will you know it has been achieved?

Insight: How the decision is made (before work begins)

Insight is the phase most organizations skip entirely.

Work starts. Someone decided it should. But how was the decision made? What data existed? What alternatives were evaluated? What decision method was applied? In most cases, the honest answer is: the boss said so. Or: we have always done it this way.

Insight requires that the decision method is chosen explicitly before work begins. Not every decision needs an elaborate analysis. But every decision needs transparency about the basis on which it was made.

This has two effects.

1. You avoid reflexive decisions based on gut feeling or hierarchy when data would have been available.

1. When the result is off, you can trace where the decision was wrong, not who made the wrong decision, but what basis was missing.

Data beats opinions. That is a foundational principle. Insight is the phase that makes that principle operational.

Implementation: How work is executed while staying connected to intent

Implementation is not "do the task." Implementation is the governed execution of a routine that remains linked to the intent.

The difference from a standard task list: every work item in the I2I loop knows where it came from. It knows the intent that created it. It knows the decision basis that led to its existence. And it is routed through the Control Tower, not as an entry in an isolated to-do list, but as an element with defined states that moves through the system by pull logic.

What pull principle means here: work is not pushed forward because someone finished it. Work is pulled when the next phase has capacity. If quality confirmation is currently reviewing three items, a fourth does not enter. This prevents overload, makes bottlenecks visible, and forces prioritization.

Impact: What the result is and what it changes

Impact is the phase that fundamentally distinguishes the I2I loop from PDCA.

PDCA ends with "Act": action based on the check. In practice, that usually means: we take the lesson and do better next time. That is a personal intention. Not a system change.

Impact in the I2I loop has two components.

1. Quality confirmation. Did the result fulfill the intent? Not as a subjective evaluation, but against the criteria defined in the intent. Either the criteria are met, or they are not. The metric for this is FTT (First Time Through): the percentage of work items that pass quality confirmation on the first attempt.

1. System change. If the result does not match the intent, the person is not corrected. The process is updated. A routine gains an additional verification step. A decision rule is adjusted. A quality criterion is sharpened.

This is the critical point: impact is not reporting. Impact is the moment the system learns from its own results. And that learning is only real if it changes an artifact.

Why the loop is universal

The defining characteristic of the I2I loop is not that it works for one type of process. It is that it works at every level.

At the task level. An employee needs to create a client presentation.

• Intent: target audience, core message, quality standard, deadline.

• Insight: what data exists about the client, which template fits?

• Implementation: creation, routed through the Control Tower.

• Impact: does the presentation meet the standards defined in the intent? If not: what about the process needs to change?

At the project level. A feature needs to go live in six weeks.

• Intent: scope, budget, quality criteria.

• Insight: technical feasibility analysis, resource decision.

• Implementation: sprint cycles, visible in the Control Tower each week.

• Impact: feature is live, user data confirms the hypothesis — or disproves it, and the product backlog is adjusted.

At the strategy level. The company wants to double revenue in a market segment.

• Intent: target revenue, timeframe, allowable investment.

• Insight: market data, competitive analysis, prioritization method.

• Implementation: initiatives are launched, each with its own I2I loop.

• Impact: quarterly result is checked against intent. Deviation does not lead to blame. It leads to process adjustments.

The same structure. The same logic. The same loop. Whether a single task or a yearly strategy, the I2I loop ensures that intent and impact stay connected.

The Control Tower as a state machine

In Blog #2, I introduced the Control Tower as the single source of truth for work in flight. Now it gets concrete.

The Control Tower is not simply a Kanban board with four columns. It is a state machine. Every work item has a precisely defined state, and transitions between states follow explicit rules.

An element cannot jump from Intent directly to Implementation. It must pass through Insight. The decision basis must be documented before work begins. An element cannot jump from Implementation to "done." It must pass through Impact. Quality confirmation must be completed before the element is considered finished.

This sounds bureaucratic. In practice, it is the opposite. Because the rules are explicit, there is no debate about whether something is "done." Either an element has passed through the Impact phase, or it has not. Done is not when someone says "I am done." Done is when quality confirmation has passed.

What the Control Tower makes visible in practice:

• Where is work piling up? If ten items are in Implementation and only one in Impact, there is a bottleneck at quality confirmation.

• Which work has no intent? Anything in the Control Tower without a linked intent is, by definition, unaligned work. It may be urgent. But it has no connection to strategic purpose.

• What blocks what? Dependencies between work items become visible. Not in a separate dependency matrix, but directly in the flow.

What happens in Company 0

I use the I2I loop and the Control Tower every day in my own work. Rocket Routine GmbH is Company 0 — the first company running on this system.

An example from this week.

• Intent: write the weekly blog article. Quality criteria: terminology matches the Knowledge Base vocabulary, the article covers exactly one topic, DE and EN as standalone versions.

• Insight: topic is defined in the content pipeline, source material is the concept document and the existing articles.

• Implementation: writing, routed through the Control Tower, status moves from "Draft" to "Review" to "Quality Confirmation."

• Impact: the article meets the criteria — or it does not. If not, the author is not corrected. The process is missing a step. Maybe a checklist that must be completed before publication. Maybe a clearer definition in the intent.

This might sound like overhead for a single article. But the point is: the same loop I use for a blog article, I also use for a product decision. For a marketing campaign. For quarterly planning. The structure scales because it is the same at every level.

Why this works

Three reasons.

1. Transparency replaces control. When every work item carries its state, its intent, and its decision basis, you do not need status meetings. You do not need a project manager collecting the current state from everyone. You open the Control Tower and see it.

1. Bottlenecks become visible before they cause problems. Pull principle means: when work piles up, inflow stops. That forces resolution. Why is quality confirmation stalling? Is there a capacity issue? Are the criteria unclear? The cause is addressed, not the symptom. 3. The system learns. Every Impact phase that identifies a deviation changes an artifact. A routine is updated. A decision rule is adjusted. A quality criterion is sharpened. Over weeks and months, a system emerges that improves with every cycle. Not because people get better. Because processes get better.

Processes are the problem, not people. The I2I loop is the mechanism that turns that principle from a belief into an operational reality.

What comes next

The I2I loop defines the cycle. The Control Tower makes it visible. But who executes the work within this cycle, especially when it involves recurring, standardizable tasks? Next week, I will explain how Rocket Routine OS provisions AI operators with explicit responsibilities, decision rights, and quality obligations: Role Contracts.

If you are running a founder-led B2B company with 15 to 50 employees and you want continuous steering from intent to impact: rocket-routine.com