When I started designing the Declarative Capability Language (DCL), I wasn’t thinking about regulatory compliance. My goal was much simpler: I wanted a language that could describe what a system is responsible for, entirely independent of frameworks, programming languages, or deployment technologies.
A language centred on capabilities, intent, outcomes, effects and policies rather than controllers, services and APIs. The problem I was trying to solve was architectural clarity.
Recently I’ve been sharing the language with different large language models, not to generate code, but to critique the language itself. I asked them the difficult questions you’d ask any design partner:
- Where is the language weak?
- What concepts are missing?
- Does it make sense?
- Could you build software from this?
- What kinds of systems could it describe?
Some of the answers were expected, mostly surrounding syntax tweaks or better examples. But then something unexpected happened. Different models, working completely independently, began identifying use cases that I hadn’t originally considered.
The strongest recurring theme? AI governance and system assurance.
The Regulatory Challenge
Across every industry, there is increasing pressure to demonstrate how software behaves. For AI systems, this pressure is even greater.
The EU AI Act, GDPR and other regulatory frameworks ask organisations to answer questions such as:
- What decisions does this system make?
- Which data does it process?
- What safeguards exist?
- Where is human oversight required?
- What evidence is produced?
- How can these decisions be audited?
Most organisations already have answers to these questions. The problem is where those answers live.
- Architecture documents.
- PowerPoint slides.
- Wiki pages.
- Design reviews.
- Code comments.
- Slack conversations.
None of them is strongly enough connected to the software they describe. Documentation gradually becomes an approximation of reality.
Why DCL Fits Naturally
The interesting observation wasn’t that DCL had features specifically designed for regulation. It didn’t. Instead, the language already described the exact concepts that governance teams care about because they happen to be the exact concepts architects care about.
In DCL’s semantic model:
- A capability declares what a system is responsible for.
- Actors describe who or what participates.
- Rules constrain behaviour.
- Outcomes make possible results explicit.
- Effects describe interactions with the outside world.
- Policies define the architectural expectations surrounding execution.
- Events and observability describe the evidence a system produces.
Those concepts exist because they are useful architectural concepts. It turns out they are also useful governance concepts. That wasn’t something I planned. It emerged from the semantic model.
From Documentation to Compiler Verification
Traditional governance is largely document-driven. A policy is written, architects interpret it, developers implement it, and auditors review the result. Every single step introduces room for interpretation and the certainty of drift.
DCL suggests a different approach: making the expression of responsibility part of the capability definition itself.
By attaching policies directly to capabilities, the compiler can validate the structure. Documentation, diagrams, and reports all become generated projections of the exact same semantic model. Rather than asking whether the documentation is up to date, the documentation simply becomes another view of the source truth.
AI as a Design Partner
One of the most enjoyable parts of building DCL has been using AI as a sounding board. The models weren’t caught up in the syntax; they recognised that DCL’s semantic model could become a foundation for operational assurance.
That feedback has already actively influenced the language. Recent additions such as agent actors, tool effects, and confidence policies were introduced to better describe AI-native systems, while remaining strictly true to the original principles of the language. The language didn’t become “an AI language”, it just became a better language for describing modern, autonomous systems.
Looking Forward
I still see DCL first and foremost as a language for describing business capabilities. That hasn’t changed. What has changed is my understanding of where those descriptions become valuable.
- Architecture.
- Documentation.
- Code generation.
- AI-assisted development.
- Governance.
- Regulatory reporting.
They all depend on the same thing: an accurate, unambiguous description of what the system is responsible for.
The more I explore DCL, the more I realise that the language isn’t just describing software. It’s describing organisational responsibility. And perhaps that’s why AI kept discovering these new applications before I did.
Leave a Reply