How do you specify your intent with sufficient clarity that autonomous systems can execute reliably

Across the first nine articles in this series, we have explored the foundations of Intent-Driven Development.

We examined why traditional implementation-centred delivery models struggle in an environment where AI systems can generate software at extraordinary speed. We explored how Intent-Driven Development integrates with existing practices such as User-Centred Design, Domain-Driven Design, Behaviour-Driven Development and Test-Driven Development. We introduced governance mechanisms such as risk dials and human gates, and we examined how intent fidelity allows organisations to measure whether autonomous systems remain aligned with the intent that governs them.

We also explored how organisations progress through evidence-based maturity stages, and how the role of practitioners evolves as the centre of gravity shifts from implementation to the design of intent.

At this point in the journey, a practical question inevitably arises:

What does an Intent-Driven specification actually look like?

This article begins to answer that question.

It does not prescribe. The AI landscape is evolving too rapidly, and organisational contexts vary too widely, for any single template to become canonical. Teams will naturally adapt these ideas to the tools they already use, whether that means Markdown documents in repositories, Confluence pages, Jira epics, Notion workspaces or Linear issues.

What matters is not the container.

What matters is that the specification captures the elements that allow autonomous systems to execute reliably while remaining aligned with human intent.

In an Intent-Driven environment, specifications become the artefact through which practitioners govern intent while delegating execution.

The Six Elements of Intent

An effective Intent-Driven specification answers six fundamental questions.

If these questions are clear, autonomous systems can execute safely. If they are ambiguous, implementation drift becomes inevitable.

These six elements are not arbitrary categories. They emerge naturally from the disciplines Intent-Driven Development integrates, User-Centred Design, Domain-Driven Design, Behaviour-Driven Development, Test-Driven Development, and from the governance requirements that prevent autonomous systems from drifting away from human purpose.

Note on evolution

These six elements evolved from the five foundational questions introduced in Article 1. As the Intent-Driven Development framework matured—particularly through the integration of Domain-Driven Design discussed in Article 2, it became clear that domain context required explicit treatment.

Originally, domain understanding sat implicitly within the question “what does success look like?”. In practice, however, autonomous systems require far richer contextual grounding than human teams typically make explicit. Business entities, domain language, bounded contexts and invariants form the conceptual world in which implementation occurs.

As a result, Domain Context emerged as a distinct element of the specification. Separating it from success criteria ensures that autonomous systems understand not just what must be achieved, but the business model within which that achievement must make sense.

1. Intent: The “Why” and the “What”

The first section establishes the fundamental purpose of the system.

Why are we building this?
What problem does it solve?
What outcome defines success?

Without clear articulation of intent, everything downstream becomes interpretation. Autonomous systems will inevitably fill gaps with assumptions. Those assumptions may be technically coherent while still being strategically misaligned.

Intent should answer questions such as:

• What problem are we solving?
• For whom are we solving it?
• What does success look like?
• Why does this matter to the business?
• What outcome are we optimising for?

This is where User-Centred Design thinking becomes foundational. If you cannot clearly articulate the user need and business value, you are not yet ready to delegate implementation.

2. Domain Context: The “World”

The second section situates the specification within its domain.

Autonomous systems perform far more reliably when they understand the conceptual model within which they are operating. Domain-Driven Design provides the structure here.

Domain context should clarify:

• Which bounded contexts are involved
• What entities, aggregates and value objects exist
• What ubiquitous language the organisation uses
• What business rules and invariants must hold
• How this specification fits within the broader domain model

When agents lack domain context, they default to generic patterns. The code may compile and tests may pass, but the implementation will not reflect how the business actually understands the problem.

In organisations managing multiple projects within the same domain, much of this context may be defined once at the domain level and referenced by individual specifications rather than repeated.

This pattern becomes increasingly valuable as Intent-Driven Development scales across enterprise environments.

3. Success Criteria: The “Done”

The third section defines what success looks like in measurable terms.

Both functional requirements (what the system must do) and non-functional requirements (how well it must perform) belong here.

Success criteria typically specify:

• Functional requirements
• Non-functional requirements such as performance, security and scalability
• Acceptance criteria expressed using Behaviour-Driven Development scenarios
• The definition of “complete”
• The threshold for “good enough”

Without clear success criteria, intent fidelity cannot be measured. An implementation may work, but there is no reliable basis for determining whether it works correctly.

4. Validation: The “Proof”

This section defines how we prove the implementation reflects the governing intent.

Validation embodies the spirit of Test-Driven Development by specifying what must be tested, which edge cases matter, and how the system should behave when things go wrong.

Validation should address:

• Test scenarios that prove the system works
• Edge cases that must be handled
• Expected behaviour under failure conditions
• Performance benchmarks
• The evidence required to confirm completion

Autonomous systems are particularly strong in this area. When validation criteria are well defined, agents can generate comprehensive test suites that explore far more combinations than humans typically consider.

But they can only do this when the validation intent has been clearly articulated.

5. Constraints: The “Boundaries”

