Configuration declarations#

Business Language has lightweight configuration syntax for package metadata, workspace metadata, compiler/runtime settings, and named config declarations. This syntax is not a substitute for ERP policy configuration tables.

Use grammar-level configuration for source/package/runtime metadata. Use tables plus resolver functions for business policy that varies by company, tenant, country, process, or time.

Named config declarations#

The dedicated configuration declaration is intentionally small.

config RuntimeSettings;

config RuntimeSettings {
}

At top level and module scope, named configuration declarations use only config. configuration { ... } is valid as a service config block, not as a named top-level declaration.

service RuntimeSettingsService {
  configuration {
    timeout_ms: 5000;
  }
}

Use named config declarations for tooling or package-level markers. Do not put tenant-owned approval routes, status transitions, thresholds, or workflow outcomes in an empty named config block.

Package config entries#

Packages can end with a semicolon or contain configuration entries.

package erp.finance;

package erp.finance {
  owner: "finance";
  version: "1.0.0";
  strict: true;
}

Package entries are metadata about the package. Keep module-owned policy in tables such as PostingPolicy, ApprovalRoute, or ReasonCode.

Workspace config entries#

Workspaces contain the same config entry shape as package bodies.

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

Workspace config should describe the source workspace or build environment. It should not become a hidden policy registry.

Generic config entries#

The generic config syntax supports scalar values and nested blocks.

runtime: "wasm";
runtime.server.port: 8080;

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

Config values can be expressions or nested blocks. Entries can use : or key-value block style. Config entries may use key: value or key value, and entries may be separated with semicolons or commas. Top-level config keys may be qualified names.

compiler: {
  target: "wasm";
  optimize: true;
};

runtime server {
  host: "127.0.0.1";
  port: 8080;
}

Config entry keys#

Config keys can be identifiers or string literals.

package erp.finance {
  owner: "finance";
  "support-team": "finance-platform";
}

Use string keys when external tooling requires names that are not valid identifiers.

Policy boundary#

If a value can vary by company, country, tenant, process, date, administrator, or customer implementation, model it as table data.

table PostingPolicy {
  field company_code: CompanyCode key;
  field document_type: DocumentType key;
  field valid_from: date key;
  field active: bool required default(true);
  field requires_approval: bool required default(false);
}

Then resolve it explicitly:

private function resolve_posting_policy(
  company_code_param: CompanyCode,
  document_type_param: DocumentType,
  posting_date_param: date
): PostingPolicy {
  select var policy: PostingPolicy
    where PostingPolicy.company_code = company_code_param
      and PostingPolicy.document_type = document_type_param
      and PostingPolicy.active = true
      and PostingPolicy.valid_from <= posting_date_param;

  if (policy is null) {
    raise message posting_policy_required(company_code_param, document_type_param);
  }

  return policy;
}

See Configuration tables and Configuration resolver patterns for the full ERP policy pattern.

Closed-failure rule#

Grammar-level configuration can describe build and package behavior. Required business configuration must still fail closed when it is missing or ambiguous. Do not invent defaults in config blocks to bypass a missing policy row.