Building BIOS Architecture

105. BIOS Provisioning

BIOS Provisioning establishes the initial trusted identity, ownership context, configuration authority, and deployment package required for a Building BIOS instance.

Provisioning shall occur before the BIOS receives operational control authority.

The provisioning package shall include:

Building ID or authorized process for creating it;

BIOS hardware identity;

BIOS software and Core version;

Root-of-Trust configuration;

initial trust authorities;

owner or project authority;

initial administrator identities;

approved Building Manifest;

applicable Engineering Profiles;

initial configuration schema;

recovery authorities;

backup policy;

commissioning requirements.

Provisioning shall distinguish among:

BIOS platform provisioning;

building-specific provisioning;

user and service provisioning;

Component and Cartridge pre-enrollment;

certificate and credential provisioning;

recovery provisioning.

The process shall verify that the BIOS platform has not been altered between manufacture, delivery, and site activation.

Factory default credentials shall not remain active after building-specific provisioning.

Provisioning records shall identify:

who performed the action;

where it occurred;

hardware and software involved;

credentials created;

ownership authority;

configuration package;

verification results;

unresolved restrictions.

A BIOS may be pre-provisioned for a specific project or provisioned onsite. In either case, final activation shall verify that the hardware, Building ID, site, configuration, and responsible authority correspond.

Recovery credentials shall be created and protected during provisioning rather than improvised after a failure.

106. Factory Configuration

Factory Configuration prepares BIOS hardware, prefabricated building assemblies, Cartridges, gateways, and controllers before shipment to the construction site.

Factory Configuration may include:

installation of approved BIOS software;

secure boot configuration;

device and Cartridge identities;

communication settings;

initial Interface Descriptors;

factory topology for prefabricated assemblies;

calibration data;

factory test results;

firmware versions;

temporary commissioning credentials;

project-specific assignments;

shipping and storage state.

Factory Configuration shall not falsely declare site-dependent relationships as verified. Building location, final Interface engagement, field utility connection, and complete topology shall remain uncommissioned until verified onsite.

Every factory-configured item shall be linked to:

Component or Cartridge Instance ID;

manufacturing batch;

factory identity;

configuration version;

software and firmware versions;

test equipment and calibration;

responsible personnel or automated system;

The factory package shall distinguish:

manufacturer-controlled configuration;

project-controlled configuration;

site-required configuration;

installer-adjustable settings;

Site Installation places the BIOS hardware, communication infrastructure, local service interfaces, and supporting equipment into their approved building locations.

Before installation, the responsible party shall verify:

BIOS hardware identity;

shipping condition;

tamper status;

approved location;

environmental conditions;

primary and backup power;

grounding;

communication paths;

physical security;

service access;

recovery access;

compatibility with the provisioned building package.

The installation shall define:

enclosure and mounting;

ventilation and temperature control;

moisture and dust protection;

electrical supply and isolation;

battery or backup power;

network connections;

physical access control;

labeling;

emergency identification;

replacement clearance.

The BIOS shall not be located where a single foreseeable water leak, fire event, impact, environmental condition, or unauthorized access can unnecessarily disable both primary operation and recovery.

Redundant BIOS nodes shall avoid common physical failure conditions where required.

Site Installation shall record:

actual location;

installed hardware;

connected power and networks;

physical-protection measures;

installation date;

installer identity;

deviations;

inspection results;

Initial Commissioning verifies that the installed BIOS platform, building configuration, connected assets, trust system, and essential services operate correctly together.

Commissioning shall include:

hardware identity verification;

secure boot verification;

power and backup-power testing;

persistent storage testing;

local service-access testing;

communication-network testing;

clock and synchronization verification;

trust and credential verification;

Building Manifest import;

Registry initialization;

Component and Cartridge discovery;

Interface verification;

topology construction;

configuration validation;

service dependency testing;

state and event testing;

alarm and notification testing;

backup and restore testing;

Safe Boot testing;

The commissioning record shall identify:

tests performed;

expected and actual results;

test equipment;

configuration version;

responsible parties;

defects and corrective actions;

accepted restrictions;

unresolved conditions;

approval status.

Initial commissioning results may be:

accepted;

accepted with restrictions;

conditionally accepted;

rejected;

limited to construction or maintenance operation.

The first As-Commissioned Configuration Baseline shall be created only after the required commissioning criteria are satisfied.

