Building Definition Language

The As-Maintained Configuration represents the building after maintenance, repair, calibration, adjustment, or replacement activities.

It shall identify:

work performed;

affected Entities;

removed parts;

installed parts;

updated material or batch identities;

calibration results;

changed settings;

renewed seals, fasteners, or consumables;

post-maintenance testing;

recommissioning;

remaining limitations.

Example:

configuration House_001_AsMaintained_Rev14 {

type: as_maintained;

based_on: @House_001_AsOperated_2027_07_20;

];

];

evidence: @Maintenance_Evidence_Rev14;

}

Maintenance shall not overwrite original manufacturing, installation, or commissioning records.

If maintenance changes capability, geometry, Interface condition, firmware, control logic, or safety behavior, the resulting configuration shall undergo the required validation and recommissioning.

A maintenance action that restores an Entity to its approved condition may create a new As-Maintained configuration without changing its Type.

The As-Modified Configuration represents an approved physical or digital change that alters the building beyond ordinary maintenance.

Modifications may include:

building expansion;

relocation of Components;

new Interfaces;

new Cartridge Types;

capacity increases;

structural alteration;

utility rerouting;

change of use;

new control architecture;

new Engineering Profiles;

legacy-system conversion.

Example:

configuration House_001_AsModified_Rev02 {

type: as_modified;

parent: @House_001_AsCommissioned_Rev01;

change_project: @Bedroom_Addition_Project;

];

];

evidence: @Modification_Approval_Package;

}

The modification shall define intermediate construction configurations where the building cannot transition directly from the old completed state to the new completed state.

Modification approval shall evaluate:

structural load paths;

utilities;

safety systems;

accessibility;

envelope continuity;

BIOS configuration;

Digital Twin;

maintenance and replacement access;

The completed As-Modified Configuration may become the new basis for subsequent As-Commissioned and As-Operated configurations.

101. Configuration Alternatives

BDL shall support multiple design or implementation alternatives without representing them simultaneously as the approved physical configuration.

An Alternative Set shall define:

decision subject;

baseline configuration;

candidate alternatives;

shared requirements;

evaluation criteria;

constraints;

decision status;

selected alternative;

rejected alternatives;

decision authority.

Example:

alternative_set Heating_System_Alternatives {

baseline: @House_001_AsDesigned_Rev05;

];

];

selected: @Alternative_A_HeatPump;

decision: @Heating_System_Decision_001;

}

Each alternative shall remain a complete and internally consistent configuration branch or controlled partial branch.

BDL shall identify whether an alternative is:

under study;

technically valid;

conditionally valid;

selected;

rejected;

archived;

Every optional or conditional declaration shall identify:

Entity or requirement;

condition;

default status;

activation stage;

dependencies;

compatibility impact;

validation behavior;

deactivation behavior.

Example:

optional cartridge Solar_Battery_Cartridge {

type: @Battery_Cartridge_Type_01;

location: @Energy_Cartridge_Bay_02;

reserved_interface: @Battery_Interface_02;

}

conditional requirement Cold_Climate_Freeze_Protection {

when:

@Regional_Profile.design_temperature < 0 °C;

require:

@Exterior_Water_Lines.freeze_protection == verified;

}

Optional shall not mean undocumented. Reserved geometry, Interface capacity, utility capacity, structural support, and future access shall be defined where future installation is intended.

Safety-critical conditional elements shall fail conservatively when the triggering condition cannot be determined.

A Change Set records the exact additions, removals, modifications, and relationship changes between two versions.

Each Change Set shall define:

Change Set ID;

source configuration;

target configuration;

initiating authority;

purpose;

affected Entities;

added declarations;

removed declarations;

modified properties;

modified relationships;

changed Profiles;

impact classification;

evidence;

approval;

implementation status.

Example:

change_set CS_012_Kitchen_Cartridge_Replacement {

from: @House_001_AsOperated_Rev11;

to: @House_001_AsOperated_Rev12;

remove_active_instance:

@Kitchen_Service_Cartridge_Old;

add_active_instance:

@Kitchen_Service_Cartridge_New;

];

