Platform Guardrails
Encoded contours — in-set and out-of-set — that product teams self-serve inside without a ticket per decision
Platform guardrails are encoded contours — allowable regions with clear in-set and out-of-set boundaries — that a platform team publishes as software so product teams can self-serve without a human gate on every action inside the region.
Introduction: One Authority Per Invariant — At Scale — firewall rules are the canonical shape: rules live in a policy engine; the system accepts or rejects; teams add what they need when in-set; security owns contour evolution, not every rule change.
The design goal: maximize the in-set — freedom of movement inside bounds — without compromising safety, coherence, consistency, ethics, and truth. Widen when MOE holds; tighten when meta-loop signals say aim drifted (double-loop learning on the platform product). Widening the in-set is not permission to ship dark patterns.
What guardrails must be in software
Guardrails fail as slide-deck principles. Platform products require:
Watch MOP (did checks run?) separately from MOE (did the contour still protect aim?) — see LLM-enabled MOE tracking.
Failure shapes
Not the same as informal “guardrails” in safety prose (commitment-boundary structure). Platform guardrails are the productised form at scale.
Corpus stance
A2 — working context: Operational vocabulary for platform teams; implement via platform self-service guardrails pattern.