109. Operational Management

Operational Management maintains the BIOS in a known, secure, healthy, and supportable condition throughout building use.

Operational activities shall include:

BIOS health monitoring;

service availability monitoring;

storage and backup verification;

configuration-drift monitoring;

credential-status monitoring;

software-support monitoring;

Registry maintenance;

event and fault review;

capacity monitoring;

integration-status monitoring;

recovery-readiness verification.

The BIOS shall provide authorized operators with:

current operating mode;

BIOS integrity status;

active configuration version;

unavailable services;

degraded Components and Cartridges;

active alarms and faults;

pending maintenance;

backup condition;

update status;

certification and support status.

Routine operational management shall not require unrestricted access to safety-critical or engineering configuration.

Temporary overrides, maintenance permissions, and remote-service sessions shall expire automatically according to their approved duration.

Operational procedures shall define response to:

repeated restart;

storage degradation;

expired credentials;

unavailable cloud services;

lost Component communication;

configuration drift;

unsupported software;

certificate revocation;

failed backup;

The BIOS shall undergo periodic and condition-triggered inspection to confirm that its physical installation, hardware, software, configuration, security, and recovery functions remain suitable for service.

Inspection shall include, as applicable:

enclosure and mounting;

environmental condition;

physical tamper evidence;

power and backup power;

grounding;

communication connections;

storage health;

clock accuracy;

secure boot status;

software integrity;

credential validity;

active services;

configuration integrity;

backup validity;

recovery-interface accessibility;

event and audit logging;

integration health.

Diagnostic testing may include:

processor and memory tests;

storage-integrity tests;

redundant-node failover;

network-path tests;

service restart;

configuration validation;

authentication tests;

alarm-delivery tests;

Safe Boot;

backup restoration in an isolated environment.

Inspection frequency shall reflect:

building criticality;

BIOS architecture;

hardware environment;

previous faults;

software support;

regulatory requirements;

The inspection result shall classify the BIOS as:

acceptable;

acceptable with advisory;

maintenance required;

degraded;

restricted;

immediate recovery required;

BIOS Maintenance preserves or restores hardware, software, communication, storage, security, and recovery capability without altering the approved building function unnecessarily.

Maintenance may include:

cleaning;

environmental-control service;

backup-battery replacement;

storage replacement;

communication-module replacement;

clock-battery replacement;

credential rotation;

log archival;

backup verification;

service repair;

driver repair;

approved security patching;

recovery-media renewal.

Before maintenance, the BIOS shall identify:

affected services;

dependent systems;

required operating mode;

redundancy availability;

configuration checkpoint;

recovery plan;

maintenance authority.

Maintenance shall follow a controlled work order containing:

task;

target;

approved parts or software;

isolation requirements;

expected duration;

verification procedure;

rollback procedure;

responsible person.

Substitute hardware shall meet the required environmental, security, reliability, communication, and performance characteristics.

Maintenance affecting trust, persistent storage, Core services, network segmentation, or command authority shall require enhanced verification.

After maintenance, the BIOS shall perform:

integrity checking;

service health verification;

configuration validation;

communication verification;

affected integration testing;

backup verification;

event recording.

Maintenance shall not silently reset configuration, delete logs, re-enable revoked access, or restore insecure defaults.

112. Configuration Update

A Configuration Update changes the approved representation or operating rules of the building without necessarily changing BIOS software.

Configuration Updates may include:

adding or removing a Component;

replacing a Cartridge;

changing an Interface connection;

modifying a spatial assignment;

changing a dependency;

changing an Engineering Profile;

updating a capacity or operating limit;

changing control authority;

changing an operating mode;

accepting an As-Built condition.

Every Configuration Update shall include:

proposed change;

affected configuration objects;

engineering rationale;

compatibility assessment;

dependency impact;

safety and security impact;

required evidence;

implementation sequence;

validation procedure;

commissioning requirements;

recovery plan;

The BIOS shall:

preserve the current baseline;

validate the proposed package;

verify authority and signatures;

identify affected entities;

establish required operating state;

apply the proposed configuration in a controlled context;

verify physical implementation;

validate the resulting configuration;

recommission affected functions;

activate the new baseline;

record the complete change.

If activation fails, the BIOS shall return to a safe condition. Rollback shall occur only where the preceding physical configuration remains valid.

113. Firmware and Software Update

