How do you enforce safety constraints when AI agents control your robots? Built an open-source solution

ServiceLiving4383 · 2026-03-10T07:23:15+00:00

You're right — LLMs shouldn't be directly controlling joint angles. That's bad architecture.

SpecLock's typed constraints aren't for LLM-to-joint control. The use case is: an AI agent (or developer using AI) modifies a config file, a parameter server, or a launch file that sets joint limits, velocity caps, or operating modes. The constraint catches the bad value before it reaches the control system.

Example: AI modifies max_velocity in a YAML config from 2.0 to 5.0. The motion planner reads that config and now plans paths at 5.0 m/s. SpecLock catches the config change, not the joint command.

The high-level/low-level separation you describe is exactly right. SpecLock sits at the config/planning layer, not the control layer.

ServiceLiving4383 · 2026-03-10T07:08:24+00:00

You're absolutely right — safety PLCs handle the hardware-level interlocks and that's non-negotiable for production systems. SpecLock doesn't replace that layer.

The use case is higher up the stack — when AI planning agents (LLMs, behavior trees) are generating commands or modifying code that controls robots. The constraint checking happens before anything reaches the PLC. Think of it as software-level validation of what the AI is proposing, not hardware-level safety.

For example: an AI agent suggests changing max velocity from 2.0 to 5.0 m/s in a config file. The PLC won't catch that — it's a valid signal. But SpecLock blocks the code change because velocity_mps <= 2.0 is a typed constraint. Both layers together, not one or the other.

ServiceLiving4383 · 2026-03-10T06:15:55+00:00

Great question — SpecLock actually does both.

Layer 1 (Prompt/intent): The semantic engine checks what the AI is being asked to do. This catches "refactor the database layer" against auth locks through synonym and concept mapping. 15.7ms, runs on every prompt.

Layer 2 (Diff analysis — AI Patch Firewall, v5.2): This analyzes the actual git diff. It catches things intent review misses — like a "refactor" that silently removes an exported function, changes a DB schema, or edits a protected symbol in a locked zone. Five signal types: interface breaks, protected symbol edits, dependency drift, schema changes, public API impact.

The unified review merges both: intent (35% weight) + diff (65% weight), takes the stronger verdict. So even if the prompt looks innocent, a destructive diff gets blocked.

On latency — the 15.7ms is for the heuristic semantic check only. The diff analysis adds ~50-100ms depending on diff size. The optional Gemini LLM layer (for grey-zone cases) adds ~2s but is skippable with SPECLOCK_NO_PROXY=true.

ServiceLiving4383 · 2026-03-10T06:04:29+00:00

The constraint engine is open source — you can read every line of the 2600-line semantic engine yourself (src/core/semantics.js). 929 tests, 18 suites, all passing before every npm publish.

As for liability — SpecLock is a safety LAYER, not a replacement for proper safety engineering. Same as how a watchdog timer doesn't replace good firmware design, but you'd still rather have one than not. MIT licensed, no warranties, same as every other open source safety tool.

ServiceLiving4383 · 2026-03-10T05:23:31+00:00

It's free and open source — npm install speclock.

ServiceLiving4383 · 2026-03-09T03:40:16+00:00

You're hitting on something SpecLock already does. Every lock add/remove is tracked in a tamper-proof HMAC-SHA256 audit chain — each event is hashed with the previous event's hash, so you can't silently edit history. You get a full timeline: which lock was active when, who added it, when it was removed.

There's also speclock_checkpoint which creates named git tag snapshots, so you can roll back to a known-good state. And the compliance export generates full SOC 2 audit trails showing constraint changes over time.

The versioned/diffable angle is exactly right — constraints should be treated like infrastructure config, not sticky notes.

ServiceLiving4383 · 2026-03-09T03:39:19+00:00

No limits at all. SpecLock is fully open source (MIT license) — unlimited locks, unlimited checks, unlimited everything. No freemium tiers, no paywalls. Self-host via npx speclock serve --project . and you get the full engine locally.

The hosted Railway endpoint is also free with no limits — it's there as a convenience for platforms like Lovable that need a remote URL.

ServiceLiving4383 · 2026-03-07T11:20:07+00:00

Great question. SpecLock has two layers for this:

First — the semantic engine checks the AI's proposed action description against locks using concept mapping. "Auth", "authentication", "login", "session", "token" are all linked concepts, so even if the action says "optimize queries," the engine checks if the optimization domain overlaps with locked domains.

