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.

The Intent Hierarchy – How organizations structure intent across enterprise, domain, and project scopes without duplication

In Article 10, we established what an IDD specification contains, describing the six elements that enable autonomous systems to execute reliably while remaining aligned with human purpose. That article addressed a foundational question: what does a well-formed specification look like?

As organizations begin to scale this approach beyond individual teams, however, a second question naturally emerges: how do we avoid duplicating the same intent across hundreds of project specifications?

When teams write their first few IDD specifications, certain elements begin to repeat almost immediately. Regulatory requirements such as GDPR appear in every specification. Infrastructure constraints, AWS, security baselines, monitoring standards, are restated. Domain models resurface across projects. Architectural patterns such as CQRS or event-driven communication are described again and again. At small scale, this repetition is tolerable, even helpful. At enterprise scale, it becomes a liability.

Consistency becomes increasingly difficult to maintain. When GDPR guidance changes, updating it across hundreds of specifications is impractical. When the organization adopts a new technology standard, propagating that change requires coordinated effort across teams. Over time, knowledge fragments, with slightly different interpretations of the same intent scattered throughout the organization.

The solution is not to remove these elements. They remain essential for autonomous systems to execute correctly. The solution is to structure them so they can be defined once, at the appropriate level, and reused consistently.

The Intent Hierarchy is the mechanism by which Intent-Driven Development scales: shared intent is defined once at the right level, inherited by default, and refined continuously through evidence from implementation.

The Structure of Organizational Intent

Intent exists at multiple scopes within an enterprise, and understanding these scopes is key to structuring it effectively. Some intent applies universally across the organization, regardless of domain or project. Some applies within a specific business domain, reflecting how that part of the business operates. Some is unique to an individual feature or initiative.

The Intent Hierarchy makes these scopes explicit and connects them through inheritance.

At the highest level, Organization Intent defines what applies enterprise-wide. This includes technology standards, architectural patterns, security and privacy baselines, compliance approaches, and ethical principles that govern all work.

At the next level, Domain Intent defines what applies within a bounded context. This is where domain models, business rules, ubiquitous language, and domain-specific patterns are established, reflecting how a particular part of the business actually operates.

At the most specific level, Project Intent defines what is unique to a feature or initiative. This includes goals, validation criteria, constraints, and ethical considerations specific to that piece of work.

Each level inherits from the level above it, adding specificity appropriate to its scope. A project within the Shopping domain, for example, inherits both the organizational standards that apply across the enterprise and the domain-specific context that defines how shopping works within the business.

Inheritance and Promotion

Inheritance, however, is only part of the model.

While intent flows downward through the hierarchy, it must also evolve upward if the system is to remain grounded in reality. Patterns that emerge through project implementations are not confined to the project level. When those patterns prove effective, they are recognised and promoted into domain intent. When similar patterns appear across domains, they are elevated further into organizational intent.

In this way, the hierarchy becomes a living system in which intent is both governed and continuously refined.

Intent is not only inherited, it is earned.

This bidirectional flow ensures that the hierarchy remains connected to implementation reality rather than becoming an abstract architectural construct – like ivory tower architecture. It also reflects a deeper principle that runs throughout Intent-Driven Development: systems improve not only through design, but through feedback.

Visual Representation

What Lives at Each Level

The effectiveness of the Intent Hierarchy depends on placing concerns at the appropriate level. Organizational intent should not include feature-specific detail, and project intent should not redefine domain models. Each level must contain what naturally belongs to its scope.

At the organizational level, intent defines how the enterprise operates as a system. Organizations do not control regulations such as GDPR, but they do control how those regulations are implemented in practice. That implementation, how deletion requests are handled, how retention policies are enforced, how audit trails are maintained, is organizational intent.

This level also defines technology standards, architectural patterns, security and privacy baselines, and ethical principles. Ownership typically sits with enterprise architecture, the CTO office, and security and compliance teams, working in collaboration with domain experts and project teams who surface patterns from implementation. These elements tend to change relatively slowly, evolving through evidence gathered from practice.

At the domain level, intent captures the reality of the business within a bounded context. This is where domain entities, business rules, and ubiquitous language are defined, along with the events that describe meaningful changes within the domain. Ownership rests with domain experts, product architects, and senior engineers who have the deepest understanding of how the business operates. This layer evolves more frequently, reflecting changes in business understanding and learning from implementation.

At the project level, intent becomes fully specific. This is where the six elements defined in Article 10 are expressed in detail for a particular feature or initiative. Crucially, this level references inherited organizational and domain intent rather than restating it, allowing project specifications to remain focused on what is unique.

How Intent Inheritance Works

When a project inherits from domain and organizational intent, it gains all relevant context without duplication. Compliance approaches, technology standards, architectural patterns, domain models, and security baselines are all applied automatically.

This inheritance is not optional. It is the mechanism that ensures consistency across the enterprise.

Projects can extend inherited intent by adding constraints that are specific to their context. They can also, where necessary, request exceptions. However, they cannot silently override inherited intent. Any deviation must be explicit, justified, and subject to review.

