07 , FPL language

FPL — The Standard Policy Language

FPL (Faramesh Policy Language) is the standard and canonical policy language for Faramesh. Every policy is FPL. YAML and natural language are alternative input formats , they compile to FPL before the engine evaluates them. FPL is the source of truth.

Why FPL exists

Governing AI agents with YAML, OPA/Rego, or Cedar requires a senior engineer who understands authorization, schema design, and the agent framework's internals. That bottlenecks governance to a tiny pool of people. A compliance officer, a CISO, or a legal team member cannot write Rego or navigate a 200-line YAML policy.

FPL solves this by providing agent-native primitives as first-class language constructs , sessions, budgets, delegation chains, workflow phases, credential bindings, and mandatory deny , not as convention-over-configuration hacks layered on top of a general-purpose format. The result is a policy language that's shorter, safer, and readable by anyone who understands the business rules.

How FPL compares

Four input modes, one engine

FPL is canonical. The other three modes compile to FPL before evaluation.

The deny! invariant

deny! is a compile-time constraint. It is the most important construct in FPL. When you write deny! shell/*, no child policy, no priority rule, no extends chain, and no subsequent permit rule can override it. The compiler enforces this structurally , it is not a runtime convention or a documentation practice. OPA, Cedar, and YAML-based engines rely on documentation to express "this rule must never be overridden." FPL makes it a language guarantee.

Backtest before activation

Every policy compiled from natural language is backtested against real DPR (Decision-Provenance Record) history before the user sees it. Faramesh replays the new policy against past decisions and shows what would have changed: "23 of your last 847 decisions would have been deferred." The user sees the impact and decides whether to activate. This makes NLP compilation trustworthy rather than a black box.

Structured FPL example

A complete agent policy expressed in FPL. This single file defines the default stance, model constraints, budget tracking, phased rules, delegation limits, ambient credential stripping, selectors, and credential bindings.

agent support-bot {
  default deny
  model  gpt-4o
  framework langchain

  budget session {
    max_usd  5.00
    max_calls 200
  }

  phase intake {
    permit crm/lookup
    permit kb/search
  }

  phase execution {
    permit email/send
    defer  refund/issue when amount > 500
    permit refund/issue when amount <= 500
  }

  rules {
    deny shell/*
    deny fs/write
  }

  delegate {
    to finance-team scope refund/issue ceiling 2000
  }

  ambient {
    strip OPENAI_API_KEY
    strip STRIPE_API_KEY
  }

  selector {
    tag pii effect defer
  }

  credential {
    backend vault
    path    secret/data/support
  }
}

NLP compilation

Write policy in plain English and compile it to FPL. The NLP compiler maps natural language constraints to structured policy blocks.

faramesh policy compile \
  "deny all shell commands, defer refunds over $500 to finance"

YAML decompilation

Convert an existing YAML policy back into FPL for easier editing.

faramesh policy fpl decompile policy.yaml

GitOps workflow

FPL files are plain text and designed for version control. Commit them alongside your application code. Validate in CI before deploy. Diff policy changes in pull requests the same way you diff code.

# CI pipeline step — validate before merge
faramesh policy validate agent.fpl

# Backtest against production history
faramesh policy backtest agent.fpl \
  --db /var/lib/faramesh/faramesh.db

# Diff two policy versions
faramesh policy diff agent-v1.fpl agent-v2.fpl

FPL block reference

Every construct available in FPL, with its purpose.