Skip to main content
Polar uses explicitly typed data. When you open a Polar policy, two main type categories are available:
ClassDescription
PrimitiveLiteral values such as strings, integers, and booleans.
AbstractHigh-level types for modeling your application, such as users and resources.
This page covers built-in types only. Most of your policy will be written using custom types defined as resource blocks.

​
Primitive types

Polar supports the following primitive types:
TypeDescriptionExample
StringText value"a"
Integer64-bit signed integer-3
BooleanTrue or false valuestrue
You can use primitives directly in rules or facts: 
is_string_a(x: String) if x = "a";

​
Common uses of String

By convention, Polar represents permission names, role names, and relation names as String values.

​
Object literal representation

Primitives can also be expressed as object literals: 
Boolean{true}
This form has no semantic difference; it’s purely an alternate syntax.

​
Fact argument length limit

Each argument in a fact can be at most 384 bytes (not characters—multi-byte characters reduce the count).
Example within limits: has_relation(Foo{"<384-byte string>"}, "<384-byte-string>", Bar{"384-byte string>"}) Polar provides two abstract types for authorization modeling:
TypeDescription
ResourceSomething you protect (e.g. Repository, Document). Defined with resource.
ActorSomething you grant access to (e.g. User, ServiceAccount). Defined with actor.
Create your own types by extending these abstracts in resource blocks.

​
Polymorphism

Abstract types enable polymorphism in policies. Among built-in types:
SupertypeSubtype
ResourceActor
This means every Actor is also a Resource. See the extends documentation for details.

​
Object literal restriction

Do not represent abstract types as object literals. For example, avoid: Resource{"foo"} # Invalid