Guardrails the model can’t argue with
A rule written in a prompt is a request. A rule enforced by the executor is a fact. Fibric’s policies live on the deterministic side of the trust line, where the model’s eloquence counts for nothing — and that is the entire point.
The most common way to constrain an agent today is to tell it what not to do. The system prompt says: never refund more than fifty dollars, never message customers at night, never touch the VIP accounts. And most of the time, the model complies. But “most of the time” is a probability, and a guardrail that holds probabilistically is not a guardrail. It is a suggestion with good uptime.
The failure modes are well documented by now. A long context pushes the instruction out of effective attention. A cleverly framed input reads like an exception the rule surely did not mean to cover. A model update shifts the compliance rate by a fraction of a percent, and nobody notices until the fraction lands on something expensive. None of this is a defect in any particular model. It is what it means to encode a constraint in a system whose job is to weigh evidence and be persuaded. Rules should not be persuadable.
Enforcement below the reasoning
Fibric puts policies where they cannot be argued with: in the deterministic executor, on the far side of the propose/dispose line. The model reads real state and proposes a validated plan. Before any step of that plan reaches a connector, the executor checks it against policy — code, not prose. If a step violates a rule, the step does not fire. The executor does not negotiate, does not weigh the model’s justification, and does not know how compelling the argument was. It evaluates a predicate and returns a decision, the same decision every time for the same inputs.
This inverts the usual relationship. Instead of hoping the model internalizes your rules, you let the model be maximally capable — creative, aggressive, occasionally wrong — and make the boundary a property of the platform. The worst a misled model can produce is a proposal that the executor declines and records. Fail-closed means the declined action simply never happens; it does not queue, retry into existence, or degrade into a partial effect.
Rules as code
Because policies are evaluated by code, they read like code: explicit conditions over the plan, the entity, the clock, and the running totals the executor already tracks. Three families cover most operations we see in production:
Business hours are a clock comparison, not a behavioral norm. The executor evaluates the tenant’s local time; a message proposed at 02:00 is denied at 02:00, every time, regardless of how urgent the model believes it is. Spend ceilings compound naturally because the executor is the single chokepoint for effects: it already maintains the running total per entity and per day, so a ceiling is a comparison against state the platform holds, not state the model reports. Protected entities route around autonomy entirely — any action touching a tagged entity requires a human approval recorded in the receipt, or it does not dispose.
What determinism buys you
- Testability. A policy is a function. You can unit-test it against a corpus of plans before it ever guards production, and rerun the suite when you change it. Try that with a paragraph in a prompt.
- Uniformity as a design goal. Policies attach to capabilities beneath the connector layer, so a validated spend ceiling can govern the same supported effect across commissioned connectors. Each vendor swap still requires capability mapping and deployment verification.
- Evidence. Every denial produces a receipt: the plan, the rule that fired, the values it saw. When someone asks why an action did or did not happen, the answer is a record, not a reconstruction.
The same policy interface is the goal when the far end is hardware. The Smart City Labs hotel example is an illustrative managed-pilot pattern, not evidence of live BACnet actuation. A real deployment must verify controller semantics, commissioning boundaries, human approval, and independent life-safety controls.
Prompts still matter, just not for safety
None of this means the prompt is useless. Telling the model about your rules makes it propose better plans and waste fewer cycles on actions that will be denied. But that is an efficiency measure, not a safety one. The load-bearing constraint lives in the executor, where it cannot be crowded out of context, reframed as an exception, or shifted by a model update. Write your rules where the model can read them. Enforce them where it can’t argue.
Keep reading: Fail closed · Cost ceilings