In practice, this means that projects can strengthen constraints but not relax them without approval. A project handling particularly sensitive data might require stronger encryption than the organizational baseline, but it cannot reduce that baseline unilaterally.

When Intent Conflicts

Conflicts between levels of intent are inevitable, particularly in complex organizations where regulatory requirements, business needs, and technical constraints intersect.

These conflicts must be addressed explicitly.

By default, higher levels of the hierarchy take precedence, ensuring consistency across the organization. Exceptions are permitted, but they must be documented, justified, and time-bound.

Domain-level changes, when required, propagate automatically to all projects within that domain, ensuring that shared understanding evolves consistently.

Importantly, no level of the hierarchy is beyond challenge. Evidence from implementation can and should be used to refine both domain and organizational intent. This keeps the hierarchy responsive to reality.

Ethical conflicts are treated differently. Where a proposed system conflicts with established ethical principles, the conflict must be escalated rather than negotiated away. Systems that cannot operate within defined ethical boundaries should not be built.

Governance of the Intent Hierarchy

Each level of the hierarchy has clear ownership, but governance is not purely a top-down activity. It is a continuous process of balancing strategic direction with practical evidence.

At the organizational level, governance involves recognising patterns that emerge across domains, formalising them into standards, and ensuring alignment with regulatory and strategic context.

At the domain level, governance involves maintaining the integrity of the domain model, refining it as understanding evolves, and extracting patterns from project implementations.

At the project level, governance involves defining specific intent, implementing it effectively, and surfacing insights that may be valuable at higher levels.

In this sense, the Intent Hierarchy functions as a feedback system, not unlike those found in control theory or the scientific method, where desired states are continually compared with observed outcomes and adjusted accordingly.

At an enterprise level, this is how the core principle operates:

Govern Intent. Delegate Execution.

Intent is governed at the appropriate level, organizational, domain, or project, while execution is delegated to systems operating within those boundaries.

Anti-Patterns

Organizations implementing an Intent Hierarchy tend to encounter a consistent set of failure modes.

The God Layer emerges when too much is defined at the organizational level, leaving little room for domain or project-level adaptation and ultimately constraining innovation.

The Orphan Projects pattern arises when projects fail to inherit shared intent, leading to duplication, inconsistency, and compliance risks.

The Abandoned Layers problem occurs when organizational or domain intent is defined once but not maintained, resulting in documentation that no longer reflects reality and is consequently ignored.

The Inheritance Spaghetti anti-pattern appears when inheritance paths become overly complex, with conflicting sources of intent creating confusion and slowing delivery.

Finally, Premature Abstraction occurs when organizations attempt to define a hierarchy before sufficient patterns have emerged, resulting in structures that do not align with actual needs.

In practice, it is better to tolerate some duplication initially and extract hierarchy once patterns become clear through implementation.

Intent Hierarchy in Practice

To make this concrete, consider how the Abandoned Cart Recovery example from Article 10 would be structured with an Intent Hierarchy in place.

Without a hierarchy, the specification restates everything, GDPR requirements, AWS infrastructure, domain models, architectural patterns, and security standards, resulting in a document of several thousand words, much of it duplicated across projects.

With a hierarchy, the project specification focuses only on what is unique, referencing inherited intent rather than restating it. The result is significantly smaller, more focused specifications, with shared concerns defined once and reused consistently.

Changes to organizational standards propagate automatically. Domain models evolve once and are inherited everywhere. Consistency is achieved not through repetition, but through structure.

When to Implement It

The Intent Hierarchy provides value when organizations reach a scale where duplication becomes costly and coordination becomes difficult.

It is particularly useful when multiple teams operate within shared domains, when compliance requirements must be applied consistently across systems, and when organizational standards have matured through practice and need to be reused systematically.

Conversely, it is less appropriate in small or highly experimental environments, where the overhead of maintaining a hierarchy may outweigh its benefits.

In practice, it is often better to start without a hierarchy and introduce it when patterns become clear and duplication becomes painful.

The Core Principle

The Intent Hierarchy exists to solve a specific problem: how to scale intent across an organization without duplicating it, while ensuring that it remains grounded in reality.

It recognises that intent operates at multiple levels, that expertise is distributed across those levels, and that effective systems require both consistency and adaptability.

By structuring intent hierarchically, allowing it to be inherited by default and refined through practice, organizations can scale Intent-Driven Development from individual specifications to enterprise capability.

Hierarchy is a tool, not a goal. Its purpose is to ensure that systems execute reliably, remain aligned with human intent, and continue to evolve as understanding improves.

This is how Intent-Driven Development scales, from individual specifications to enterprise capability, without losing coherence or connection to reality.

Next Article ->

Intent-Driven Development – Intent Evolution and Intent Shaping

Traditional architecture often tries to define standards before delivery begins. Intent-Driven Development works the other way around. Intent emerges where work happens, is shaped through execution and measurement, and is promoted upward when it becomes reusable. The hierarchy is not the starting point. It is the result of learning.