Spec-Driven Development SDD — Hardware Specification & Testability (Hardware SDD)

(Human‑authored, governs physical robot behavior, testability, and safety)

1. Purpose

Defines the physical, electrical, mechanical, thermal, and diagnostic constraints of the humanoid robot.
Ensures the robot is testable, observable, controllable, and safe at the hardware level.

2. Scope

Applies to:

actuators
joints
sensors
PCBs
battery systems
thermal systems
safety controllers
embedded firmware
calibration systems
diagnostics

3. Functional Requirements

The hardware must:

support stable locomotion
support manipulation up to rated payload
provide accurate sensor data
maintain thermal stability
support OTA firmware with rollback
support hardware‑level diagnostics
support safe‑mode operation

4. Negative Requirements

Hardware must never:

exceed torque limits
exceed thermal limits
exceed voltage/current limits
operate with failed sensors
disable safety interlocks
allow irreversible actions without safeguards
allow firmware flashing without dual approval

5. Safety Invariants

Must always hold:

joint torque ≤ rated limit
actuator temperature < 80°C
battery temperature < 55°C
IMU + vision fusion valid
collision detection active
emergency stop functional
center of mass within stability polygon

6. Design for Testability (DFT → DfAT)

Hardware must include:

JTAG / boundary scan
BIST (Built‑In Self Test)
actuator calibration mode
sensor calibration mode
force‑torque calibration
thermal calibration
safe‑mode locomotion
fault‑injection hooks
drift‑detection telemetry

This is Design for Agentic Testability (DfAT).

7. Diagnostics Requirements

Hardware must support:

POST
actuator torque test
joint encoder calibration
IMU calibration
vision alignment
thermal sensor validation
battery health diagnostics

8. Physical Irreversibility Constraints

Hardware must prevent:

falls
collisions
over‑torque
over‑force
thermal runaway
battery damage
irreversible mechanical damage

9. Evidence Requirements

Hardware must produce:

torque logs
thermal logs
IMU traces
vision hashes
error codes
calibration constants

Identity-Anchored AI Safety Protocol (IASP)

Identity-Anchored AI Safety Protocol (IASP) A Proposal for Context-Aware AI Authorization and Guardrail Evaluation Author: Anh Nguyen Organization: AI GRC Engineering, Repassure.ai Status: Draft Engineering Proposal for Discussion Version: 0.1 (July 2026) Status This document is a draft engineering proposal intended to stimulate discussion among AI

Spec-Driven Development SDD — Humanoid Testing & System Validation

(Human‑authored specification — governs testing, not test cases) 1. Purpose of This SDD This SDD defines the governance, safety envelopes, autonomy boundaries, validation requirements, and evidence obligations for testing and system validation of a humanoid robot. It ensures that all testing is: * safe * bounded * repeatable * auditable * aligned with physical irreversibility

Spec-Driven Development SDD — Humanoid Runtime Autonomy & Safety (Runtime SDD)

Human‑authored, governs what the robot is allowed to do in the real world) 1. Purpose Defines the runtime safety envelopes, autonomy boundaries, invariants, escalation rules, and evidence requirements for humanoid operation in real environments. This is the SDD that the Runtime Harness enforces. 2. Scope Applies to: * locomotion * manipulation

Spec-Driven Development SDD — Humanoid Training Specification (Training SDD)

(Human‑authored, governs what the robot is allowed to learn) 1. Purpose Defines the data, simulation, reward shaping, safety envelopes, and validation gates for training humanoid locomotion, manipulation, perception, and human‑interaction policies. Ensures the robot only learns safe, reversible, bounded behaviors. 2. Scope Applies to: * reinforcement learning * imitation learning