Firmware and Software Update modifies executable code operating within the BIOS platform, connected controllers, or registered Cartridges.

Updates shall be classified as:

security;

defect correction;

compatibility;

performance;

functional;

safety-related;

major platform migration.

The update package shall identify:

publisher;

target;

current and proposed versions;

digital signature;

integrity value;

dependencies;

compatibility;

configuration effect;

known risks;

installation requirements;

restart requirements;

rollback or recovery;

Updates shall not proceed when:

emergency operation is active;

required backup is invalid;

recovery capacity is unavailable;

insufficient power exists;

affected redundancy is already lost;

configuration is inconsistent;

required authorization is absent.

Where practical, new software shall be installed into an inactive partition or isolated environment and verified before activation.

Following activation, the BIOS shall confirm:

secure boot;

software integrity;

service availability;

Registry access;

configuration compatibility;

communication;

safety-related functions;

event recording;

Hardware Migration transfers BIOS authority from an existing computing platform to replacement or upgraded hardware while preserving Building ID, configuration, trust, and lifecycle continuity.

Migration may be required because of:

hardware failure;

capacity expansion;

technology obsolescence;

cybersecurity improvement;

manufacturer withdrawal;

environmental damage;

planned modernization.

The migration process shall include:

register and verify the new hardware;

establish a trusted migration relationship;

confirm software and schema compatibility;

create a current verified backup;

transfer configuration and authorized records;

transfer or replace credentials;

validate restored data;

synchronize state and event records;

test network and integration services;

transfer authoritative role;

isolate the old platform;

monitor the new platform;

Private credentials that cannot be securely transferred shall be replaced through an authorized trust-transition process.

Parallel operation during migration shall define which platform is authoritative. Both platforms shall not issue conflicting configuration or command authority.

Migration shall include Safe Boot, backup restore, and failover testing where required.

The old hardware shall be sanitized, archived, retained as an approved recovery device, or decommissioned according to its classification.

115. Building Expansion and Reconfiguration

The BIOS shall support physical expansion, renovation, subsystem replacement, change of use, and building-zone reconfiguration.

Expansion may introduce:

new spatial zones;

structural components;

Nodes;

Interfaces;

Cartridges;

utility capacity;

networks;

BIOS nodes;

Engineering Profiles;

new dependencies;

new safety systems.

The process shall begin with a proposed BDL or configuration model identifying:

existing configuration;

proposed additions or removals;

temporary construction states;

affected Interfaces;

resource requirements;

dependency changes;

capacity effects;

safety and regulatory impacts;

Temporary construction configurations shall be represented explicitly. The BIOS shall not assume that the building moves directly from the old complete state to the new complete state.

Phased work shall define:

intermediate baselines;

temporary supports;

utility bypasses;

isolated areas;

reduced capabilities;

temporary alarms;

permitted occupancy;

After expansion, the BIOS shall reconstruct topology, update registries, validate dependencies, recommission affected systems, and create a new As-Modified Baseline.

116. Disaster Recovery

Disaster Recovery restores essential BIOS authority and building configuration following severe physical, digital, environmental, or organizational disruption.

Disaster scenarios may include:

fire;

flood;

structural damage;

total power loss;

BIOS hardware destruction;

storage loss;

cyberattack;

credential compromise;

communication failure;

loss of vendor services;

unauthorized configuration change.

The Disaster Recovery Plan shall define:

critical BIOS functions;

recovery priorities;

backup locations;

replacement hardware;

trusted recovery software;

recovery authorities;

emergency credentials;

offline documentation;

maximum acceptable data loss;

maximum acceptable recovery time;

temporary operating modes.

Recovery shall proceed through:

establish physical safety;

determine BIOS and infrastructure condition;

isolate compromised systems;

establish trusted recovery hardware;

verify recovery authority;

retrieve and validate backups;

assess physical changes since the backup;

restore essential configuration;

rediscover Components and Interfaces;

reconcile the physical building;

validate dependencies;

recommission critical systems;

restore additional services by priority;

BIOS Decommissioning permanently removes a BIOS implementation, BIOS node, or complete building BIOS from authorized service.

Decommissioning may occur because of:

hardware replacement;

building demolition;

building conversion;

migration to another compliant implementation;

irreparable compromise;

end of support;

permanent shutdown.

The decommissioning process shall include:

confirm scope and authority;