The fifth section defines the boundaries within which implementation must operate.

Constraints include:

• Technical platform limitations
• Architectural patterns
• Existing system integrations
• Resource limitations
• Regulatory and compliance obligations

Constraints are not restrictions on creativity. They are the operational and architectural realities within which solutions must function.

Autonomous systems require these boundaries to be explicit.

Many constraints, such as organisational architecture standards, technology stacks and compliance requirements, often apply across many projects. Mature IDD organisations typically define these once and allow project specifications to inherit them rather than duplicating them repeatedly.

6. Ethical Considerations: The “Should We”

The final section addresses a question that autonomous systems cannot answer:

Should this system exist at all?

As discussed earlier in this series, certain decisions must remain permanently human. Ethical judgement is one of them.

Ethical considerations should explore:

• Who is impacted by the system
• Potential harms that might arise
• Biases that might emerge
• Privacy implications
• Mitigation strategies

When autonomous systems can build rapidly, the question of whether to build becomes as important as how to build.

Many organisations are unaccustomed to making ethical reasoning explicit. But doing so becomes essential when implementation can be delegated to machines.

A Detailed Example: Abandoned Cart Recovery

To illustrate how these elements come together in practice, consider a common e-commerce scenario: implementing an abandoned cart recovery system.

The example below is intentionally detailed. It shows how the six elements of an Intent-Driven specification can be expressed in a form that autonomous systems can execute against reliably while remaining aligned with human intent.

If you prefer, you can also make the full example available as a downloadable Markdown reference.

Example IDD Specification: Abandoned Cart Recovery

Adapting to Your Context

The example above is deliberately comprehensive and provides lots of different examples. Not every specification needs this level of detail.

More detailed specifications are appropriate when:

• systems operate in high-risk domains
• domain models are complex
• regulatory documentation is required
• teams are new to Intent-Driven Development
• multi-agent coordination is required

Simpler specifications may suffice when:

• systems have limited blast radius
• domains are well understood
• teams share strong contextual knowledge
• prototypes are being explored
• risk levels are low

The goal is not documentation for its own sake.

The goal is clarity of intent.

Starting with Intent-Driven Specifications

For teams beginning their IDD journey, start with two sections:

Intent and Constraints.

Those two elements alone dramatically improve clarity. They force teams to articulate why something should be built and what boundaries govern it.

As teams gain experience, additional elements can be added:

• Domain Context
• Success Criteria
• Validation
• Ethical Considerations

Over time, specifications become more precise and shared language emerges.

What initially feels like additional effort becomes the mechanism that prevents costly misalignment.

What Specifications Enable

When specifications capture these six elements clearly, several capabilities emerge.

Autonomous systems can execute reliably because they have the context, constraints and success criteria required to generate aligned implementations.

Cross-functional teams gain shared understanding because product, engineering, design, security and QA contribute to the same governing artefact.

Intent fidelity becomes measurable because implementations can be evaluated against explicitly defined expectations.

Governance becomes evidence-based because risk dials can be adjusted according to observed alignment.

Institutional knowledge accumulates because specifications record what was intended, not just what was built.

And accountability remains clear.

Delegating execution does not delegate responsibility.

The humans who authored the specification remain responsible for the outcomes it produces.

Scaling Intent Across the Organisation

As organisations mature in their use of Intent-Driven specifications, an interesting pattern begins to emerge.

Many elements of intent are shared across multiple projects.

Industry compliance obligations, organisational architecture standards, platform choices and domain models often apply consistently across teams.

Repeating this information in every project specification quickly becomes inefficient.

Instead, organisations begin structuring intent hierarchically.

Certain elements of intent are defined once at industry, organisational or domain level and then inherited by project specifications.

This approach reduces duplication while ensuring consistent governance across the enterprise.

Managing intent at this scale requires thinking beyond individual specifications toward a broader structure for organising and governing shared intent.

That architectural question will be explored in the next article.

The Core Message

Specifications are not bureaucracy.

They are the artefact through which practitioners govern autonomous systems.

In an environment where AI can build almost anything at speed, the question is no longer whether specifications are necessary.

The real question is whether they are clear enough to safely delegate execution.

The six elements described here, Intent, Domain Context, Success Criteria, Validation, Constraints and Ethical Considerations, provide a practical structure for specifications that enable autonomous systems to execute reliably while remaining aligned with human purpose.

Your specifications will not look exactly like the example above. They should not.

Your domain, regulatory environment, organisational culture and technology stack will all influence how these ideas are expressed.

What matters is that the specification answers the fundamental questions that allow autonomous systems to execute while remaining aligned with human intent.

Start where you are. Use the tools you have. Refine through practice.

The format will evolve.

The principles will endure.

Next Article ->

Intent-Driven Development – The Intent Hierarchy

The Intent Hierarchy is how Intent-Driven Development scales: shared intent is defined once, inherited everywhere, and refined through implementation. It allows organizations to maintain consistency without duplication, and autonomy without losing alignment with human intent.