Artifact Reference

Artifacts are the primary building blocks of a BDL definition.

Each artifact represents a governed piece of Barsa system metadata or behavior.

Artifact kinds

The current BDL model includes the following artifact kinds:

Kind	Purpose
entity	Defines data entities, fields, relations, views, commands and entity-level behavior.
form	Defines user-facing forms, layouts, field states, tabs, groups and sections.
report	Defines supported report structures, data presentation and report configuration.
workflow	Defines processes, activities, variables, actors, bindings and workflow layout.
rule	Defines governed business rules.
command	Defines governed commands and actions.
permission	Defines access-control metadata where supported.
menu	Defines menu and navigation metadata.
notification	Defines governed notification metadata.
seedData	Defines governed initial or reference data.
systemCode	Defines approved system-level code slots.
page	Defines page metadata available in supported BDL v5.2 authoring surfaces.
group	Defines grouping metadata available in supported BDL v5.2 authoring surfaces.

Common artifact principles

Although artifact shapes differ, the following rules apply broadly:

• Use stable codes and explicit identifiers.
• Do not invent native Barsa IDs.
• Resolve live metadata before authoring when native identifiers are required.
• Keep artifact definitions minimal and explicit.
• Validate against the active BDL version.
• Check authoring availability separately from language expressibility.
• Treat diagnostics and known gaps as part of the authoring contract.

Entity artifacts

An entity artifact can describe the data model and entity-level behavior of a Barsa system.

Typical entity concerns include:

• Fields
• Field types
• Relations
• Defaults
• Calculations
• Views
• Commands
• Business rules
• Entity settings

Form artifacts

Form artifacts describe UI structure and field presentation.

Typical form concerns include:

• Layout
• Field state
• Semantic rows
• Tabs
• Groups
• Sections
• Form settings

Report artifacts

Report authoring is version- and runtime-aware.

Supported report families may include:

• Tabular
• Statistical
• Print
• Tree
• Matrix
• Calendar
• Gantt
• Dashboard-oriented reporting

Availability must be checked against the active runtime and authoring surface.

Workflow artifacts

Workflow artifacts can represent:

• Process structure
• Activities
• Variables
• Actors
• Form bindings
• Activity metadata
• Visual layout

Workflow authoring must follow runtime and approval requirements.

Rules and commands

Rules and commands are governed behavioral artifacts.

Their valid placement and execution depend on the host artifact and the active authoring surface.

Permissions, menus, pages and groups

Navigation and access-control artifacts are capability-gated.

Their presence in the language model does not imply unrestricted production authoring.

Notifications and seed data

BDL can represent governed notifications and initial data where supported by the active contracts.

System code

System code is a governed artifact surface and should never be treated as unrestricted arbitrary code execution.

Supported code slots may include approved business logic and Windows client code locations.

Code authoring must follow validation, approval and runtime safety rules.

Version awareness

Artifact availability can change between BDL versions, runtime versions and authoring surfaces.

Always evaluate an artifact across:

1. Native Barsa capability
2. Runtime support
3. BDL expressibility
4. BDL authoring availability

Next

Continue to the Capability Model to understand how support and authoring availability are represented across layers.