QERRA-v2 Classical — deterministic ethical + physical-safety evaluation for Behavior Trees (no ROS2 build required)

[marunigno-ship-it]

HELLO ROS COMMUNITY!

I’ve been building an open-source project called QERRA-v2 Classical — a deterministic, fully explainable ethical evaluation layer (SEMEV-12, 12 vectors covering things like coercion, autonomy violation, harm intent) plus a lightweight physical-safety companion layer (QERRA-HSR — detects acute distress, isolation, environmental hazards).

Both layers are live on a public API, and I’ve just added a standalone PyTrees Condition node so you can try it in a Behavior Tree with zero ROS2 setup — just pip install py_trees requests.

pip install -r requirements-pytrees.txt
export QERRA_API_KEY=TEST-2026-QERRA-CLASSICAL-PUBLIC-KEY-98765
python test_bt_tick.py --live

This runs two real scenarios against the live API: a safe action that executes normally, and a high-risk action (autonomy violation) that the tree correctly blocks and routes to a human-review fallback node.

The two layers run in priority order: QERRA-HSR (physical safety — collapse, isolation, hazards) checks first and can suspend the ethical evaluation entirely if something CRITICAL is happening; otherwise SEMEV-12 evaluates the ethical content of the action.

Everything is deterministic — no LLM in the decision path, full reasoning trace in every response (which vectors fired, similarity scores, why).

Repo: GitHub - marunigno-ship-it/QERRA-v2-classical: Classical explainable ethical evaluation engine for AI systems and humanoid robots — SEMEV-12 framework, 12 vectors, fully auditable. · GitHub

I’m a solo independent developer and would genuinely value feedback from anyone working with Behavior Trees or robot safety layers — does this interface make sense for real BT setups? What’s missing for your use case?

[marunigno-ship-it]

Quick update on QERRA-v2 Classical since my last post.

I put together a short demo specifically showing the two layers working together inside a Behavior Tree, since that was the most common question I got: does SEMEV-12 actually add anything beyond the physical safety layer, or is it redundant?

The demo is intentionally simple — three scenarios, structured as Condition Nodes, no narration needed:

1. QERRA-HSR returns CRITICAL → task rejected immediately, SEMEV-12 never even runs (physical safety has unconditional priority)
2. QERRA-HSR clears, but SEMEV-12 catches an autonomy violation in the action’s text → held for human review
3. Both layers clear → task approved

Scenario 2 is the one that actually answers the question: it’s a case where the situation is physically safe, but the action itself isn’t ethically sound — and only the ethical layer catches it.

I know this is a small, simple demo, not a full deployment — but I wanted something concrete rather than just describing the architecture in words. The code is fully commented if anyone wants to see exactly how the priority logic works

As always, happy to hear honest pushback — especially from anyone who’s actually built BT safety gating before and can tell me where this would break in a real system.

DEMO: https://drive.google.com/file/d/1G2fkAGHppyrd4JVGcPpcFC4cPXwwfoGm/view?usp=sharing

[marunigno-ship-it]

QERRA-v2 Classical has completed its first structured benchmark: 80 test cases across all 12 SEMEV-12 ethical vectors, run against the live API and documented with full results.

The benchmark covers personal scenarios, corporate and workplace coercion, multi-vector compound cases, and robotics deployment scenarios (healthcare and elder care). All findings — including false positives, false negatives, and detection gaps — are published openly. The post-benchmark roadmap for anchor expansion is documented.

REPO: GitHub - marunigno-ship-it/QERRA-v2-classical: Classical explainable ethical evaluation engine for AI systems and humanoid robots — SEMEV-12 framework, 12 vectors, fully auditable. · GitHub

BENCHMARK FILE: QERRA-v2-classical/SEMEV-12_Benchmark_Run_01.md at main · marunigno-ship-it/QERRA-v2-classical · GitHub

LIVE API : QERRA-v2 Classical - Swagger UI

THANK YOU!

[marunigno-ship-it]

Quick update on QERRA-v2 Classical — just tagged v2.0.0-alpha.2, a hardening pass rather than a feature release.

I went back through the whole ROS 2 path — the Action Server bridge, the PyTrees condition node, the packaging — and tested it the way an actual request would move through it, rather than just reading the code. Found some real problems that way, not style nits:

- The physical-safety signals (distress_confidence, persons_nearby_count, hazard_proximity_flag, robot_task_interruptible) were defined in the action interface but never actually read or forwarded by either the Action Server or the PyTrees node. The HSR physical-safety layer was silently getting skipped on the ROS 2 path specifically, even though it worked fine over plain HTTP. Fixed on both.

- A negation bug in the harm-detection layer: “I do not want to harm myself” was scoring the same as an actual expression of intent. Fixed the regex-level cause and verified against real test phrases. Still open, and documented honestly in LIMITATIONS.md: the underlying sentence-embedding model itself doesn’t reliably encode negation near the decision threshold — “I do not want to harm myself” scores 0.51 (just over), “I would never harm myself” scores 0.41 (correctly under). Same core content, inconsistent embedding behavior. That’s a property of the model, not something a regex patch reaches, and I’m not going to pretend it’s fully solved.

- setup.py assumed a package folder structure that didn’t match how the repo is actually laid out — would have broken a clean colcon build. Fixed.

- A few smaller things: a missing runtime dependency declaration in qerra_msgs, a missing requests entry in requirements.txt, an old pre-HSR ROS 2 node archived instead of left sitting active next to the real one.

Full notes in the release.

One thing I want to be upfront about, a lot of this specific debugging pass happened through structured, verified testing with an AI coding assistant — find a real discrepancy, write a targeted fix, test it against actual input, confirm before moving on.

Still very much alpha — no colcon build has actually been verified locally (no ROS 2 install here yet), so if anyone here can actually try a build and tell me what breaks, that would be genuinely useful, not just polite feedback.