preserve the final Configuration Baseline;

export required Registries and lifecycle records;

archive evidence and audit logs;

transfer authority where applicable;

revoke credentials;

remove remote access;

disable update and support services;

sanitize protected data;

remove or classify hardware;

update the Building Manifest;

record final state.

If the building remains in operation under a replacement BIOS, authority shall transfer before the old BIOS is disabled.

If the complete building is decommissioned, the BIOS shall create an As-Decommissioned model showing:

Components removed;

Cartridges transferred;

materials recovered;

hazardous systems;

remaining physical assets;

final utility isolation;

Every significant BIOS claim, decision, configuration, state transition, and lifecycle action shall be linked to appropriate evidence.

Evidence may include:

design records;

signed configuration;

manufacturer documentation;

certificates;

test results;

commissioning records;

physical inspection;

sensor measurement;

diagnostic output;

software-integrity records;

authentication records;

human approval;

robotic installation records;

photographs or scans;

AI-supported analysis.

Each evidence item shall identify:

Evidence ID;

subject;

claim supported;

evidence type;

source;

author or producing system;

date;

configuration and software version;

method;

result;

uncertainty;

limitations;

integrity information;

retention requirement.

The BIOS shall distinguish among:

declared evidence;

calculated evidence;

simulated evidence;

tested evidence;

inspected evidence;

monitored evidence;

inferred evidence;

independently certified evidence.

Traceability shall connect:

constitutional requirement;

technical specification;

Engineering Profile;

BDL element;

compiled configuration;

physical Instance;

Interface connection;

commissioning test;

operational event;

maintenance action;

Conformance Testing determines whether a Building BIOS implementation satisfies its declared System05 BIOS specification, deployment Profile, security class, and operational requirements.

Testing shall include, as applicable:

architecture review;

secure boot testing;

identity and authentication testing;

authorization testing;

Registry testing;

Interface and Cartridge integration;

configuration validation;

state-transition testing;

event integrity;

fault management;

API conformance;

network segmentation;

offline operation;

backup and restore;

failover;

Safe Boot;

update and rollback;

hardware migration;

emergency operation;

performance and capacity;

cybersecurity;

Reference test configurations shall include products or simulated entities from multiple manufacturers where interoperability is claimed.

Conformance testing shall verify that the BIOS:

rejects invalid identity;

rejects unauthorized commands;

detects incompatible configuration;

preserves transactional integrity;

distinguishes requested and verified physical state;

continues required local functions offline;

restores a valid configuration;

records failures without silent deletion.

Test plans shall define:

test environment;

BIOS version;

configuration;

input conditions;

expected result;

acceptance criteria;

tools;

uncertainty;

responsible laboratory;

BIOS Certification is the formal determination that a defined BIOS implementation or deployment satisfies specified System05 requirements.

Certification may apply to:

BIOS Core software;

physical BIOS hardware;

complete hardware-software platform;

deployment architecture;

security implementation;

communication gateway;

recovery process;

installation organization;

complete building-specific BIOS deployment.

The certification record shall identify:

certified product or deployment;

hardware;

software and firmware versions;

Configuration Schema versions;

supported Interface and Cartridge classes;

deployment limits;

building-scale limits;

security and availability classification;

tests and evidence;

excluded functions;

issuing authority;

validity period;

surveillance requirements.

Certification levels shall reflect the consequence of BIOS failure and the authority assigned to the implementation.

A BIOS used only for identity and documentation may require a different certification level from a BIOS coordinating safety-related commands or high-criticality buildings.

Changes affecting trusted boot, authorization, configuration processing, state logic, safety behavior, update architecture, or recovery may require recertification.

Certification shall not replace:

project-specific engineering;

regulatory approval;

commissioning;

physical safety certification;

licensed professional responsibility.

Suspended, expired, or withdrawn certification shall remain visible in the Registry and shall trigger defined operational review.

121. BIOS Governance

BIOS Governance controls the development, approval, publication, implementation, revision, and retirement of Building BIOS specifications.

Governance shall preserve:

safety;

vendor neutrality;

interoperability;

transparency;

cybersecurity;

recoverability;

human accountability;

regional adaptability;

long-term data access.

Governance responsibilities shall include:

BIOS constitutional consistency;

Core architecture;

data schemas;

API standards;

identity and trust;

security requirements;

configuration semantics;

state and event models;

certification requirements;

