Glossary & Reference

101. Computational Architecture

A Computational Architecture is the organized structure through which data, rules, models, software services, devices, networks, identities, permissions, and computational responsibilities interact.

It may include:

embedded controllers;

Building BIOS services;

Digital Twin platforms;

Engineering Compilers;

AI Models and Agents;

robotic control systems;

user applications;

communication and security services;

local, edge, and cloud computation.

The Computational Architecture shall define boundaries, Interfaces, authority, dependencies, failure behavior, data flows, configuration, and lifecycle responsibilities.

Safety-critical physical functions should remain appropriately independent from optional computational services. Loss of cloud access, AI capability, external communication, or a nonessential application shall not create an uncontrolled physical state.

Computational Architecture is not identical to Digital Engineering. Digital Engineering governs engineering information and continuity; Computational Architecture defines the systems that process and act upon information.

The architecture should remain replaceable and vendor-independent where practical while preserving authoritative identities, semantics, security, and operational continuity.

102. Artificial Intelligence

Artificial Intelligence (AI) is the computational capability through which systems perform tasks involving inference, prediction, pattern recognition, generation, optimization, planning, language interpretation, perception, or decision support.

Within System05, AI may assist with:

engineering analysis;

compatibility evaluation;

manufacturing and inspection;

operational optimization;

anomaly detection;

maintenance planning;

robotic coordination;

knowledge retrieval;

lifecycle decision support.

AI output shall remain distinguishable from deterministic engineering rules, verified measurements, certified evidence, and authorized decisions.

AI does not possess engineering, professional, regulatory, ownership, or constitutional authority merely because it produces technically persuasive output.

Every consequential AI use should identify the applicable Model, version, input data, limitations, confidence, permitted purpose, and responsible human or system authority.

AI capabilities may evolve rapidly, but the governing requirements for safety, traceability, physical verification, human authority, and controlled change shall remain stable.

103. AI Model, Algorithm and Computational Tool

An AI Model is a mathematical or computational representation trained, configured, or otherwise developed to produce inferences, predictions, classifications, generated content, or decisions from inputs.

An Algorithm is a defined computational procedure or set of logical steps used to perform a task or transformation.

A Computational Tool is a software or hardware implementation used to execute calculations, simulations, rules, Models, Algorithms, or engineering workflows.

An AI Model may contain or use multiple Algorithms, and a Computational Tool may operate without AI.

Each safety- or engineering-relevant implementation should identify:

purpose and permitted use;

version and configuration;

training or reference data where applicable;

inputs and outputs;

validation domain;

assumptions and limitations;

uncertainty and failure modes;

cybersecurity status;

responsible owner or steward.

Validation of a Computational Tool does not validate every input or conclusion. Likewise, correct execution of an Algorithm does not prove that the selected method, assumptions, or physical model are appropriate.

104. AI Agent

An AI Agent is an identified computational system capable of interpreting information, maintaining goals or task context, selecting actions, using approved tools, and interacting with physical or digital environments within defined authority.

An AI Agent may:

observe states and events;

retrieve engineering information;

generate plans or recommendations;

initiate permitted workflows;

communicate with users or other systems;

request approval;

perform bounded actions;

record outcomes and update authorized records.

Not every AI interface, chatbot, Model, or automated script is an Agent. Agent status requires an operational loop connecting observation, reasoning or selection, and action.

Each Agent shall possess a declared identity, role, permissions, operating boundary, Model and tool dependencies, supervision mode, audit requirements, and safe failure behavior.

An Agent shall not expand its own authority, alter constitutional controls, approve its own restricted actions, or conceal uncertainty.

Agent output and activity shall remain attributable, reviewable, interruptible where required, and distinguishable from actions taken by human authorities.

105. Operations Agent and Design Agent

An Operations Agent is an AI Agent primarily responsible for supporting an existing Building during commissioning, operation, occupancy, inspection, maintenance, repair, emergency response, and lifecycle management.

It may monitor conditions, identify anomalies, optimize authorized systems, recommend maintenance, assist occupants, and coordinate approved service actions.

A Design Agent is an AI Agent intended to support the generation, evaluation, coordination, or revision of engineering configurations before manufacturing, construction, or major Retrofit.

The two roles shall remain separately identified because they possess different data, risks, authorities, validation requirements, and consequences.

Under the System05 phased strategy:

the Operations Agent is the principal early autonomous-agent application;

initial design activities remain human-led and may use AI as a controlled assistant;