classification: functional_replacement;

}

Changes shall be classified as:

editorial;

administrative;

geometric;

functional;

capacity-affecting;

Interface-affecting;

structural;

safety-affecting;

Every change shall identify required revalidation, reanalysis, inspection, testing, commissioning, or certification.

104. Provenance

Provenance records where a BDL declaration originated, who or what created it, how it was transformed, and which authority accepted it.

Every significant declaration shall be capable of carrying:

source identity;

author;

organization;

creation time;

source document;

source version;

generation method;

transformation history;

review status;

approval authority;

superseding record.

Example:

provenance Node_N01_Capacity_Provenance {

subject: @Node_N01_Capacity;

source: @Node_Type_Test_03;

created_by: @Structural_Engineer_01;

created_at: "2027-03-14T16:20:00Z";

reviewed_by: @Independent_Reviewer_01;

status: verified;

}

Generated information shall identify the producing tool:

generated_by {

tool: @Engineering_Compiler;

version: "1.4.2";

input_configuration: @House_001_AsDesigned_Rev08;

}

AI-generated information shall identify:

AI system;

model version;

prompt or task reference where appropriate;

source inputs;

confidence;

human review;

Engineering Evidence supports a claim regarding identity, geometry, material, capacity, performance, condition, compatibility, compliance, or lifecycle event.

Evidence Types may include:

calculation;

simulation;

laboratory test;

field test;

inspection;

survey;

material certificate;

manufacturing record;

commissioning test;

sensor data;

photograph;

video;

robotic installation record;

professional review;

certification.

Each Evidence record shall define:

Evidence ID;

evidence Type;

claim supported;

subject;

configuration;

method;

source;

author or laboratory;

date;

inputs;

equipment;

calibration;

result;

uncertainty;

limitations;

integrity reference;

review status.

Example:

evidence Node_Type_Test_03 : StructuralTestEvidence {

subject: @Universal_Node_Type_SC03;

supports_claim: axial_compression_capacity;

test_configuration: @Node_Test_Specimen_03;

method: @Node_Axial_Test_Procedure;

result: 180 kN;

laboratory: @Independent_Laboratory_01;

status: accepted;

}

Evidence shall remain linked to the exact Type, Instance, configuration, and conditions evaluated.

Evidence from a different geometry, material, environment, or manufacturing process shall require an applicability assessment.

Each Certification Reference shall identify:

Certificate ID;

certified subject;

certification body;

certification scheme;

applicable specification;

configuration and version;

tested capacity or scope;

limitations;

issue date;

expiration or review date;

status;

surveillance requirements;

evidence package;

digital verification method.

Example:

certification_reference Node_SC03_Certification {

certificate_id: "S05-CERT-NODE-SC03-001";

subject: @Universal_Node_Type_SC03;

certification_body: @Certification_Body_01;

applicable_profile: @Structural_Interface_Profile_SC03;

status: valid;

limitations: @Node_SC03_Certification_Limits;

}

Certification status shall include:

proposed;

under review;

valid;

conditionally valid;

suspended;

expired;

withdrawn;

A valid Type certification shall not automatically certify an incorrectly manufactured, damaged, improperly installed, or incompatible Instance.

An Assumption is a declared value or condition temporarily accepted for analysis or design because verified information is unavailable.

Uncertainty represents the quantified or qualified limitation in knowledge, measurement, prediction, or model accuracy.

Every Assumption shall define:

Assumption ID;

subject;

assumed value or condition;

reason;

source;

affected decisions;

sensitivity;

verification deadline;

responsible party;

consequence if incorrect;

current status.

Example:

assumption Soil_Bearing_Assumption_01 {

subject: @Foundation_Design;

assumed_value: 150 kPa;

reason: "Geotechnical investigation pending";

used_by: @Preliminary_Foundation_Analysis;

verification_required_before: construction_release;

consequence_if_lower: foundation_redesign;

}

Uncertainty may be represented as:

value range;

probability distribution;

