Documentation Index
Fetch the complete documentation index at: https://www.osohq.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
Polar uses explicitly typed data. When you open a Polar policy, two main type categories are available:
| Class | Description |
|---|
| Primitive | Literal values such as strings, integers, and booleans. |
| Abstract | High-level types for modeling your application, such as users and resources. |
Primitive Types
Polar supports the following primitive types:
| Type | Description | Example |
|---|
String | Text value | "a" |
Integer | 64-bit signed integer | -3 |
Boolean | True or false values | true |
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:
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:
| Type | Description |
|---|
Resource | Something you protect (e.g. Repository, Document). Defined with resource. |
Actor | Something you grant access to (e.g. User, ServiceAccount). Defined with actor. |
Polymorphism
Abstract types enable polymorphism in policies.
Among built-in types:
| Supertype | Subtype |
|---|
Resource | Actor |
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
