Why DCL
DCL exists because business capability is a missing or poorly preserved architectural unit. Strategy, architecture, delivery, and runtime systems all depend on capability meaning, but that meaning is often weakened as it moves through prose, diagrams, tickets, APIs, services, platform settings, and code.
DCL treats capabilities as architecture. It is an experimental attempt to make capability meaning explicit, inspectable, and compiler-verifiable.
The problem is not syntax
Software teams already have many useful syntaxes. Programming languages, configuration languages, modelling notations, diagrams, tickets, and documentation all carry part of the system story. The gap DCL addresses is not a shortage of ways to write things down.
The gap is that business capability is rarely represented as a durable language primitive. The responsibility a system exposes is often implied by service names, endpoint shapes, backlog items, workflow diagrams, or implementation code.
Business capability gets lost
Business strategy becomes initiatives. Initiatives become architecture. Architecture becomes delivery plans. Delivery plans become software implementation. Implementation becomes runtime behaviour.
At each layer, the original capability meaning can become fragmented. A decision that began as a business responsibility may later appear as an API route, a queue, a handler, a table, a retry policy, and a dashboard alert, with no single artefact preserving what the capability means.
DCL is for the architectural meaning that gets lost between strategy and code.
Existing code models implementation
General-purpose programming languages are excellent at describing how software runs. They model functions, types, modules, control flow, data structures, and runtime behaviour. They can express business logic, but they do not usually model business intent as architecture.
DCL describes what software means before describing how it is implemented. It names the capability, the intent that asks for it, the outcomes it can produce, the effects it may cause, the events it emits or awaits, and the policies that govern it.
Diagrams and documents are useful but not enough
Architecture documents and diagrams help people reason about systems. They can explain context, trade-offs, boundaries, and design intent in ways that code alone rarely can.
But most documents and diagrams are not compiler-verifiable. They can drift from implementation, leave references ambiguous, or describe behaviours that are never checked as part of the language model.
DCL is not a replacement for human explanation. It gives explanation a language-level anchor.
Why capability should be a language primitive
A capability is a unit of architecture. It is the responsibility a system or context exposes to its environment. That responsibility should be visible before teams have already committed to service boundaries, queues, handlers, screens, database tables, or infrastructure choices.
Treating capability as a language primitive lets a model talk directly about intent, outcomes, rules, policies, effects, events, and lifecycle progression. The result is not merely a collection of information from existing sources. It is a source-level representation of capability meaning.
Why compiler validation matters
Compiler validation makes capability meaning inspectable in a different way from prose. The compiler can check references, detect ambiguity, validate policy attachment, analyse lifecycle structure, and report semantic problems early.
DCL makes business capability compiler-visible. That does not make a model automatically correct, complete, or production-ready. It does mean the model can be checked as a language artefact instead of relying only on informal review.
Why this matters more in the AI era
AI-assisted tools work best when context is structured, explicit, current, and checkable. Loose prose, stale diagrams, and fragmented implementation details make it harder to understand what a system is responsible for and why.
DCL does not currently claim production AI integration. It is designed to support future tools that can inspect capability models, reason over compiler-checked semantics, and help teams understand architectural intent without flattening it into implementation details.
What DCL is not
- DCL is not infrastructure-as-code.
- DCL is not just documentation.
- DCL is not a framework convention.
- DCL is not a claim that diagrams, prose, tests, or code are unnecessary.
- DCL is not production-ready language infrastructure.
DCL is a language for expressing what a system is responsible for, what intent it accepts, what outcomes it can produce, what it causes, and what policies govern it.
Where DCL is going
DCL is experimental. The current project focuses on the language shape, compiler validation, learning material, examples, and a browser playground. Future work may include stronger editor support, language-server features, MCP tooling, richer projections, documentation generation, and integration points for AI-assisted understanding.