reference implementations;

deprecation policy.

A BIOS proposal or major revision shall proceed through:

problem definition;

use-case analysis;

threat and hazard analysis;

architectural proposal;

compatibility review;

prototype;

test implementation;

security review;

interoperability testing;

public or authorized technical review;

controlled pilot;

approval;

publication;

Security-sensitive details may receive restricted distribution, but their governance, authority, and audit status shall remain traceable.

Emergency security or safety revisions may use accelerated approval while preserving documentation, scope, transition requirements, and later review.

122. Versioning and Compatibility

Every BIOS architecture, implementation, schema, API, policy package, driver, Interface Descriptor, and configuration package shall be versioned.

Version changes shall be classified as:

Major: introduces breaking compatibility or changes authoritative behavior;

Minor: adds compatible functions;

Patch: corrects defects without intentionally changing external behavior;

Security Revision: addresses a security risk and may impose accelerated migration;

Profile Revision: changes deployment-specific requirements.

The BIOS shall declare:

supported configuration-schema versions;

supported BDL and Compiler outputs;

supported Interface Descriptor versions;

supported Cartridge Passport versions;

supported API versions;

supported driver versions;

supported security protocols.

Backward compatibility shall permit a newer BIOS to operate approved older configurations within declared limits.

Forward compatibility shall allow older deployments to reject or safely ignore unknown optional capabilities without misinterpreting them.

Unknown critical fields, states, commands, or safety requirements shall cause rejection rather than silent omission.

Compatibility shall be verified before:

BIOS update;

hardware migration;

Configuration Update;

new Cartridge enrollment;

new integration service;

Evolution may be driven by:

new Interface and Cartridge generations;

security threats;

improved safety;

new regulations;

AI and robotic capabilities;

new building types;

operating experience;

incident findings;

technology obsolescence.

The preferred evolution strategy shall be:

add optional compatible capability;

add a new Profile;

extend a schema safely;

introduce a compatible Minor version;

provide a migration tool;

introduce a Major version when necessary;

maintain transition support;

deprecate obsolete or unsafe versions;

withdraw versions only when continued use is unacceptable.

BIOS lifecycle status may include:

experimental;

draft;

approved;

active;

mature;

maintenance-only;

deprecated;

unsupported;

withdrawn.

A deprecation notice shall identify:

affected versions;

reason;

risk;

effective date;

continued-use conditions;

available updates;

hardware requirements;

migration procedure;

backup requirements;

certification effect;

Where hardware cannot support a required secure update, an approved migration path shall be provided when practical.

Critical security or safety risks may require restricted operation, network isolation, increased monitoring, accelerated migration, or withdrawal.

124. Final Building BIOS Model

The final System05 Building BIOS Model consists of a trusted local coordination layer positioned between the physical building and higher-level digital systems.

Its authoritative core contains:

persistent Building Identity;

Root of Trust;

Building Manifest;

Component Registry;

Cartridge Registry;

Interface Registry;

Spatial Registry;

Capability Registry;

Building Topology Graph;

Interface Connection Map;

Dependency Map;

Engineering Profile Configuration;

Configuration Baselines;

State and Event Engines;

Policy and Rules Engine;

Service Manager;

backup and recovery system.

The complete BIOS lifecycle follows this sequence:

Construct Topology Establish physical, structural, utility, communication, control, spatial, and dependency relationships.

Validate Configuration Determine whether the complete configuration is consistent, compliant, and safe for the intended mode.

Protect Enforce trust, authorization, segmentation, fail-safe behavior, fault containment, and emergency priorities.

Integrate Provide controlled access to Digital Twins, Engineering Compiler, AI, BMS, home automation, robots, edge services, and emergency responders.

Expand and Reconcile incorporate physical modifications while preserving traceability between design, installed condition, and active configuration.

Recover Restore trusted authority after hardware failure, cyberattack, corruption, or disaster.

Migrate or Decommission Transfer building authority to future hardware and software without losing identity, configuration, or lifecycle history.

The Building BIOS shall not be the intelligence that decides every aspect of building operation. It shall be the trusted foundation that tells every authorized system what the building contains, how its parts are related, what state they are in, what actions are permitted, and what evidence supports those conclusions.

The Building BIOS transforms a collection of physical products and disconnected software into a coherent, identifiable, configurable, recoverable, and continuously evolvable engineering platform.