An authorization evaluator is not a policy control plane.
OPA and Cedar do one job: evaluate a decision from the inputs you hand them, statelessly and fast. If you have tried to build governance on top of one, you already know where it stops: everything that makes a decision safe to change, and possible to prove, you build yourself.
What OPA is
A graduated CNCF project with a large community and a mature language, used for authorization across Kubernetes and infrastructure. It stays in your cluster; we are the control plane for the decisions that need memory and a record.
What Swiftward does differently
OPA answers "given these facts, is this allowed." It does not remember. The moment your policy needs "is this the fifth transfer this hour" or "has this user's trust score dropped," you add a database next to OPA and take on keeping those counts correct under load. Swiftward is stateful by design: counters, rate limits, sliding windows, and cooldowns are built in, ACID, and safe to re-process.
What you build on top of OPA
Versioning, and rollback by naming the previous version. Shadow mode and A/B against live traffic. A record that shows a past decision on the version that was live. A dead-letter queue. Human review that survives a restart. An audit trail an auditor accepts. Each is a project on top of OPA. Together they are most of a year of work, and then you own them. Swiftward is that layer, built and maintained.