Policy Authoring

Iron Gorilla policies use a typed rule model for guided authoring, simulation, and AI-assisted drafting. Rules are structured around selectors, condition trees, explicit effects, and catalog-backed action metadata.

The Mental Model

Each action rule answers one question:

1. What action does this rule apply to?
2. Under what conditions does it match?
3. What effect should it produce?

That maps directly to:

• selector
• when
• effect

The rule also has a required name and an optional description.

Rule Anatomy

{
  "id": "rule_high_value_payment",
  "name": "Require approval for large payments",
  "description": "Pause payment calls over the review threshold.",
  "effect": "require_approval",
  "selector": {
    "kind": "action",
    "family": "tool.invoke",
    "match": "resource",
    "resourceId": "payments.charge"
  },
  "when": {
    "kind": "group",
    "op": "and",
    "children": [
      {
        "kind": "predicate",
        "left": { "source": "current_action", "field": "input.amount" },
        "operator": ">=",
        "right": { "source": "literal", "value": 10000 }
      }
    ]
  }
}

Effects

Rules can produce three effects:

• allow
• deny
• require_approval

If multiple rules match, precedence is:

1. deny
2. require_approval
3. allow

If nothing matches, the governance profile decides the default behavior.

Selectors

Selectors are structured objects, not typed strings.

Supported families:

• tool.invoke
• llm.call
• data.read
• data.write
• agent.delegate
• now
• random
• uuid
• step.start
• step.end

Supported match modes:

• all
• resource
• group

The valid resources and groups come from GET /policies/catalog. Clients use catalog-provided selector ids rather than deriving ids from labels or user input.

Conditions

The when tree supports:

• nested and groups
• nested or groups
• typed predicates

Predicates compare operands from these sources:

• literal
• current_action
• governance_context
• history_ref

Cross-Action References

history_ref is how a rule can depend on prior actions in the same job.

It supports only two modes:

• exists: did a prior matching action happen?
• latest: read one normalized field from the latest matching prior action

Cross-action references are bounded:

• only prior completed or replayed actions are considered
• only normalized action facts are exposed
• arbitrary result-body inspection is not supported

Catalog-Driven Authoring

The catalog endpoint gives the editor the metadata it needs to stay valid:

• action families
• resources
• groups
• fields
• field-specific operators
• governance fields
• starter templates

The UI can present domain-specific choices like “Tools” or “Providers” and restrict available options to the selected scope.

Simulation

POST /policies/simulate evaluates draft rules against a typed frame:

• currentAction
• governanceContext
• history

The response includes rule traces that explain the final decision and show why each relevant rule matched or failed.

Assist

POST /policies/assist uses the same catalog and rule grammar as the manual editor. Generated drafts stay within the available tools, fields, operators, and supported constructs.

This keeps human-authored rules and AI-authored rules on the same backend-owned contract.