Building Definition Language

131. BDL Validation

BDL Validation shall determine whether a document, Module, Package, Profile, or complete building configuration satisfies the requirements applicable to its declared purpose and lifecycle stage.

Validation shall occur in ordered layers:

package integrity;

lexical validation;

syntax validation;

namespace and import resolution;

identity validation;

Schema and Type validation;

unit validation;

semantic validation;

engineering-rule validation;

compatibility validation;

topology and dependency validation;

configuration validation;

evidence validation;

signature and authorization validation;

target-readiness validation.

A validation request shall define its target:

validation_request House_001_Manufacturing_Release {

configuration: @House_001_AsDesigned_Rev08;

target: manufacturing_release;

];

}

Target stages may include:

conceptual review;

engineering coordination;

regulatory submission;

procurement;

manufacturing release;

construction release;

robotic assembly;

commissioning;

BIOS activation;

operational modification;

Every validation result shall include:

validation run ID;

input configuration;

exact Module and Profile versions;

validator identity and version;

target;

passed checks;

warnings;

failures;

indeterminate checks;

unresolved information;

timestamp;

Syntax Validation shall determine whether BDL text follows the formal grammar of its declared language version.

Syntax checks shall include:

valid tokens;

balanced delimiters;

valid declaration structure;

valid property assignment;

valid block structure;

valid literal notation;

valid Reference notation;

valid expression structure;

valid comment form;

valid statement termination;

permitted keyword use.

Example invalid syntax:

structural_member Beam_B01 : TimberBeam {

length 3600 mm;

}

The missing assignment symbol shall produce a structured error:

Syntax errors shall identify:

error code;

source file;

line and column;

offending token;

expected token or structure;

recovery position;

severity.

A parser may continue after a recoverable error to report additional issues, but content interpreted after recovery shall not be treated as authoritative.

Syntax Validation shall not evaluate:

engineering meaning;

Type compatibility;

unit correctness;

Interface compatibility;

Profile compliance.

Formatting differences, whitespace, indentation, and comments shall not change syntax meaning where the grammar permits them.

Semantic checks shall include:

namespace resolution;

Module resolution;

persistent identity uniqueness;

Type existence;

inheritance validity;

property applicability;

cardinality;

Reference resolution;

relationship applicability;

unit dimension;

coordinate-system consistency;

state applicability;

lifecycle consistency;

expression Type and unit;

required-property completeness.

Example:

component Beam_B01 : StructuralMember {

length: 35 kN;

}

This shall fail because length requires a length quantity.

Example:

connect @Electrical_Interface_01

to @Wastewater_Interface_01;

This may be syntactically valid but semantically invalid because the Interface domains are incompatible.

Semantic errors shall distinguish:

undefined;

ambiguous;

incompatible;

prohibited;

incomplete;

circular;

dimensionally invalid;

Unknown and TBD values may remain semantically valid when their Types are known, but they may prevent later target validation.

Engineering Rule Validation shall evaluate BDL configurations against constitutional rules, Engineering Profiles, Regional Profiles, project requirements, manufacturer limitations, and approved constraints.

Every rule shall define:

Rule ID;

source authority;

version;

scope;

inputs;

evaluation logic;

severity;

applicable lifecycle stage;

exception authority;

required evidence;

failure message.

Example:

engineering_rule Rule_Structural_Capacity_001 {

applies_to: StructuralEntity;

require:

subject.capacity >= subject.demand;

severity: critical;

required_before: construction_release;

}

Engineering checks may include:

capacity versus demand;

serviceability;

material compatibility;

geometric tolerances;

clearances;

thermal performance;

utility capacity;

voltage and pressure compatibility;

maintenance access;

fire continuity;

robotic approach;

evidence completeness.

Rule results shall include:

passed;

failed;

warning;

indeterminate;

deferred;

not applicable;

Rules requiring professional judgment, physical testing, or external approval shall produce a verification requirement rather than a false automated conclusion.

Conflicting rules shall identify their authorities and precedence. The validator shall not resolve an unresolved regulatory or safety conflict arbitrarily.

135. Compatibility Validation

Compatibility Validation shall determine whether Components, Cartridges, Interfaces, software services, and Profiles can participate together in a specific configuration.

Checks shall cover:

Interface Type;

Compatibility Class;

version;

geometry;

datum and orientation;

tolerances;

structural actions;

capacity;

material interaction;

mechanical locking;

electrical characteristics;

fluid characteristics;

thermal conditions;

communication protocol;

control authority;

security;

environmental exposure;

lifecycle state;

certification.

Example:

compatibility_validation Beam_Node_Check_001 {

side_a: @EC01_Node_Interface;

side_b: @N01_X_Positive;

configuration: @House_001_AsInstalled_Rev01;

}

The result shall identify each evaluated dimension:

