External use case · Provided by Appmilla
Replacing BDD Glue with Capability-Driven Verification
The Context
An autonomous software factory was built to take a feature request through specification, implementation, deployment, and verification using locally hosted AI models.
The factory followed a strong principle: no stage should simply claim that work is complete. Each stage should produce evidence that can be independently checked.
Behaviour-Driven Development (BDD), using Gherkin and specification-by-example, was originally used as part of the specification and verification process.
The scenarios themselves were useful. The problem was everything required to make them executable.
The Problem
Executing BDD scenarios required a growing layer of technical glue.
Each scenario needed step definitions that connected natural-language statements to implementation code. Different technology stacks required different test runners and integrations. Additional bridge code was needed to make the specification layer work reliably within the automated factory.
Over time, much of the complexity was no longer improving the specification or the software being built. It existed simply to connect the specification to the test framework.
In one real service, eight Gherkin scenarios containing 29 steps had been written but were never connected to executable verification. Doing so was estimated to require around 22 step definitions, a 151-line bridge, another test dependency, and additional runner configuration.
The specification existed.
The verification did not.
Could the responsibility of the software be specified independently from the mechanism used to verify it?
The DCL Experiment
DCL was evaluated as an alternative specification layer.
Instead of describing executable test scenarios, the feature was described as a capability: its intent, possible outcomes, rules, effects, events, lifecycle, policies, and observations.
The DCL compiler then provided a deterministic check that the specification itself was structurally and semantically valid.
Verification was treated as a separate concern.
Rather than executing the specification through step definitions inside the application, verification obligations were derived from the capability definition and executed from outside against the deployed service.
The resulting model was:
DCL capability → compiler validation → derived verification → running system
This removed the need for the specification to know anything about the language or framework used to implement the service.
The Result
A real feature was specified in 38 lines of DCL and reached a successful compiler validation in 2 minutes and 35 seconds.
General derivation rules were then used to turn the capability definition into outside-in assertions against the deployed application.
The final verification ran 13 derived assertions against the live service.
All 13 passed.
No BDD step definitions were required. No test-framework bridge was required. No application-language-specific BDD runner was required.
The experiment also demonstrated another property of DCL.
When a locally hosted AI model was asked to generate a capability, it produced a structurally convincing specification but invented two values that did not exist in the DCL language. The compiler rejected both with precise diagnostics.
This created a useful boundary between probabilistic generation and deterministic verification:
AI can propose the specification. The compiler decides whether it is valid.
What DCL Provided
DCL did not replace testing.
Instead, it changed the relationship between specification and verification.
The capability became the machine-checkable statement of what the software was responsible for. Verification could then be derived from that meaning and executed using whatever mechanism was appropriate for the target system.
For this software factory, that meant replacing a growing layer of BDD execution glue with a simpler model:
Specify the capability. Validate the specification. Derive the verification. Test the running system.
Following the experiment, DCL was adopted as a trial specification path within the factory, behind a configuration switch with the existing BDD process retained as a fallback.
The experiment provides an early example of DCL being used beyond architecture documentation: as a compiler-verified specification language within an AI-assisted software delivery process.