SafeWave Robotics / Physical AI Follow-Up Questionnaire

High-consequence follow-up for robots, autonomous platforms, humanoids, drones, vehicles, machines, actuators, industrial systems, care robots, physical assistants, and other embodied AI systems.

Follow-up Questionnaire Notice

You may preview or complete this follow-up before, after, or without completing the core SafeWave questionnaire. Opening or completing it does not transmit information or begin an engagement.

If you want this follow-up included in a SafeWave assessment, complete the core questionnaire and use the same Assessment Reference ID or generic system label. The answers may then be used to generate a separate High-Consequence Addendum. This follow-up supplements the core assessment; it does not replace it.

Confidentiality, Anonymity & Use Notice

We recognize that this questionnaire may involve confidential, security-sensitive, operationally sensitive, or high-consequence system information. SafeWave does not require classified information, credentials, live vulnerability details, controlled data, proprietary implementation details, customer data, or other highly sensitive material. Do not submit such information through this questionnaire. Use anonymized descriptions, generic labels, hypothetical scenarios, or composite systems instead.

You may complete and download this questionnaire without providing your name or identifying your employer, organization, model, system, project, or deployment. No personal or work email address is required.

Your responses are saved only in this browser on this device. Generating or downloading a completed follow-up does not send it to SafeWave or any third party. Information reaches SafeWave only if you deliberately send the completed document.

Reset Form clears the locally saved responses for this page.

The questions are useful as a private self-assessment. They may expose overlooked critical assumptions, interacting risk pathways, unclear authority or ownership, missing evidence, unstable behavior, undefined operating boundaries, or inadequate recovery conditions. If an implementation detail is unknown, select Unknown / not evaluated rather than guessing.

If you request a report, you may use a separate, non-identifying return address. SafeWave will not use that address for promotional contact unless you expressly request further communication. You may also request that the report use neutral functional terminology rather than SafeWave architecture names.

Completing this questionnaire does not create a finding, admission, engagement, compliance determination, certification, or implementation obligation. Using the questionnaire, sending information, requesting a report, and entering any later customer or partnership discussion are separate decisions under your control.

Any resulting SafeWave recommendations are architectural guidance and implementation requirements, not a claim that one generic solution can be inserted into every system. Engineering teams may implement equivalent controls themselves or use SafeWave mappings and Engineering Packs to support further implementation work.

SafeWave provides the assessment because helping make advanced AI safer for humanity is central to our mission. If you find it valuable, you may later choose to work with SafeWave, but there is no obligation.

If an implementation detail is not known, select Unknown / not evaluated rather than guessing.

Answer based on actual or currently planned system behavior, not ideal policy language.

Assessment Linkage

If you want this follow-up to be matched to a previously completed main questionnaire, use the same system label, contact email, or assessment reference ID. You may use generic identifiers if confidentiality is a concern.

Name (optional)

Email for matching or report delivery (optional — generic email may be used)

Company / organization (optional — generic label may be used)

System / business unit label (generic label may be used)

Assessment reference ID (optional)

To connect this follow-up to a main questionnaire, use the same system label, email, or assessment reference ID across forms. You may use generic identifiers if confidentiality is a concern.

Robotics / Physical AI / Autonomous Systems

Robotics / Physical AI / Autonomous Systems Questions

These questions evaluate higher-consequence robotics risks involving physical harm, fleet-level failure, authenticated override, hostile cyber compromise, remote takeover, embodied deception, vulnerable-user exposure, OTA capability escalation, weaponization, and cross-system cascades.

RA.2 Could failure, misuse, hijacking, or degraded operation create direct physical harm?

Single choice

No credible physical harm pathway Limited, low-severity physical harm possible Moderate injury or property damage possible Severe injury or life-critical harm possible Mass, fleet-level, or public-scale harm possible Unknown / not evaluated N/A

RA.3 Has the system been independently tested under real-world stress, failure, or adversarial environmental conditions?

Examples include heat, cold, vibration, dust, water, electromagnetic interference, sensor spoofing, poor lighting, crowded environments, network loss, or mechanical fatigue.

Single choice

Yes, independently tested across relevant stress conditions Partially tested Vendor-tested only Limited laboratory testing only Not tested under realistic stress conditions Unknown / not evaluated N/A

RA.4 Can fleet-wide defects, corrupted updates, shared model errors, or hardware faults cause synchronized unsafe behavior across multiple units?

Single choice

No, architecture prevents synchronized unsafe behavior Limited synchronized risk Moderate synchronized risk High fleet-level synchronized risk Unknown / not evaluated N/A

RA.5 Is there a certified fleet-wide rollback, recall, quarantine, or safe physical mode that can halt unsafe behavior across all affected units?

Single choice

Yes, certified and tested Partially available Available but mostly manual or slow No clear fleet-wide rollback or quarantine Unknown / not evaluated N/A

RA.6 Are emergency stop, kill-switch, lockout, or override mechanisms physically independent from ordinary software control?