compatibility_result Beam_Node_Result_001 {

geometry: compatible;

version: compatible;

structural_capacity: compatible;

material: compatible;

environment: compatible;

locking_protocol: compatible;

overall: compatible;

}

A result may be:

directly compatible;

compatible at reduced capability;

compatible through certified Adapter;

conditionally compatible;

incompatible;

Configuration Validation shall evaluate the building configuration as a coordinated whole rather than as isolated valid Entities.

Checks shall include:

Building Manifest completeness;

Module-version compatibility;

duplicate identities;

required Entity presence;

spatial consistency;

geometric collision;

Interface occupancy;

connection completeness;

topology continuity;

dependency availability;

capability sufficiency;

resource allocation;

Engineering Profile application;

safety-system availability;

temporary-work status;

evidence and approval;

configuration-state consistency.

Example checks include:

require every StructuralMember

has valid_load_path_to @Foundation_System;

require every operational Cartridge

has all mandatory_dependencies available;

prohibit one PhysicalInterface

connected_to more_than_one exclusive_counterpart;

Configuration Validation shall identify effects at:

Component level;

Assembly level;

system level;

Zone level;

complete building level.

Validation shall support partial configurations such as one manufacturing package or one construction phase, but the declared boundary and external assumptions shall be explicit.

A valid temporary construction configuration may differ from the final design configuration while still satisfying its stage-specific safety rules.

BDL Conformance Testing shall determine whether a parser, validator, authoring tool, Compiler, serializer, API, or conversion tool implements the BDL specification correctly.

Conformance tests shall include:

valid syntax acceptance;

invalid syntax rejection;

namespace resolution;

Type checking;

unit checking;

identity handling;

canonicalization;

serialization equivalence;

signature preservation;

Profile application;

constraint evaluation;

extension handling;

error reporting;

round-trip preservation;

version compatibility.

Test categories shall include:

positive tests;

negative tests;

boundary tests;

malformed-input tests;

security tests;

large-configuration tests;

interoperability tests;

migration tests.

A conformance test case shall define:

Test ID;

applicable specification version;

input;

required result;

permitted variation;

expected diagnostics;

reference canonical output.

Example:

conformance_test CT_UNIT_001 {

input: "length: 3.6 m;";

expected_canonical_value: 3600 mm;

expected_result: valid;

}

A tool shall not claim complete BDL conformance if it supports only a proprietary subset without declaring that limitation.

Reference Documents shall include:

minimum valid building;

spatial model;

structural model;

Universal Node model;

Cartridge and Interface model;

utility network;

Building BIOS configuration;

Digital Twin initialization;

robotic installation definition;

lifecycle configuration sequence;

Regional Profile;

legacy conversion;

invalid examples with expected errors.

Each Reference Document shall identify:

Reference ID;

BDL version;

Schema versions;

Profile versions;

purpose;

expected validation stage;

expected result;

known simplifications;

A complete reference project should demonstrate:

Reference documents shall include their exact Canonical Representations so independent implementations can compare outputs.

The BDL Reference Implementation shall provide an open, inspectable implementation of essential language functions.

It should include:

tokenizer;

parser;

Abstract Semantic Model;

Schema validator;

unit engine;

namespace resolver;

canonicalizer;

serializer;

configuration differ;

basic engineering-rule engine;

command-line validation tool;

conformance test runner.

The Reference Implementation shall prioritize correctness, transparency, and interoperability over proprietary optimization.

It shall not become the sole normative definition of BDL. Where behavior conflicts with the published specification, the specification and approved interpretation shall govern.

Every release shall identify:

supported BDL versions;

supported Schema versions;

supported serialization formats;

known limitations;

conformance status;

security status;

Vendor implementations may use different programming languages, databases, and internal architectures provided their observable behavior conforms.

Safety- or certification-critical deployment may require additional hardened implementations beyond the general reference software.

140. BDL Certification

BDL Certification shall provide formal assurance that a defined tool, Package, Library, Profile, or workflow conforms to specified BDL requirements.

Certification may apply to:

parser;

validator;

Engineering Compiler;

authoring tool;

serializer;

API implementation;

BDL Package;

Component Library;

Profile Library;

conversion tool;

organizational authoring process.

A certification record shall define:

certified subject;

product and version;

BDL versions;

Schema versions;

supported features;

test suite;

limitations;

certification authority;

issue date;

expiration or review date;

surveillance requirements;

status.

Certification levels may distinguish:

syntax conformance;

semantic conformance;

engineering-validation conformance;

full toolchain interoperability;

safety-critical deployment suitability.

A tool certified for BDL parsing shall not be represented as certified for structural engineering validation unless that function was separately evaluated.

Changes to parsing behavior, canonicalization, Type semantics, rule evaluation, signatures, or migration may require recertification.