an independent Design Agent may be introduced progressively when engineering libraries, verification systems, manufacturing evidence, and robotic execution capabilities are sufficiently mature;

no Design Agent may independently approve structural design, regulatory compliance, manufacturing release, or construction.

An Operations Agent shall not silently become a Design Agent by proposing or executing unapproved physical changes.

106. Decision Support, Automation and Autonomous Action

Decision Support is the provision of organized information, analysis, predictions, alternatives, or recommendations to assist an authorized decision-maker.

Automation is the execution of defined activities according to predetermined rules, sequences, triggers, or control logic.

An Autonomous Action is an action selected and initiated by a system based on interpreted conditions and objectives without requiring prior human approval for that specific instance.

These terms describe different authority relationships. A sophisticated AI recommendation may remain Decision Support, while a simple thermostat may perform Automation or bounded Autonomous Action.

Every consequential capability shall declare:

what information it may access;

what decisions it may recommend;

what actions it may execute;

permitted states and limits;

approval and notification requirements;

monitoring and override mechanisms;

rollback or recovery behavior;

A system shall not describe an action as “automated” to obscure who authorized the governing rules or who remains responsible for its consequences.

107. Human-in-the-Loop, Human-on-the-Loop and Human Authority

Human-in-the-Loop describes an arrangement in which a human must review, approve, complete, or reject a consequential step before the system may proceed.

Human-on-the-Loop describes supervised operation in which a system may act within defined limits while a human can observe, intervene, override, suspend, or assume control.

Human Authority is the formally assigned power and responsibility to make, approve, prohibit, or reverse decisions.

Human participation shall be meaningful. A person who lacks sufficient information, time, competence, access, or practical ability to reject an action does not provide effective oversight merely by being shown a notification.

The required control mode shall consider:

severity and reversibility of consequences;

system reliability and uncertainty;

speed of required response;

cybersecurity exposure;

affected people and rights;

legal and professional obligations.

Human oversight shall not be used to excuse unsafe automation design. Likewise, Human Authority shall not be assumed to validate AI output without appropriate engineering review and evidence.

108. Autonomy Level and Phased Autonomy

An Autonomy Level is a controlled classification describing the degree to which a system may perceive, decide, plan, and act without instance-by-instance human direction.

Phased Autonomy is the planned progression from limited assistance toward greater operational independence as evidence, infrastructure, verification, governance, and recovery capability mature.

Autonomy may progress through conditions such as:

information and recommendation only;

human-approved execution;

supervised bounded automation;

conditional autonomous operation;

higher autonomy within a certified domain.

Autonomy shall be classified by function and operating domain. A system may autonomously optimize energy while requiring human approval for maintenance, access control, or structural reconfiguration.

A single average autonomy number shall not conceal differences among perception, planning, physical action, emergency response, and recovery capability.

Advancement to a higher level shall require defined entry criteria, validation evidence, monitoring, authority, and safe fallback. Autonomy may be reduced when conditions, Models, configurations, communications, or evidence no longer support the approved level.

109. Robotics

Robotics is the engineering discipline concerned with machines capable of sensing, controlled movement, manipulation, physical interaction, or task execution within an environment.

Within System05, Robotics may support:

manufacturing;

material handling and logistics;

positioning and Assembly;

fastening and connection;

inspection and measurement;

maintenance and cleaning;

repair and replacement;

Disassembly and recovery.

Robotics and AI are complementary but distinct. A Robot may execute deterministic instructions without AI, and an AI system may operate without physical Robotics.

System05 shall consider robotic requirements from the beginning of physical and digital architecture while preserving practical human construction and maintenance where Robots are unavailable.

Robotic activity shall account for Tool Corridors, datums, temporary stability, machine-readable identity, connection states, force limits, human presence, emergency stopping, error recovery, and physical verification.

Completion of a robotic instruction sequence shall not independently prove that the physical work is acceptable.

110. Robot, Machine, Tool and End Effector

A Robot is a programmable Machine capable of controlled physical action, typically using sensing, motion, and task logic to interact with its environment.

An End Effector is the device attached to or integrated with a robotic manipulator to interact directly with a workpiece or environment.

End Effectors may include:

grippers;

fastening tools;

welding or cutting devices;

scanners and inspection probes;

material applicators;

lifting devices;

Each equipment item should possess an identity, capability envelope, configuration, calibration or validation status, maintenance history, safety limits, and compatible Interface definitions.

