Modules and namespaces#

Business Language source is parsed as a sequence of declarations and statements. Organization declarations give those declarations a package, namespace, dependency, and module structure.

Packages#

Use package to identify a package namespace. A package can end with a semicolon or contain configuration entries.

package erp.finance;

package erp.finance {
  owner: "finance";
  version: "1.0";
}

Namespaces#

Namespaces group declarations under a qualified name.

namespace erp.finance;

namespace erp.finance {
  table LedgerAccount {
    field account_id: string key;
  }
}

Modules#

Modules are named declaration containers. A module can contain imports, exports, tables, subscriptions, entities, services, APIs, forms, apps, controls, fields, validations, functions, rules, tests, messages, labels, configurations, errors, annotations, and nested modules.

@audited
module AccountsPayable {
  import erp.finance;

  field VendorId: string {
    max_length: 40;
  }

  table Vendor {
    field vendor_id: VendorId key origin;
    field vendor_name: string max_length(120);
  }
}

Module headers are property-based:

module Sales {
  version: "1.0";
  owner: "sales";
} {
  service SalesService {
  }
}

Imports and exports#

Use imports and exports to control module dependencies. Top-level files and module bodies support the same import and export declaration shapes.

import erp.finance;
import erp.finance(LedgerAccount, JournalEntry);
import erp.shared();

export erp.finance;
export * from erp.finance;
export * from "erp.shared";

Import and export paths are dot-separated importPath values. A path segment can include hyphen-separated identifier parts, so import erp.finance-core; is valid. package and namespace declarations use qualifiedIdentifier, so their segments are identifiers and do not use hyphens.

Prefer explicit imports for public ERP modules. Re-export only deliberate module surfaces so tenant-specific policy tables and internal resolver helpers do not leak across package boundaries.

Workspaces#

Workspaces hold configuration entries for a named source workspace.

workspace erp.sandbox {
  owner: "platform";
  strict: true;
}

Workspace entries use the same config entry shape as package bodies.

Using declarations#

using supports package version, selected imports, aliases, and conditional inclusion.

using erp.finance @1.0.0 { LedgerAccount, JournalEntry } as Finance if enabled;

Config entries#

The generic config syntax supports scalar or nested values:

For the full syntax and policy boundary, see Configuration declarations.

runtime: "wasm";

compiler options {
  strict: true;
  target: "native";
}