Language Governance shall control the definition, interpretation, revision, publication, and retirement of BDL Core language features.

Governance shall protect:

semantic stability;

engineering clarity;

safety;

vendor neutrality;

international adaptability;

deterministic interpretation;

backward compatibility;

open implementation;

long-term accessibility.

Language Governance responsibilities shall include:

grammar;

keywords;

core semantics;

primitive Types;

identity model;

unit model;

configuration model;

canonicalization;

extension rules;

error taxonomy;

version policy.

A proposed language change shall include:

problem statement;

use cases;

proposed syntax;

proposed semantics;

alternatives;

compatibility impact;

migration impact;

security and safety impact;

reference implementation;

tests;

Emergency corrections may be issued for severe ambiguity, corruption risk, or security defects, followed by full governance review.

A Schema proposal shall define:

namespace;

owner;

version;

compatible BDL Core versions;

Entity Types;

Properties;

Relationships;

constraints;

extension points;

migration rules;

Regional Schemas shall identify their jurisdiction, authority, effective dates, and relationship to universal Schemas.

Every approved Schema shall be registered with:

persistent Schema ID;

publisher;

version;

status;

integrity value;

dependencies;

Governed registries may include:

namespace registry;

Schema Registry;

Type Registry;

Component Registry;

Cartridge Registry;

Interface Registry;

Profile Registry;

Material Registry;

certification registry;

extension registry;

conformance-tool registry.

Each registered item shall include:

persistent ID;

owner or publisher;

version;

status;

scope;

authoritative resource;

integrity value;

compatibility information;

deprecation status;

dispute or correction history.

Registry Governance shall prevent:

duplicate identity assignment;

unauthorized identity takeover;

reuse of retired Instance IDs;

silent replacement of registered content;

false certification status;

A Registry service may be distributed or mirrored, but authoritative ownership and update rules shall remain explicit.

Essential building operation shall not depend upon continuous access to a remote Registry. Required records shall be cached or stored locally by Building BIOS.

144. Versioning

BDL shall apply controlled versioning to:

Core language;

grammar;

Schemas;

Modules;

Packages;

Libraries;

Profiles;

extensions;

configurations;

serialization formats;

APIs;

conformance tests.

Version changes shall be classified as:

Major: introduces breaking syntax or semantic change;

Minor: adds backward-compatible capability;

Patch: corrects defects or clarifies behavior without intended compatibility break;

Status: identifies draft, experimental, approved, deprecated, or withdrawn state.

A version record shall include:

Version ID;

parent version;

release date;

change summary;

affected features;

compatibility statement;

migration requirement;

updated tests;

approving authority.

A BDL document shall declare the Core version it requires:

bdl_version: "1.0";

Imports shall pin exact versions or declared compatible ranges:

import s05.structural.nodes version "^1.2";

Authoritative configurations shall record the exact resolved versions, even when the source import permitted a range.

Backward Compatibility exists when a newer BDL implementation can correctly interpret and process content created under an approved older version.

A newer implementation claiming backward compatibility shall:

recognize the older grammar;

preserve older semantics;

resolve older Schemas;

preserve identities;

preserve units;

preserve configuration states;

preserve evidence and signatures;

identify deprecated constructs;

avoid silently upgrading meaning.

Backward compatibility may be:

full;

limited to specific features;

available through migration;

read-only;

If an older feature has become unsafe or irreparably ambiguous, the tool shall reject its use for new critical outputs and provide migration guidance.

Backward compatibility of syntax shall not imply that an old engineering Profile remains legally or technically acceptable for a new project.

Forward Compatibility allows an older BDL implementation or configuration to interact safely with later optional features without misinterpreting them.

Forward-compatible design shall use:

namespaces;

extension fields;

explicit feature criticality;

version negotiation;

optional capabilities;

reserved identifiers;

safe rejection behavior.

Extensions shall identify whether they are:

informational;

optional operational;

required operational;

No tool shall ignore an unknown field if doing so could change:

geometry;

capacity;

Interface behavior;

control authority;

safety state;

certification;

A BDL Package may declare its minimum required feature set:

];

Migration transforms BDL content from one language, Schema, Module, Profile, or configuration version to another.

Every migration shall define:

source version;

target version;

mapping rules;

transformed constructs;

removed constructs;

added defaults;

unresolved items;

semantic differences;

required human review;

validation requirements;

provenance.

Example:

migration BDL_Core_1_to_2 {

from: @BDL_Core_1;

to: @BDL_Core_2;

mappings: @Core_1_to_2_Mapping;

];

}

Migration shall not overwrite the original Package.

The migrated result shall receive:

new version identity;

migration provenance;

source reference;

migration tool identity;

migration report;

Where no exact mapping exists, the result shall contain an explicit unresolved item rather than an invented replacement.