confidence interval;

measurement uncertainty;

qualitative confidence class;

model limitation.

Example:

measured_position: 1250.4 mm ± 0.8 mm;

manufacturer: unknown;

TBD A value must be determined before a specified lifecycle or approval stage.

foundation_capacity:

TBD(required_before: construction_release);

Not Applicable The property does not apply to the Entity.

firmware_version: not_applicable;

Unavailable The value may exist but cannot presently be accessed.

test_report:

unavailable(reason: "Legacy archive inaccessible");

Withheld The information exists but access is restricted.

internal_geometry:

withheld(classification: manufacturer_confidential);

Unverified A value has been supplied but has not been validated.

member_grade:

unverified("GL24", source: @Supplier_Statement);

Every TBD value shall identify:

responsible party;

deadline or lifecycle gate;

required verification;

affected Entities;

consequence of nonresolution.

A default value shall not replace Unknown or TBD unless the applicable Profile explicitly permits a conservative default and records its use.

109. Compliance Status

Compliance Status records the result of evaluating an Entity, requirement, Interface, system, or configuration against an identified rule, Profile, specification, or certification basis.

Compliance results shall include:

compliant;

compliant with conditions;

partially compliant;

noncompliant;

not evaluated;

indeterminate;

not applicable;

temporarily accepted;

exemption granted.

Each Compliance Record shall define:

Compliance Record ID;

subject;

requirement;

applicable version;

evaluation method;

result;

evidence;

evaluator;

date;

limitations;

corrective action;

expiration or review condition.

Example:

compliance_record CR_Node_N01_Profile {

subject: @Node_N01;

requirement_set: @Structural_Interface_Profile_SC03;

result: compliant;

];

evaluated_by: @Commissioning_Authority;

}

A configuration containing unresolved critical noncompliance shall not be released for the affected lifecycle stage.

BDL shall support digital signatures and integrity verification for documents, Modules, Packages, Profiles, configurations, evidence, and certification references.

A signature record shall identify:

signed object;

object version;

signer;

signer authority;

signature method;

signing time;

integrity digest;

trust chain;

validity status;

revocation status;

signature purpose.

Example:

digital_signature House_001_Design_Approval {

signed_object: @House_001_AsDesigned_Rev08;

signed_by: @Design_Authority_01;

purpose: approved_for_manufacturing;

signed_at: "2027-04-12T18:00:00Z";

digest: sha256("...");

}

Signature purposes may include:

authorship;

review;

engineering approval;

manufacturing release;

commissioning acceptance;

certification;

BIOS activation;

Example:

];

External geometry and evidence resources shall include integrity references so that substitution or modification can be detected.

Historical signatures shall remain preserved after certificates expire or are revoked, with their validity at signing time recorded.

111. Access and Information Classification

BDL shall classify information according to its intended audience, sensitivity, operational consequence, privacy, security, and intellectual-property status.

Information classifications may include:

public;

open engineering;

project internal;

owner confidential;

manufacturer confidential;

personally sensitive;

security sensitive;

safety critical;

emergency access;

regulatory restricted.

Each classification declaration shall define:

protected object;

classification;

authorized roles;

permitted operations;

retention;

export restrictions;

disclosure conditions;

emergency-access rule;

declassification or review condition.

Example:

access_classification BIOS_Network_Credentials {

subject: @BIOS_Credential_Package;

classification: security_sensitive;

];

operations: [read, rotate, revoke];

export: prohibited;

}

BDL shall separate necessary interoperability information from protected proprietary information.

A manufacturer may protect internal Cartridge geometry while exposing:

external Interface geometry;

capabilities;

limitations;

safety behavior;

installation requirements;

evidence required for interoperability.

Emergency information may be made available under a dedicated emergency-access policy without exposing unrelated private or security-sensitive data.

Access restriction shall not be used to conceal information necessary to evaluate safety, compatibility, certification, maintenance, or emergency response.

Tools shall preserve classification labels during import, export, compilation, BIOS deployment, Digital Twin integration, and archival.