Nominal reach or payload does not prove suitability for a task. Actual suitability depends on geometry, orientation, tool access, accuracy, environment, force, stability, and failure conditions.

111. Robot Readiness and Machine Interaction

Robot Readiness is the degree to which an Engineering Entity, Interface, environment, instruction set, and workflow are intentionally designed to support reliable robotic interaction.

Machine Interaction is a controlled physical or informational exchange between a Machine and another entity.

Robot Readiness may require:

stable datums and coordinate frames;

machine-readable identity and orientation;

accessible grasping and Tool features;

Tool Corridors and clearance volumes;

defined loads and force limits;

temporary capture and safe release;

observable connection states;

machine-readable instructions;

predictable failure and recovery behavior;

human-safe interaction conditions.

Robot Readiness does not require that a Robot be used in every project. It preserves the ability to introduce Robotics without unnecessary redesign.

A component is not Robot-ready merely because a Robot can physically grasp or move it. Readiness shall be assessed for the complete task, environment, configuration, safety condition, verification process, and relevant Robot capability class.

112. Perception, Sensing, Localization and Machine State

Sensing is the acquisition of information about physical, environmental, digital, or operational conditions through Sensors or equivalent mechanisms.

Perception is the interpretation of sensed information to identify entities, relationships, events, features, or conditions.

Localization is the determination of a Machine’s or entity’s position and orientation relative to a declared coordinate system or environment.

A Machine State is the declared internal or external condition of a Machine, such as idle, initialized, moving, holding, faulted, stopped, isolated, or recovering.

Sensing provides observations; Perception gives those observations meaning; Localization establishes spatial relationship; Machine State describes the Machine’s current controlled condition.

These outputs shall identify uncertainty, reference frames, timing, calibration, configuration, and validity.

Estimated state shall remain distinguishable from directly measured state. Loss of perception or localization shall not be interpreted as proof that the environment is clear.

Safety-relevant actions shall require appropriate confidence, redundancy, guarding, or transition to a safe condition when the required information becomes unreliable.

Life Safety is the protection of people against conditions that may cause death, serious injury, entrapment, poisoning, fire exposure, structural collapse, or loss of essential escape and survival functions.

Life Safety is a critical subset of Safety and normally receives the highest protection and verification priority.

Safety shall be addressed through a hierarchy that may include:

hazard elimination;

inherently safer design;

physical protection;

redundancy and containment;

detection and control;

procedures and warnings;

training and protective equipment.

Absence of recorded incidents does not prove Safety. Safety depends on identified hazards, credible scenarios, exposure, controls, evidence, and continued performance.

Affordability, schedule, automation, convenience, or technical novelty shall not justify transferring unacceptable risk to occupants, workers, maintainers, emergency personnel, or the public.

Digital safety functions shall not substitute for adequate physical protection unless their reliability and failure behavior have been explicitly verified.

Risk is the evaluated combination of the likelihood and severity of harmful consequences under defined conditions and uncertainties.

A Consequence is the resulting effect of an event, such as injury, collapse, loss of function, environmental damage, financial loss, or information compromise.

Exposure is the presence, duration, frequency, proximity, or susceptibility of people, Assets, systems, or environments relative to a Hazard.

A Hazard may exist with low current Risk where Exposure is prevented. Conversely, frequent Exposure may make a moderate Hazard unacceptable.

Risk assessment shall identify:

system boundary and affected parties;

initiating events;

operating and lifecycle conditions;

credible failure sequences;

likelihood and uncertainty;

consequence severity;

existing and proposed controls;

residual Risk;

responsible acceptance authority.

Risk reduction shall not rely solely on low assumed likelihood when consequences are catastrophic and practical protective measures are available.

A Defect is a physical, digital, documentary, or process-related nonconformity that may affect quality, function, safety, appearance, or lifecycle performance.

An Error is an incorrect action, calculation, decision, instruction, data value, interpretation, or execution by a human or computational system.

An Error may introduce a Defect. A Defect may create a Fault. A Fault may result in Failure, but this sequence is not inevitable.

The architecture shall distinguish:

active and latent conditions;

detected and undetected conditions;

local and system-level effects;

temporary and permanent conditions;

safe and unsafe failures;

common-cause and independent failures.

A Fault indication does not prove that Failure has occurred, and continued operation does not prove the absence of a serious Defect.

Relevant conditions shall be recorded, investigated, classified, corrected, and reverified according to their consequences.

