Russell East's blog

https://russelleast.github.io/Capability-Language

The Problem Was Never Code

I didn’t set out to create a programming language.

If anything, creating a language sounded like a terrible idea.

The world doesn’t need another language.

What it does need is a better way to describe software systems.

Throughout my career, I’ve worked as a developer, technical lead, solution architect, and principal architect across a range of industries and systems. During that time, I’ve noticed the same pattern repeatedly.

The business talks about capabilities.

Architecture talks about services, domains, integrations, and platforms.

Engineering talks about APIs, queues, databases, workflows, and code.

Operations talks about reliability, observability, recovery, and support.

Everyone is describing the same system.

Nobody is describing it in the same way.

The Loss of Architectural Intent

The original capability — the thing the business actually needs the system to do — becomes fragmented across:

• PowerPoint decks
• Capability maps
• Architecture diagrams
• ADRs
• Jira tickets
• Source code
• Infrastructure definitions
• Tribal knowledge

Eventually the implementation becomes the source of truth. The problem is that implementation is not intent.

A service tells me how something works. It does not necessarily tell me why it exists.

An API tells me how to call something. It does not necessarily tell me what responsibility it owns.

A workflow tells me what happens. It does not necessarily tell me which outcomes matter.

Somewhere between business strategy and software delivery, we lose the architectural meaning of the system.

Architecture’s Documentation Problem

As architects, we’ve spent years trying to bridge this gap.

• We create diagrams.
• We write ADRs.
• We document domains and integrations.
• We build capability maps.

All of these are useful. All of them suffer from the same weakness. They are passive artefacts. They cannot be validated. They cannot be compiled. They cannot tell us when architectural intent has drifted. Over time, they become snapshots rather than living representations of the system.

The Missing Layer

The longer I worked in architecture, the more I became convinced that something fundamental was missing.

• We have languages for implementation.
• We have languages for infrastructure.
• We have languages for APIs.
• We have languages for data.

But we do not have a language for capability. We do not have a language that treats business responsibility as a first-class architectural construct. That realisation became the foundation of the Declarative Capability Language (DCL).

A Different Starting Point

DCL starts with a simple premise:

A capability is a unit of architecture.

Not a service.

Not a controller.

Not an endpoint.

Not a deployment boundary.

A capability is a responsibility that a system exposes.

Once that responsibility is defined, we can describe:

• The intent it accepts
• The outcomes it produces
• The rules it follows
• The effects it causes
• The events it emits
• The policies that constrain it
• The lifecycle it progresses through

These are not documentation conventions.

They become language constructs.

Capability as Code

The goal of DCL is not to replace code.

The goal is not to replace architecture.

The goal is not to generate entire systems automatically.

The goal is to create a durable, compiler-verifiable representation of architectural meaning.

A representation that sits between business intent and implementation.

A representation that can survive organisational change, technology change, and system evolution.

A representation that makes capability itself part of the architecture.

Why AI Makes This More Important

When I started exploring AI-native systems, orchestration runtimes, and architecture intelligence platforms, the problem became even more obvious.

AI systems perform best when context is:

• explicit
• structured
• machine-readable
• unambiguous

Most architecture today is none of those things. Instead, architectural knowledge exists as a mixture of documents, diagrams, code, meetings, and tribal knowledge.

Humans can often navigate this ambiguity.

AI struggles with it.

If we want AI to participate meaningfully in software design and delivery, we need better representations of architectural intent.

We need something more precise than a PowerPoint diagram and more durable than a wiki page.

An Experiment in Architectural Language

In many ways, DCL is an experiment. An experiment in whether capability can become a first-class language primitive. An experiment in whether architecture can be expressed with the same precision we expect from code. An experiment in whether business intent can survive the journey from strategy to software delivery.

I don’t know whether DCL will ultimately succeed. What I do know is that the problem it is trying to solve is real. Business capability deserves to be more than a box on a diagram.

It deserves to be part of the language.