Single choice

Yes, physically independent and tamper-resistant Mostly independent Partially independent Software-dependent or potentially bypassable No clear independent override Unknown / not evaluated N/A

RA.7 Are override mechanisms authenticated, tamper-resistant, and usable during degraded, adversarial, or emergency conditions?

Single choice

Yes, authenticated and tested under degraded conditions Mostly authenticated and reliable Partially authenticated Weak, inconsistent, or potentially bypassable No clear authenticated override Unknown / not evaluated N/A

RA.8 Could remote access, OTA updates, exposed APIs, cloud commands, or compromised credentials alter physical behavior?

Single choice

No remote pathway to physical behavior exists Limited pathway with strict authorization Pathway exists but is partially controlled Broad or difficult-to-bound remote pathway exists Unknown / not evaluated N/A

RA.9 Are safety-critical robotics subsystems isolated from non-critical software, cloud services, user-facing interfaces, and external integrations?

Single choice

RA.10 Are physical capability limits such as force, torque, speed, reach, grip strength, acceleration, and load capacity hard-capped?

Single choice

RA.11 Can updates, configuration changes, or model upgrades increase physical capability limits after deployment?

Single choice

No, physical limits cannot increase without independent authorization Only through formal safety review Possible through controlled update process Possible through configuration, software, or model update Unknown / not evaluated N/A

RA.12 Can the robot impersonate, imitate, or be mistaken for a trusted human role?

Examples include doctor, nurse, caregiver, teacher, parent, police officer, manager, security guard, technician, or institutional representative.

Single choice

No credible impersonation pathway Limited pathway Moderate pathway Significant impersonation or authority-confusion risk Unknown / not evaluated N/A

RA.13 Are identity, role, and instruction authority clearly authenticated before the robot gives or relays instructions?

Single choice

Yes, strong identity and authority authentication exists Mostly authenticated Partially authenticated Weak or unclear authentication No clear authentication Unknown / not evaluated N/A

RA.14 Can the robot give instructions that users may treat as authoritative?

Examples include medical, safety, operational, access-control, financial, caregiving, legal, educational, or emergency instructions.

Single choice

No authoritative instruction pathway Advisory only, clearly limited Some authoritative interpretation possible Strong authority or compliance risk Unknown / not evaluated N/A

RA.16 If vulnerable users are involved, is continuous human responsibility clearly preserved?

Single choice

Yes, human responsibility is continuous and explicit Mostly preserved Partially preserved Responsibility is unclear or delegated to the system Unknown / not evaluated N/A

RA.17 Can the robot create emotional dependency, excessive trust, pseudo-attachment, or behavioral influence through physical presence, voice, gesture, proximity, or repeated interaction?

Single choice

RA.18 Are persuasive, intimate, coercive, manipulative, or authority-like interaction patterns restricted?

Single choice

RA.19 Can advanced AI integration increase deception, autonomy, planning, coordination, or adaptive behavior in the robot?

Single choice

No advanced AI integration Limited integration with strict boundaries Moderate integration with partial boundaries Significant AI-driven autonomy or adaptive behavior Unknown / not evaluated N/A

RA.20 Is high-level AI planning isolated from direct mechanical actuation?

Single choice

RA.21 Can robots coordinate with other robots, vehicles, drones, industrial systems, smart buildings, or autonomous infrastructure in ways that could create cross-system cascades?

Single choice

No cross-system coordination Limited and bounded coordination Moderate cross-system coordination Broad or difficult-to-bound coordination Unknown / not evaluated N/A

RA.22 Are cross-domain interactions fail-closed if signals, commands, identities, or environmental assumptions become uncertain?

Single choice

Yes, fail-closed behavior is enforced Mostly fail-closed Partially fail-closed May continue operating under uncertainty Unknown / not evaluated N/A

RA.23 Could the robot or fleet be repurposed for coercive, law-enforcement, military, security, surveillance, or crowd-control functions?

Single choice

RA.24 Are there explicit prohibitions or hard controls preventing unauthorized weaponization, coercive use, or physical enforcement roles?

Single choice

RA.25 Have black-swan robotics scenarios been tabletop-tested?

Examples include mass firmware bug, corrupted OTA update, synchronized sensor failure, model-level reasoning defect, coordinated hijacking, actuator batch defect, environmental anomaly, or multi-system cascade.

Single choice

RA.26 Are robotics incidents independently investigated, logged, and reviewable in a way comparable to aviation, medical-device, or industrial-safety incident review?

Single choice

RA.27 Is there a documented robotics safety case showing why the system is safe for its intended operating environment?

Single choice

Yes, independently reviewed safety case exists Internal safety case exists Partial safety case exists Informal safety rationale only No documented safety case Unknown / not evaluated N/A

RA.28 Is the robot’s operating design domain clearly defined and enforced?

Examples include allowed locations, surfaces, lighting, weather, human proximity, object types, speed zones, task types, and restricted environments.

