After receiving helpful feedback, I want to state more clearly what this project is and why it differs from current robotic practice.
On the surface it looks like standard software engineering. The novel value, for robotics and autonomous medical systems, is where and how the safety boundaries are enforced.
1. Hard runtime decoupling vs. "policy as code"
Most autonomous systems, including ROS-based setups, rely on internal state machines, rule engines, or local safety nodes running inside the same execution pipeline. If the model or motion planner decides to move, it checks an internal flag.
Standard approach: The planner evaluates conditions locally. A bug, memory corruption, or race condition in the application layer can still let the actuator command fire.
This architecture: The runtime is a strict pre-execution gate. The physical adapter can not receive an instruction unless a cryptographically signed, validated grant is produced and consumed in a single transaction. The robot engine has no path around the gate.
2. Evidence commits as a hard prerequisite for motion
Traditional systems log asynchronously or after execution: fire the motor, then write the record. If the database locks, crashes, or loses connection, the robot keeps moving and the physical event goes untracked.
This architecture: No commit, no movement. The cryptographic evidence entry (the SHA-256 hash chain record) must commit to disk before the hardware adapter receives the payload. If the audit trail fails, physical execution is blocked at the database transaction layer.
3. Fail-closed accountability
In robotics software, "fail-safe" means stopping when an obstacle appears. Fail-closed at the authorization level means the system treats uncertainty of state (unverified patient identity, missing order parameters, an unwritten audit log) as a critical hardware fault.
Summary
The novelty is not SQLite, cryptographic hashing, or REST endpoints. It is the trust boundary: physical actuation sits downstream of a transactional proof.
The architecture treats the autonomous planner as untrusted software. Before any motor turns, it must present verifiable, auditable receipts to a strict runtime.
Log in or sign up for Devpost to join the conversation.