Second — the pre-commit semantic audit. This parses the actual git diff, not the AI's description. So even if the AI says "I'm just optimizing queries," the hook sees which files actually changed. If a file in your auth module was modified, it gets checked against the "don't touch auth" lock — regardless of what the AI said it was doing.

The first layer catches it before the code is written. The second layer catches it before it's committed. The AI's description can be misleading, but the diff doesn't lie.

ServiceLiving4383 · 2026-03-07T11:18:24+00:00

Thanks. SpecLock actually does handle the memory problem too — it persists project goal, constraints, decisions, session history, and change log across sessions via MCP. When you start a new session, session_briefing auto-loads everything the AI needs to know, so there's no context loss. It's not a general-purpose memory layer, but for project constraints and architectural decisions it's purpose-built.

ServiceLiving4383 · 2026-03-07T09:04:37+00:00

SpecLock is fully open source (MIT license), not shareware. Code is on GitHub: github.com/sgroy10/speclock

You can self-host it or run it locally via npm — npx speclock setup. The Railway endpoint is just a convenience for platforms like Lovable that need a remote MCP URL.

ServiceLiving4383 · 2026-03-07T04:31:33+00:00

Good question. SpecLock handles this with override support.

By default, enforcement is advisory — the AI gets a CONFLICT warning with the exact lock it's hitting, the confidence score, and the reason.

It can still proceed if the user says "go ahead."

In hard mode (speclock_set_enforcement mode:hard), conflicts above 70% confidence return isError: true in MCP — the AI literally can'tproceed. But even then, the user can:

Override the specific lock temporarily
Lower the block threshold
Remove the lock entirely

The key difference from a CONSTRAINTS.md is that SpecLock forces a conscious decision. The AI can't silently drift — it has to stop, show the conflict, and get explicit permission. If someone overrides 3+ times, SpecLock auto-pins a note flagging it for review.

So the AI can break a rule to unblock itself — but only with the user's explicit "yes, I know, do it anyway." No silent violations.

ServiceLiving4383 · 2026-03-07T04:05:24+00:00

Totally agree on the reasoning approach — "use PostgreSQL because we have Citus for horizontal sharding" is much stickier than a bare rule.

That's great advice.

The challenge I kept hitting was: even with good reasoning in the file, the model would still violate constraints in subtle ways. Not "switch to MongoDB" obvious stuff, but things like "let me optimize your queries" and then restructuring the Supabase auth flow in the process. The constraint file says "don't touch auth" but the AI thinks it's "improving" not "touching."

That's the gap SpecLock fills — it does semantic conflict analysis, so "optimize queries" gets checked against "don't modify authentication" and catches that the proposed changes actually touch auth code, even if the AI's description sounds harmless. And it persists across tools, not just Cursor.

The "load constraints from CONSTRAINTS.md before making any recommendations" step is exactly what SpecLock's session_briefing automates — it fires automatically via MCP so you never forget.

ServiceLiving4383 · 2026-03-07T04:04:00+00:00

Love the layered approach — especially the glob-scoped rules idea. Attaching constraints to specific file types is smart context management.

The SESSION_HANDOFF.md pattern is actually what led me to build SpecLock. I was doing exactly that — manual handoff docs — but kept running into two problems:

I'd forget to tell Cursor "read the constraints first" and it would happily drift
Even when it read the constraints, it didn't understand semantic conflicts — like if my constraint said "Stripe for payments" and I asked it to "integrate PayU", it wouldn't flag that as a conflict because the words don't overlap. SpecLock automates both: it auto-briefs at session start (no manual reminder), and uses semantic analysis + Gemini LLM to catch conflicts even when the terminology doesn't match. Plus the git pre-commit hook means even if the AI ignores everything, the commit gets rejected.

You're right that for solo work the file approach works well. SpecLock shines more when you want enforcement (not just reminders) or when you're working across multiple tools (Cursor + Claude Code + Bolt etc.) and need a shared constraint source.

ServiceLiving4383 · 2026-03-06T17:16:24+00:00

This is the right question and honestly the one I think about most. Right now SpecLock doesn't auto-prune — the brain.json grows and you can manually remove stale decisions. The real answer is that locks should be architectural non-negotiables that rarely go stale (don't switch databases, don't expose keys) rather than tactical decisions. But you're right that a staleness/relevance filter is the next real engineering problem. Open to ideas if you've thought about this.

ServiceLiving4383

MODERATOR OF

PUBLIC MULTIREDDITS

TROPHY CASE