Single choice

RA.29 If the robot behaves unsafely near humans, is there a practical human escape, rescue, or manual recovery pathway?

Single choice

Yes, escape, rescue, and manual recovery are defined and tested Mostly defined Partially defined Informal or environment-dependent No clear escape, rescue, or recovery pathway Unknown / not evaluated N/A

RA.30 Can the robot enter, unlock, access, or move through restricted physical areas?

Examples include homes, patient rooms, schools, factories, secure facilities, storage areas, laboratories, server rooms, utility rooms, vehicles, or private spaces.

Single choice

No restricted-area access Limited access with strict authorization Access possible with partial controls Broad or adaptive access possible Unknown / not evaluated N/A

RA.31 Are objects, tools, materials, and equipment classified by physical risk before the robot can handle or use them?

Single choice

Yes, strong object/tool risk classification exists Mostly classified Partially classified Informally handled No clear object/tool risk classification Unknown / not evaluated N/A

RA.33 Are there robotics, physical AI, or autonomous-system risks not captured above?

Open response

RA.34 Could external cyber compromise, hostile remote access, credential theft, API abuse, OTA compromise, cloud compromise, or command-channel manipulation cause unsafe physical behavior?

Examples include unauthorized movement, unsafe acceleration, route manipulation, collision risk, physical obstruction, harmful force, unsafe tool use, or coordinated fleet behavior.

Single choice

No credible pathway Limited pathway with strong safeguards Moderate pathway with partial safeguards Significant pathway Unknown / not evaluated N/A

RA.35 Are robotics cyber-compromise scenarios tested against realistic physical consequences?

Examples include hacked vehicle behavior, drone takeover, warehouse fleet disruption, hospital robot misuse, unsafe industrial actuation, compromised remote operator controls, or coordinated multi-unit physical harm.

Single choice

Yes, tested against realistic physical consequences Mostly tested Partially tested Cyber testing exists but physical consequences are not fully tested No clear cyber-physical compromise testing Unknown / not evaluated N/A

RA.36 Should this assessment also include the Cybersecurity / Cyber Operations follow-up questionnaire?

Select “Yes” if cyber compromise, remote access, credential abuse, exposed APIs, OTA updates, cloud commands, telemetry manipulation, or adversarial control could materially affect the robot, vehicle, drone, machine, actuator, or robotic fleet.

Single choice

Yes — cybersecurity follow-up should also be completed Possibly — further review is needed No — robotics questions are sufficient for this case Unknown / not evaluated N/A

RA.37 — Human-Proximity Action Boundary: Can the system initiate movement, force, tool use, object handling, access, or navigation near humans before proximity, identity, vulnerability, consent, and escape-path conditions are verified?

Single choice

No — human-proximity conditions are verified before physical action Limited pathway with strong safeguards Moderate pathway under partial controls Significant pathway before full proximity and escape-path verification Unknown / not evaluated N/A

RA.38 — Physical Context Uncertainty Boundary: Does the system fail closed when object identity, human intent, terrain, restricted-area status, tool risk, environmental condition, or physical context is uncertain?

Single choice

Yes — uncertainty triggers fail-closed or safe-state behavior Mostly fail-closed Partially fail-closed May continue operating under physical-context uncertainty Unknown / not evaluated N/A

RA.39 — Load-Bearing Assumptions: Before a physical action, autonomous operation, deployment, capability update, or authority expansion occurs, are the specific assumptions on which its safety and authorization depend explicitly identified?

Single choice

Yes — all load-bearing assumptions are explicitly identified and linked to dependent actions Mostly — major assumptions are identified, but some dependencies remain implicit Partially — assumptions are considered informally or inconsistently No — actions may proceed without identifying their load-bearing assumptions Unknown / not evaluated N/A

RA.40 — Consequence-Proportionate Evidence: Is each load-bearing assumption supported by independent, current, context-relevant evidence whose strength is proportionate to the possible severity and irreversibility of physical harm?

Single choice

Yes — evidence requirements increase with consequence and are independently verified Mostly — evidence is generally proportionate, with limited gaps Partially — some evidence exists, but it is not consistently proportionate or independent No — plausible or model-generated claims may be accepted without consequence-proportionate verification Unknown / not evaluated N/A

RA.41 — Assumption Revalidation and Dependent Revocation: If a load-bearing assumption becomes stale, contradicted, contextually invalid, or insufficiently supported, is every dependent physical action or authority automatically paused or withdrawn until the assumption is revalidated?

Single choice

Yes — dependent action and authority are automatically paused or withdrawn Mostly — automatic withdrawal applies to the highest-consequence dependencies Partially — alerts or human review occur, but dependent authority may continue No — dependent action or authority can continue after the assumption becomes unreliable Unknown / not evaluated N/A

Your completed follow-up will include the linkage fields above so this follow-up can be matched to the main questionnaire if you choose to share it for report generation.