Capability Model
BDL uses a layer-aware capability model.
A feature must not be described with one generic supported flag because different layers can have different availability.
The four capability layers
| Layer | Question |
|---|---|
| Native Barsa | Does the Barsa platform provide the capability? |
| Runtime Support | Can the active runtime execute or apply it? |
| BDL Expressibility | Can the BDL language represent it? |
| BDL Authoring Availability | Is governed authoring available for it in the active authoring surface? |
Why the distinction matters
A capability may exist natively in Barsa but not yet be exposed through the active BDL runtime or authoring surface.
Likewise, BDL may be able to express a structure that the current governed authoring surface does not permit authors or AI systems to generate.
For this reason, documentation and tooling must evaluate all relevant layers independently.
Native Barsa
This layer describes the underlying Barsa platform capability.
It answers whether the native platform understands or provides the feature independently of BDL.
Native support alone is not sufficient evidence that BDL authoring is available.
Runtime Support
Runtime Support describes whether the active BDL runtime can process, execute, import, export, validate, or apply the capability through governed native services.
Runtime behavior is version-specific.
BDL Expressibility
BDL Expressibility describes whether the language model has a valid representation for the capability.
A feature can be expressible in the language while still being unavailable for production authoring.
BDL Authoring Availability
Authoring Availability describes whether human authors or AI systems are permitted to generate and apply the capability through the active governed authoring surface.
This layer can be restricted by:
- Runtime limitations
- Safety requirements
- Validation requirements
- Missing metadata resolution
- Approval requirements
- Known gaps
- Version-specific restrictions
Capability evaluation
Before authoring a feature, evaluate these questions in order:
- Does Native Barsa support the feature?
- Does the active runtime support the required operation?
- Can the active BDL version express it?
- Is production authoring available?
- Are there diagnostics, approval requirements, or known gaps?
Do not infer support
Authors and AI systems must not infer availability from similar features.
The presence of a property, artifact kind, runtime API, or native Barsa feature does not automatically authorize BDL production authoring.
Use the capability documentation for the active versions and contracts.
Example
Consider a hypothetical feature that exists in Native Barsa and is expressible in BDL, but has no governed production authoring path in the current runtime.
Its capability profile could be interpreted as:
| Layer | Result |
|---|---|
| Native Barsa | Available |
| Runtime Support | Limited or unavailable |
| BDL Expressibility | Available |
| BDL Authoring Availability | Not available |
This is why a single supported value would be misleading.
Version context
Capability statements must be tied to the relevant version context.
At minimum, distinguish:
- BDL language version
- Knowledge baseline
- Native Barsa contract version
- Runtime or troubleshooting knowledge version
Do not assume that these version numbers advance together.
Next
Continue to Validation to understand how BDL definitions are checked before governed execution.