Why OPA/Cedar Policies Matter in Software Factories

A software factory's gate engine is where governance lives. Today, that governance is written in Python. It works, it is tested, and it is correct. But Python is not the right language for policy, not in the long term. The right language is a declarative policy language like Rego (Open Policy Agent) or Cedar (AWS). This is about why the migration matters and what it unlocks.

The Problem With Policy in Python

The gate engine today runs two gates: spec_gate and risk_tier_gate. Both are plain Python functions. They check schema, envelope, policy, tier max-rule, oracle-strength floor, and risk-band routing. The Python is correct, it has passing tests, and it encodes the governance guarantees. But Python is a general-purpose language. It can do anything. Policy should not be able to do anything. Policy should be declarative, auditable, and swappable.

When a new regulation lands, like the EU AI Act or a PCI compliance update, you want to ship a new policy bundle, not edit the factory's core code. Every edit to the gate engine is a risk. Every new Python branch is a new code path that needs testing. Declarative policy languages solve this by separating what you want from how it gets evaluated.

What OPA and Cedar Do

Open Policy Agent uses Rego, a declarative query language built for policy evaluation. AWS Cedar is a similar approach from the AWS side. Both take structured data as input and return a decision. The gate engine sends them the verdict, the touched paths, and the governance config. They return advance, route_human, or reject. The factory does not care which engine is behind the curtain. The PolicyEngine protocol in the gate engine is a single method: evaluate(gate, payload) -> GateDecision.

The factory already has the data it needs. Governance YAML files define tiers, mutation floors, and owners. Policy pack YAML files define required evidence, attestation rules, and retention. These are already pure data bundles. The missing piece is the policy engine that evaluates them, and that is exactly what D-008 on the decisions register is waiting for.

Reference Semantics and Test Fidelity

The Python gate functions are not throwaway code. They are the reference semantics. Whatever Rego or Cedar policy you write must produce the identical GateDecision for every case in tests/test_gate_engine.py. Those tests encode the governance contract. If the Rego output differs, the test fails. The migration is not done when the new engine runs. It is done when the new engine passes every existing test unchanged. The Python stays in the tree as the human-readable reference that policy authors consult when debugging a Rego rule.

The Migration Path

The plan is incremental. Translate risk_tier_gate into Rego first, since it is the more complex of the two gates with tier max-rule, oracle-strength floor, and risk-band routing. Turn the YAML configs into the actual data OPA/Cedar evaluates. Implement a real adapter behind the PolicyEngine protocol, wired into GateEngine as an optional constructor argument. Run the existing test suite against it. Then swap the default from Python to OPA.

This is not a rewrite. It is a careful, test-gated replacement of one evaluation engine with another. The architecture was designed for this moment. The protocol was stubbed. The data was separated from the logic. The tests were written. The only thing missing is the implementation.

Why It Matters

Declarative policy makes regulation a config change. A new compliance regime means a new policy pack, not a new deployment of the factory. The gate engine stays stable. The tests stay passing. The policy authors write Rego, not Python. And when the next regulation lands, a year from now or five years from now, the factory adapts without ship downtime or core changes. That is the whole point of putting policy in its own language.