Console Authoring
Decision tester, rule editor, live audit trail and history.
intent in natural language, one schema-valid rule
Authorization
Authorization, implemented in your estate
Quince Software implements authorization on open standards: one decision point every application can ask, with the rules held as data in Git and every decision naming the rule that produced it.
Caroline, the demonstration deployment, runs this design with real policies behind it and is available to walk through.
How it fits together
Where the data goes
AuthZEN is the contract at the edge: an application asks its question in a standard shape and gets an answer in the same standard shape, so whatever sits behind it can change without the application changing with it.
Wider than the screen. Scroll the diagram sideways to follow it.
Reference architecture · data flow
AuthZEN 1.0 is the contract at the edge
Decision point
Git Record
The record of what changed, and when.
policy change committed
Policy information point Attributes
One front to whichever systems own the attributes.
attribute changed
OPAL Live sync
Distributes policy and attributes as they change.
policy 0.27 s, attributes 0.06 s
Scope gate Admission
Rejects unauthorised callers before the engine runs.
caller accepted
Open Policy Agent PDP
A generic evaluator over rules held as data.
decision under 5 ms, naming the rule
Application Enforcement
Asks the question in a standard shape, enforces the answer.
AuthZEN 1.0 response
Policy authoring
Write the rule in plain English.
a nurse may read a patient record only while assigned to that patient's care team
The demonstration
Meet Caroline
Caroline is the demonstration deployment: this design, running, with real policies behind it. It is what the measured figures below come from, and what a walk-through shows you. It is not a product on a price list; what you buy is the implementation in your own estate.
Proof
Already running in production
The engagement ran from 2024 and the design went live in 2026 at a European central banking institution, where 300+ applications and ~50,000 users moved from role-based to attribute-based access control.
| Measure | Result |
|---|---|
| Policy save to enforced decision | 0.27 s, with the change recorded in Git |
| Attribute change to effect | 0.06 s, straight from the source system |
| Decision latency | Under 5 ms |
| Decision explanation | Every decision returns the rule that produced it |
These figures are measured on Caroline, the demonstration deployment.
The engagement
Three steps, each ending in something running
-
Step one
Pilot
A decision point runs against one of your own use cases, with your real policies, on a bounded scope. You judge the design on working software before committing to a rollout.
You end up with. A running decision point answering your use case, with the policies that produced each answer.
-
Step two
Production deployment
Rollout across the application estate, with the governance around policy change, the playbooks for onboarding each application, and the handover to whoever will operate it.
You end up with. Authorization in production across the estate, onboarding playbooks, and an operations handover to your team.
-
Step three
Retainer
Ongoing policy governance, onboarding of further applications as they arrive, and operation of the decision points themselves.
You end up with. Continuing governance of the policy estate and operation of the decision points, against an agreed scope.
See Caroline decide
Ask for a walk-through and you will see a policy change enforced while you watch, with the change already committed.