Every extension shall register:

namespace;

owner;

version;

purpose;

Core compatibility;

new Types;

new Properties;

new Relationships;

validation rules;

criticality;

migration policy;

conformance tests.

Extension status may be:

private project extension;

manufacturer extension;

regional extension;

research extension;

public candidate;

approved domain extension;

deprecated;

withdrawn.

An extension shall not:

redefine Core semantics;

weaken constitutional rules;

obscure mandatory interoperability data;

use another organization’s namespace;

create contradictory unit definitions;

bypass Profile validation.

Manufacturer extensions shall expose sufficient information for safe use even where internal implementation remains proprietary.

Extensions used in signed configurations shall be version-pinned and preserved.

A widely adopted extension may be proposed for standardization, but transition into the Core shall require formal governance and compatibility analysis.

Experimental features shall be isolated through:

experimental namespace;

explicit feature flag;

separate Schema;

declared tool support;

limited deployment scope;

clear validation status.

Example:

experimental_feature GenerativeAssemblyConstraint {

namespace: "s05.experimental.generative";

version: "0.2";

status: research_only;

permitted_targets: [simulation, prototype];

}

Experimental content shall not be used for production, certification, BIOS activation, or safety-critical decisions unless explicitly authorized by an Experimental Profile.

Every experimental feature shall define:

research objective;

responsible organization;

known limitations;

unsupported behavior;

test coverage;

data-retention requirements;

Promotion to approved status shall require:

stabilized semantics;

reference implementation;

conformance tests;

security and safety review;

interoperability demonstration;

migration strategy;

Evolution may be driven by:

new engineering domains;

improved Interface architecture;

new Cartridge classes;

robotic construction;

AI-assisted engineering;

cybersecurity;

lifecycle experience;

incident findings;

regional adoption;

implementation feedback.

The preferred evolution sequence shall be:

clarify existing semantics;

add compatible optional capability;

create a governed extension;

validate through reference implementation;

promote to approved domain Schema;

add to Core only where universal need is established;

provide migration tools;

deprecate obsolete constructs;

withdraw unsafe constructs when necessary.

Feature status may include:

proposed;

experimental;

draft;

approved;

active;

mature;

maintenance-only;

deprecated;

unsupported;

withdrawn.

A deprecation notice shall identify:

affected feature;

reason;

replacement;

migration method;

warning start;

support period;

removal or withdrawal version;

The final Building Definition Language Model shall provide a unified engineering language through which the complete System05 building can be defined, validated, compiled, constructed, operated, maintained, and evolved.

The model consists of:

persistent identities;

typed Entities;

unit-aware Properties;

explicit Relationships;

coordinate systems and geometry;

spatial and physical models;

Nodes, Cartridges, Interfaces, and Connections;

functional and engineering requirements;

capabilities and dependencies;

Engineering and Regional Profiles;

lifecycle configurations;

evidence and provenance;

versioning and integrity;

human- and machine-readable representations.

The complete BDL workflow shall be:

Define the Building Manifest Establish Building ID, Site, language version, Modules, Profiles, and configuration scope.

Describe Spatial Organization Define coordinates, placement, grids, Levels, Zones, Spaces, and boundaries.

Define Physical Entities Represent Components, Assemblies, materials, members, Nodes, Cartridges, Interfaces, systems, and temporary works.

Declare Requirements Define functions, engineering constraints, loads, performance, safety, manufacturing, lifecycle, and robot-readiness requirements.

Create Relationships Establish containment, placement, support, connection, utility flow, control, monitoring, and dependencies.

Apply Profiles Apply universal, domain, regional, project, manufacturing, and robotic requirements.

Represent Configuration Stages Maintain As-Designed, As-Manufactured, As-Installed, As-Commissioned, As-Operated, As-Maintained, and As-Modified configurations.

Attach Evidence Link engineering claims to calculations, tests, inspections, certificates, measurements, and approvals.

Validate Evaluate syntax, semantics, engineering rules, compatibility, topology, dependencies, and configuration completeness.

Compile Transform valid BDL into purpose-specific engineering and machine outputs.

Deploy to Building BIOS Load the signed configuration, discover physical Instances, reconcile the building, commission systems, and activate authorized operation.

Feed the Digital Twin Use BIOS-verified configuration and runtime data to create and continuously update the Digital Twin.

Support AI and Robotics Provide structured, traceable, and bounded information for intelligent design, analysis, assembly, inspection, and operation.

Preserve Lifecycle Continuity Record changes, replacements, maintenance, migration, reuse, and decommissioning without losing identity or history.

BDL shall not be merely a digital drawing format. It shall be the formal engineering language through which System05 expresses what a building is, what it contains, how its parts interact, what conditions they must satisfy, and how those statements are verified throughout the building lifecycle.