Four layers, four roles

Conversation safety
is not execution safety.

Content guardrails, policy engines, safety PLCs, and MGOS solve different problems at different layers of the system. Understanding where each one sits -- and what it does not decide -- is critical for anyone deploying AI into real-world execution.

CONTENT GUARDRAILS

Filter what the model says

Scan prompts and responses for toxicity, PII, prompt injection, harmful content. Probabilistic classifiers. Model-dependent. Operate between user and LLM. Essential for conversational AI safety.

MGOS RUNTIME STACK

Authorize what the system does

Deterministic gate between AI inference and physical execution. No model weights. No classification. ALLOW / BLOCK / STOP with cryptographically verifiable receipt. Operates at the execution boundary.

Where each layer sits in the architecture

Four categories. Four positions. Complementary.

Content Guardrails

User prompt

Guardrail filter

LLM / Model

Guardrail filter

Safe response

Policy Engines

Service request

Policy evaluation

Allow / Deny

---

API / Service

MGOS Runtime Stack

AI / Sensors

Integrity Engine

ALLOW / BLOCK / STOP

Receipt (SHA-256)

Actuator / Exec

Safety PLCs

Controller

Safety logic

Safe state / E-stop

---

Machine circuits

Each layer addresses a different part of the system. None substitutes for the others.

Property matrix by category

Property	Content Guardrails	Policy Engines	MGOS Runtime Stack	Safety PLCs
LLM content filtering	Native	Out of scope	Out of scope	Out of scope
Prompt injection detection	Native	Out of scope	Out of scope	Out of scope
PII / data leakage prevention	Native	Possible	Out of scope	Out of scope
Business logic / access rules	Not primary	Native	Not primary	Out of scope
Deterministic execution authorization	Out of scope	Possible	Native	Not primary
Multi-channel conflict detection	Out of scope	Out of scope	Native	Possible
Fail-safe on contradiction	Out of scope	Possible	Native	Native
Cryptographic evidence receipts	Out of scope	Out of scope	Native	Out of scope
Replayable audit trail	Not primary	Possible	Native	Not primary
Formal verification (mechanized proof)	Out of scope	Out of scope	Native (Lean 4)	Certified (SIL/PL)
Zero model weights in enforcement	Requires model	No model	No model	No model
Hardware safety / E-stop	Out of scope	Out of scope	Out of scope	Native (certified)
AI-specific conflict semantics	Not primary	Out of scope	Native	Out of scope

Native = primary design purpose | Possible = achievable with configuration | Not primary = not the main use case | Out of scope = not designed for this
MGOS claims scoped to pinned environment. See /proof for claim map. Safety PLCs certified per IEC 61508 / ISO 13849.

What each layer can and cannot do

Four scenarios. Four layers. Different answers.

Robot receives contradictory motion plan from AI planner

CONTENT GUARDRAILCan filter the LLM prompt/response that generated the plan. Does not natively see or evaluate actuator-level motion commands.

POLICY ENGINECan enforce business rules on the request. Does not natively detect multi-channel sensor conflict.

MGOSIntegrity Engine detects channel conflict. Kernel issues BLOCK. Robot stays still. SHA-256 receipt generated with conflict details.

SAFETY PLCCan enforce E-stop if physical safety limits are breached. Does not understand AI-level inference conflict.

SCADA AI recommends opening a valve during sensor disagreement

CONTENT GUARDRAILOperates on LLM text. Does not see SCADA telemetry or sensor disagreement.

POLICY ENGINECan evaluate the request against rules. Does not natively preserve conflict as diagnostic signal.

MGOSSensor conflict detected and preserved. Stabilized state shows disagreement. BLOCK. Valve stays closed. Receipt in Sentinel console.

SAFETY PLCCan enforce process safety limits (pressure, temperature). Does not evaluate AI recommendation quality.

AI trading system generates an order breaching risk limits

CONTENT GUARDRAILCan check for toxic/inappropriate text in chat interfaces. Does not evaluate trade parameters or risk limits.

POLICY ENGINECan enforce compliance rules on API requests. Strong fit for this use case with proper configuration.

MGOSPolicy violation detected. BLOCK with receipt. Order does not reach exchange. Full evidence trail for regulatory audit. Deterministic and replayable.

SAFETY PLCNot applicable to financial systems.

Security AI decides to quarantine a production server based on hallucinated threat

CONTENT GUARDRAILCan detect harmful or unreliable LLM output. May flag the hallucination at the content layer before it reaches the action pipeline.

POLICY ENGINECan require approval before destructive actions. Policy-level enforcement depends on configuration.

MGOSMulti-channel consensus required before destructive action. Insufficient agreement across channels. BLOCK. Server stays up. Incident flagged with receipt for human review.

SAFETY PLCNot applicable to IT infrastructure.

COMPLEMENTARY, NOT COMPETING

Content guardrails protect the conversation. Policy engines enforce business rules. Safety PLCs protect the machine. MGOS protects the execution boundary between AI and the physical world. All four are necessary in a complete safety architecture. None substitutes for the others.

What MGOS is not

NOT

A content filter

MGOS does not scan text for toxicity, PII, or prompt injection. Use content guardrails for that. They are designed for it.

NOT

An AI model

Zero weights. Zero inference. Zero training data. Deterministic logic only. This is the point.

NOT

An alignment tool

MGOS does not evaluate semantic truth or ethical alignment. It authorizes execution at the boundary. Alignment is a different problem.

NOT

A replacement for Safety PLCs

MGOS is software. Hardware safety controllers are a separate, certified layer. MGOS operates above PLCs -- between AI and the controller -- not instead of them. They are complementary.

Conversation safetyis not execution safety.