Rules and Commands

This example shows how rule and command artifacts can coexist in a BDL document.

The example focuses on artifact identity and composition without inventing undocumented condition, action, event, parameter, or execution structures.

Example

{
  "schema": "barsa.definition.v1",
  "project": {
    "code": "SAMPLE",
    "caption": "Sample",
    "systemId": "${RESOLVE_SYSTEM_ID}",
    "version": "1.0.0"
  },
  "references": {},
  "artifacts": [
    {
      "kind": "rule",
      "code": "ValidateCustomer",
      "caption": "Validate Customer"
    },
    {
      "kind": "command",
      "code": "ApproveCustomer",
      "caption": "Approve Customer"
    }
  ]
}

Rule artifacts

A rule represents governed logic or behavior expressed through the structures supported by the active BDL baseline.

Real rules may involve conditions, validations, events, expressions, dependencies, or actions.

Do not invent rule syntax that is not documented by the active baseline.

Command artifacts

A command represents an explicit operation or action surface.

Real commands may require parameters, target objects, permissions, runtime behavior, or links to forms and workflows.

Resolve existing targets and identifiers from authoritative metadata.

Rule versus command

A rule usually expresses logic or decision behavior.

A command usually represents an explicit operation that can be invoked.

The exact distinction and available structures must follow the active BDL and runtime contracts.

Capability checks

Before relying on a rule or command, verify:

1. Native Barsa supports the intended behavior.
2. Runtime support exists.
3. BDL can express the structure.
4. The authoring surface allows generation of that structure.

Safe authoring pattern

Keep rules and commands small and explicit.

Resolve all external references before execution.

Validate conditions, targets, and runtime assumptions rather than encoding guessed behavior.

System code

Do not use systemCode as a shortcut when a supported rule or command artifact can represent the behavior.

systemCode should remain governed code with explicit review and validation requirements.

Next

The next section demonstrates cross-artifact composition patterns.