Skip to main content

Known Gaps

This page records the current documented gaps and limitations for the active BDL knowledge baseline.

Known gaps are part of the contract. Authors and AI systems should not bypass them by guessing unsupported values or assuming behavior that has not been proven.

Closed gaps​

The following previously tracked gaps are closed in the current v5.2 baseline:

  • REPORT-GANTT-EXPORT-GAP-01
  • FORM-MULTICOLUMN-EXPORT-GAP-01
  • WORKFLOW-EXPORT-PARITY-GAP-01
  • WORKFLOW-ACTIVE-STATE-PARITY
  • WF_EXCLUSIVE_CONDITION-WARNING false positive
  • FOLDER-FIRSTCLASS-EXPORT-01
  • GENERAL-OBJECT-SINGLE-EXPORT-01
  • E06/E11 current entity rules and commands

Closed means the corresponding tracked gap has been resolved for the documented baseline. It should not be generalized to unrelated versions or environments.

Documented native limitation​

WF-START-FORM-LOSSLESS-LIMITATION​

Native StartActivityDefInfo does not persist the form TypeViewId in a way that can be proven for lossless reverse export.

As a result, the exporter omits node.variableRef in this situation rather than guessing the form.

This is an intentional safety rule:

  • Missing native evidence must not be fabricated.
  • Reverse export must prefer omission plus a documented limitation over an invented value.
  • Authors should not interpret the absence of the value as an exporter defect when this native limitation applies.

Out of current scope​

The current first-class create/reuse contract for page and group does not close these folder operations:

  • Update
  • Rename
  • Move
  • Delete

These operations should therefore not be assumed to be available merely because first-class page and group creation or reuse exists.

How to use this page​

Before authoring or diagnosing a feature:

  1. Check whether the feature is listed as a current limitation.
  2. Confirm the active BDL and runtime versions.
  3. Check the capability model and authoring surface.
  4. Do not work around a known gap by inventing native IDs, state or unsupported properties.
  5. If new evidence shows the limitation is no longer valid, treat that as a candidate for contract and evidence review rather than silently removing the restriction.

Closed versus current​

A closed gap is historical evidence that a specific tracked issue was resolved.

A current limitation remains part of the active authoring or runtime contract until supported evidence closes or changes it.

Version awareness​

Known-gap status is version-sensitive.

Always distinguish:

  • BDL language version
  • Knowledge baseline
  • Native Barsa contract version
  • Runtime and troubleshooting baseline

Do not assume that a gap closed in one baseline is closed in every deployment.

Next​

Continue to AI Authoring Guidance for rules that AI systems should follow when generating BDL.