Open-source, frozen safety “veto kernel” for robots — looking for technical critique

Discussion & Curiosity

Hi r/robotics,

I’m sharing a small open-source project called Guardian Seed and I’m looking for technical review / critique, not hype.

What it is: A minimal, deterministic “veto layer” intended to sit in parallel with an existing planner/controller and block unsafe actions. It is not a planner, not an AI alignment system, and not a replacement for hardware safety.

Core idea: Instead of learning safety or reasoning about ethics, the core is a frozen, auditable kernel (22 lines) that enforces three hard constraints: 1. No Harm (explicit vetoes for known dangerous patterns) 2. Dignity First (weighted threshold, w ≥ 0.58) 3. Safe Risk Only (hard cap at 4.5%, urgency-bounded)

Everything else (context, perception, planning, ML) lives upstream. The kernel never learns, never reasons, never mutates.

Why I built it: Most safety systems I see are either: • deeply entangled with planners, • learned/opaque, • or too large to audit quickly.

This is meant to be the opposite: boring, conservative, and inspectable — something you could plausibly run on a microcontroller or safety co-processor.

What’s included: • Frozen kernel (guardian_kernel.py) • Explicit design constraints (immutability, determinism) • Threat model (what it does / does not defend against) • Adversarial falsification harness (tries to break it) • Sentinel layer for sustained adversarial pressure • Benevolent fallback for life-risk escalation (calls for help instead of acting)

What I’m asking for: • Is this redundant with existing robotics safety patterns I’ve missed? • Are the assumptions flawed for real-world robotics? • Is the separation between planner vs. veto layer reasonable? • Where would this not make sense to deploy?

I’m not claiming novelty or completeness — just testing whether this is a useful primitive or an unnecessary abstraction.

Repo: 👉 https://github.com/adamhindTESP/Guardian-Seed

Appreciate any technical feedback, especially from folks working in embedded safety, mobile robots, or human–robot interaction.

Thanks.

Posted Dec 29, 2025, 6:27 PM UTC

09
Loading comments…