Author's note: This article is one of the original fourteen pieces that formed the foundation of Intent-Driven Development. The complete framework - refined, restructured, and expanded - now lives at intentdrivendevelopment.org, where you can also download the free ebook. This article remains here as part of the original record.

Intent Evolution and Intent Shaping – How intent emerges, unfolds, and moves through the hierarchy

In the previous article, we explored the Intent Hierarchy and how intent can be structured across enterprise, domain, and project levels. That structure is important for scaling Intent-Driven Development, but it can create a misleading impression if taken too literally. It can suggest that organizations should start by defining enterprise intent, then domain intent, and finally project intent beneath it.

In practice, this is rarely how intent actually appears. Intent does not begin as a hierarchy. Intent begins as work.

A team needs to solve a problem. A product needs a new capability. A regulation must be implemented. A system must change behaviour. Intent first appears locally, in projects and domains where real work is happening. Only later, when patterns repeat and knowledge stabilizes, does intent move upward into the wider organization and become part of the hierarchy.

The hierarchy is therefore not the starting point. It is the result of learning.

Intent Is Not Written Once

Traditional delivery often treats requirements as something written, approved, implemented, and eventually replaced. Intent-Driven Development works differently because intent is not simply handed over for implementation. Intent is interpreted, tested, measured, and refined continuously.

Intent behaves less like a document lifecycle and more like a feedback loop. Intent is defined, shaped into something executable, implemented by systems and agents, measured against outcomes and constraints, and then refined based on what is learned. This cycle continues because systems, organizations, and environments continue to change.

Intent is therefore not written once. It evolves.

Intent Shaping

A central concept in Intent-Driven Development is intent shaping – I stole this name from my good friend Calum Gunn.

Intent shaping is the process through which human goals are transformed into executable, measurable, and governable intent.

Humans begin with goals, not specifications. They describe outcomes, risks, constraints, and expectations in natural language and business terms. Intent shaping turns those goals into success criteria, constraints, boundaries, governance rules, and measurable outcomes that systems and agents can act against.

Importantly, shaping does not happen only at the start of a project. Delivery reveals missing constraints, unclear success criteria, and unexpected edge cases. Measurement reveals where intent and outcome diverge. Governance reviews reveal risks or conflicts. All of this feeds back into shaping.

Intent shaping is therefore continuous. Intent becomes clearer through execution, not just before it.

Bottom-Up Discovery and Top-Down Context

Intent-Driven Development works best when intent moves in two directions at once.

From the bottom up, projects and domains discover what actually works. They encounter real constraints, real domain rules, and real architectural patterns. When the same intent appears repeatedly across multiple projects, it is a signal that this intent may belong at a higher level in the hierarchy.

From the top down, organizations provide strategic direction, regulatory constraints, security requirements, shared infrastructure decisions, and cross-cutting governance. This context provides boundaries within which local intent must operate.

Neither direction is sufficient on its own. Bottom-up discovery without top-down context leads to fragmentation. Top-down standards without bottom-up feedback lead to ivory tower architecture disconnected from reality.

Intent-Driven Development works when these two movements meet in the middle, where intent can be validated, refined, standardized, and promoted to the appropriate level of the hierarchy.

Promoting Intent Up the Hierarchy

As projects deliver systems and learn from implementation, certain patterns begin to repeat. The same regulatory rules appear in multiple projects. The same architectural patterns appear across teams. The same domain models are reused. The same governance constraints are applied again and again.

When this happens, intent should be promoted upward.

Project intent becomes domain intent when it represents a pattern shared within a bounded context. Domain intent becomes enterprise intent when it represents a pattern shared across the organization. Once promoted, this intent flows downward through inheritance so future projects do not need to rediscover it.

This is how organizations turn delivery experience into organizational knowledge. Projects do not just build systems. They help shape the intent that future systems will inherit.

This is also why organizations should not try to design the entire hierarchy upfront. Until delivery has provided enough evidence, the organization does not yet know what should be standardized and what should remain local. Designing the hierarchy too early often leads to abstractions that look neat but do not survive contact with reality.

The hierarchy should emerge from practice, not theory.

Intent Flows Down, Learning Flows Up

Once intent exists at multiple levels, the system becomes bidirectional.

Enterprise and domain intent flow downward as constraints, standards, and shared models. Projects inherit what the organization already knows.

At the same time, learning flows upward. Projects discover new patterns, new constraints, and new governance needs. Some of these remain local. Some are promoted upward so the organization can reuse them.

So the hierarchy is not just a structure for inheritance. It is a structure for organizational learning.

Intent flows down. Learning flows up. Intent is shaped continuously between the two.

The Core Idea

The key idea of this article is simple.

Intent does not begin as a hierarchy.
Intent emerges through delivery.
Intent is shaped through execution and learning.
Intent is promoted upward when it becomes reusable.
Intent flows down through inheritance, and learning flows up through feedback.
The hierarchy is not designed first. It emerges over time.

This is what prevents Intent-Driven Development from becoming bureaucracy, and what keeps architecture connected to delivery.

Intent-Driven Development is not just a way to write specifications. It is a way for organizations to learn, structure what they learn, and reuse that knowledge safely at scale.

That is how organizations govern intent while delegating execution.

Next Article ->

Intent-Driven Development – The Learning Organization

Organizations used to manage people, then processes, then software. Soon they will manage agents. But what they really need to manage is intent. Intent-Driven Development provides the structure for how intent flows through an organization and how organizations learn over time.