Design decisions
Why zynactra/access is built the way it is. Read these before changing how it works.
Each record states the context, the decision and its consequences. A change that reverses one gets a new record that supersedes it.
| Decision | Status | |
|---|---|---|
| 1 | Cerbos evaluates generated policies; grants travel as principal attributes | accepted |
| 2 | Permissions never live in tokens | accepted |
| 3 | resource:action keys; scope lives on the assignment | accepted |
| 4 | Go and TypeScript share contracts, not bindings | accepted |
| 5 | Our own plan-to-SQL translator, identical in Go and TS | accepted |
| 6 | Storage in the product's Postgres, access schema, NOTIFY for invalidation | accepted |
| 7 | No escalation; access.delegation:any for administrators | accepted |
| 8 | Both SDKs call Cerbos over its HTTP JSON API | accepted (deviation from the first spec, which proposed gRPC for Go) |
| 9 | Route guards plus strict requirement tracking | accepted |
| 10 | Deviations from the architecture spec | accepted |
| 11 | Org rules, decision logs and policy outputs | accepted |