Platform
Coco and policy engines
OPA and Cedar are good at evaluating rules against inputs you hand them.
If you already know the vendor’s current bank details, the PO status and the settlement history for this invoice, writing a rule against those values is straightforward.
Knowing them at the moment of action is the problem.
Workflow state lives across systems, changes between the moment an agent reads a document and the moment it acts, and has no single owner. A policy engine assumes the inputs arrive correct and current. Producing inputs correct and current is the work.
The second difference is ownership.
A policy engine is a library your engineering team runs inside the application. Coco is an artifact a different team owns, versions and audits, so the entity granting permission is separate from the entity requesting it.
Teams already running OPA or Cedar keep using them. Coco solves the layer underneath.
| Timing | State used | Outcomes | Ownership | |
|---|---|---|---|---|
| Coco | At action | Live workflow state | AUTO-EXECUTE/ OBSERVE / ESCALATE / DENY | Risk & compliance team |
| Identity providers | At authentication | Identity & scopes | Token issued / denied | Platform / IAM team |
| Policy engines | At evaluation | Inputs handed in | ALLOW / DENY | Engineering team |
| API validation | At request | Request payload | 200 / 400 / 422 | API team |
