FERZ is not a Policy Engine

A policy engine is a general-purpose policy decision point: a caller submits a query, the engine evaluates it against encoded rules, and returns a decision. The architecture is domain-agnostic; the customer brings the action model, the input format, the state schema, and the policy semantics. FERZ is an AI-action governance architecture with built-in canonicalization, governed state, and verdict semantics specific to AI execution governance. The scope difference is structural: a policy engine is a component; FERZ is the architecture in which such a component may be embedded.

The authority source differs accordingly. A policy engine accepts whatever input the caller provides. If the caller submits unstable or non-canonicalized inputs, the decision is also unstable: equivalent actions may produce different decisions if represented differently in the input. FERZ canonicalizes the action specification into a stable representation, then evaluates it against governing policy and a governed state that includes policy version, evaluator version, canonicalization spec version, and context. Two evaluations with identical canonicalized inputs and identical governed state produce identical verdicts.

The evidence artifact differs structurally. A policy engine returns an allow/deny result and typically a decision log. The format and reconstructability properties of the log vary by implementation; some engines produce structured decision evidence, others produce only the result. FERZ produces a verdict with an authorization artifact: each verdict is reconstructable from policy, action specification, and governed state, with evidence sufficient for independent third-party verification. The artifact is part of the FERZ architecture, not an implementation detail.

Rule sourcing also differs structurally. A policy engine assumes the caller has authored encoded rules and brings them to the engine for evaluation; the rule-sourcing step is upstream of the engine and outside its scope. FERZ takes that upstream step as part of the architecture: an integrated codification methodology translates articulated constraints into runtime-enforceable encoded policy, then the runtime evaluates them deterministically. The codification methodology is not a content library of pre-written rules; it is a structured translation discipline that produces enforceable policy from the constraints an enterprise can articulate. The gap between articulated constraint and enforceable rule is closed inside the architecture, not delegated to the customer.

The structural claim follows. A policy engine can be a useful component within an AI-action governance architecture; it does not by itself constitute one. The properties that distinguish AI-action authorization (built-in canonicalization, governed state model, ABSTAIN-with-override semantics, authorization artifact, fail-closed by design, integrated codification methodology) are architectural commitments, not policies the customer can add to a general-purpose engine. No quantity of additional rules in a policy engine produces these properties; they are upstream of policy.

Traditional rule engines are designed for propositional logic or first-order logic over structured data. Decision tables, pattern matching, and Datalog-style evaluation cover this domain effectively. Constraints that cannot be expressed in those primitives are out of scope; they remain as natural-language policy documents that a runtime cannot evaluate. The gap between articulated constraint and enforceable rule is delegated to the customer, who must either restrict the constraints to what the rule language can express or accept that the rest go unenforced.

FERZ codification closes that gap as part of the architecture. The methodology is the upstream complement to the runtime evaluation, canonicalization, and authorization artifact properties documented in the rest of this comparison. The result is that constraints an enterprise can articulate across a broad range of complexity and direction can be translated into runtime-enforceable encoded policy and evaluated deterministically. This is not a property a policy engine or a traditional rule engine can be configured to provide; it is upstream of evaluation and a different architectural commitment.