Identity does not grant permission. Policy does.
Knowing who someone is settles one question. Policy settles what they may do, where, and when — and it is the part that has to be readable by the people accountable for it.
Policy should be as easy to write as it is to say
Administrators state the rule in plain language, see the boundary it resolves to, and confirm before anything is enforced. Nothing takes effect by accident.
The authoring sequence
The assistant taking a rule stated in plain language.
The resolved boundary, not yet saved.
The confirmation step before a policy goes live.
Live policy evaluation — pass, fail, defer.
Templates and console
Common policies start from templates; the administrative console is where they are versioned, reviewed and retired.
Policy Templates
Reusable policy definitions. Creating and retiring them requires the policy-admin role.
| Name | Conditions | Ver |
|---|---|---|
| Secure-area geofenceRamp and secure-area access must occur within the facility geofence. | REQUIRE_GEO | v1 |
| Secure-area radiusAccess within a radius of a facility point. | WITHIN_RADIUS | v1 |
| Duty windowAccess only during the operator's scheduled duty hours, in local time. | TEMPORAL_WINDOW | v1 |
| Prerequisite training + MFA tierAccess requires completed training — a prior event — and an MFA-tier role. | REQUIRE_ROLEREQUIRE_SEQUENCE | v1 |
Write the rule. Prove it held.
Every policy that runs produces decisions you can retrieve later.
What a decision looks like