116. Fail-Safe, Safe State and Degraded State

Fail-Safe describes a designed behavior through which a system responds to specified faults or loss of capability by preventing or limiting unacceptable harm.

A Safe State is a defined condition in which applicable risks are controlled to an acceptable level.

A Degraded State is a controlled condition in which some functions or performance are reduced while essential safety and permitted services remain available.

A Safe State is context-dependent. Stopping movement may be safe for one Machine but unsafe for a Building ventilation, fire-protection, or load-support system.

Fail-Safe design shall identify:

triggering faults and uncertainties;

required detection;

transition behavior;

residual energy and loads;

essential functions;

human notification and intervention;

recovery or isolation requirements;

A system shall not remain indefinitely in a Degraded State unless the permitted duration, monitoring, restrictions, and corrective actions have been established.

117. Resilience, Redundancy and Fault Tolerance

Resilience is the ability of a system to anticipate, withstand, absorb, adapt to, recover from, and learn from adverse conditions while preserving or restoring essential functions.

Redundancy is the provision of additional Components, paths, information sources, or capabilities beyond the minimum required for normal operation.

Fault Tolerance is the ability to continue performing required functions correctly or acceptably despite specified Faults.

Redundancy may support Resilience or Fault Tolerance, but it does not guarantee either. Redundant Components may share the same power source, software, material weakness, environmental exposure, or manufacturing Defect.

The architecture shall consider:

common-cause failures;

independence and diversity;

detection and isolation;

load redistribution;

degraded operation;

recovery time and resources;

replacement and repair access;

data and communication continuity.

Resilience is broader than structural robustness. It includes physical, digital, operational, organizational, supply-chain, and lifecycle recovery.

Claims of Fault Tolerance shall identify the Faults tolerated, permitted performance reduction, duration, and required recovery conditions.

118. Cyber-Physical Security, Privacy and Trust

Cyber-Physical Security is the protection of connected digital and physical systems against unauthorized access, manipulation, disruption, counterfeit information, unsafe control, and loss of confidentiality, integrity, or availability.

Privacy is the governed protection and appropriate use of information relating to occupants, users, workers, owners, or other identifiable parties.

Trust is justified confidence in an entity, identity, process, record, relationship, or system based on evidence, authority, transparency, and reliable behavior.

System05 security should address:

identity and authentication;

authorization and least privilege;

secure configuration and updates;

software and supply-chain provenance;

communication and stored-data protection;

physical access and tamper detection;

event logging and anomaly detection;

vulnerability response and recovery;

Privacy shall account for purpose limitation, consent or lawful authority, data minimization, retention, access, and deletion obligations.

Security controls shall not create an undocumented obstacle to emergency safety, authorized maintenance, or long-term Asset ownership and operation.

119. Engineering Performance, Metric, Target and Benchmark

Engineering Performance is the demonstrated degree to which an Engineering Entity fulfills its required functions under declared conditions.

Performance may relate to:

safety and reliability;

structural and environmental behavior;

quality and accuracy;

manufacturing and assembly;

energy and resource use;

maintainability and replaceability;

cost and affordability;

robotic interaction;

A Target does not automatically become an acceptance criterion unless formally adopted as such. A Benchmark does not necessarily represent a minimum requirement or best achievable result.

Comparisons shall use equivalent boundaries and conditions. Apparent precision shall not conceal uncertain, incomplete, estimated, or noncomparable data.

120. Affordability, Sustainability and Environmental Performance

Affordability is the degree to which people, organizations, or communities can obtain, operate, maintain, adapt, and retain access to a Building or engineering solution without unacceptable financial burden.

Sustainability is the capacity to satisfy present functional and social needs while preserving environmental, economic, technical, and societal capability for future generations.

Environmental Performance is the measured or evaluated effect of an Engineering Entity on energy, water, materials, emissions, ecosystems, pollution, waste, climate, and resource recovery.

Affordability shall consider more than initial purchase cost. It may include:

financing and construction cost;

energy and utility cost;

maintenance and repair;

replacement and Upgrade;

service disruption;

Design Life and residual value;

deconstruction and recovery.

Sustainability claims shall identify lifecycle boundary, assumptions, geographic conditions, data sources, tradeoffs, and uncertainty.

Low initial cost shall not be achieved through unacceptable safety, durability, labor, environmental, or maintenance consequences. Likewise, environmental improvement shall not be claimed by shifting impacts to another lifecycle Stage, region, population, or unmeasured system.