Introduction

The Policy system evaluates human-readable business rules against structured data. Instead of writing validation logic in code, you write policies in a natural-language DSL.

The Platform

1. APIs

The platform exposes two API surfaces:

• the Execution API accepts a rule (policy text) and data (JSON), evaluates the rule against the data, and returns a result
• the General API manages stored policies and flows

POST https://api.policy2.net/run
x-api-key: <your-api-key>
{
  "rule": "A **Person** gets approved if __age__ of **Person** is greater than 18.",
  "data": { "Person": { "age": 25 } }
}

For stored resources, the General API handles draft/version lifecycle, ownership, tenant visibility, groups, audit, and deletion rules.

For enterprise tenants, the platform uses dedicated database servers rather than placing multiple enterprise customers onto the same shared database server. See Enterprise Isolation for the current model.

Execution is ID-based:

• use /run/policy/{baseId} to run the latest version, or the draft if no version exists yet
• use /run/policy_version/{policyId} to run an exact policy record
• use /run/flow/{baseId} to run the latest version, or the draft if no version exists yet
• use /run/flow_version/{flowId} to run an exact flow record

Stored resources are governed by roles and ownership rules. Role checks are evaluated via the platform authorization policy in the policy engine. A never-published draft can remain user-owned, while published resources become organization-owned.

2. Dashboard

A web UI for creating and testing policies visually. It connects to the API under the hood.

3. SDKs

If you are integrating Policies into an application, use one of the official SDKs:

• Go: go-sdk
• Python: policies2 on PyPI
• TypeScript: @policies2/sdk
• Rust: policies on crates.io

The full install matrix is on the SDKs page.

Why Use Policy DSL?

• Business rules change frequently — update a policy without redeploying code
• Stakeholder transparency — non-developers can read and verify the rules
• Audit trail — stored resources can be versioned, audited, and reviewed over time
• Separation of concerns — logic lives outside your application code
• Testable — every rule can be tested independently with sample data

How Rules Work

A policy rule has this structure:

A/An/The **Selector** outcome
if condition
[and/or condition]...
.

• Selector — the JSON object being evaluated (e.g., **Person**)
• Outcome — what happens if all conditions pass (e.g., gets approved)
• Conditions — checks against properties of the data
• Period — every rule ends with .

The platform walks each condition, evaluates it against the data, and returns true (pass) or false (fail).