One rule, as code and as a card.

What a Policy Card is

A Policy Card writes one governance rule as a machine-readable artefact that travels with the system it governs: its effect, the failure mode it addresses, where it is enforced, the obligations it maps to and the engine module that implements it [1][2]. The same card is evaluated in the pipeline and, where the rule is a runtime constraint, at the point of action, and every evaluation leaves a verdict: rule id, decision, input hash and timestamp [1]. The machine version validates against the policy card schema [3]; the obligation ids are the stable ids of the register [4].

The six rule templates

Each template states the rule with its default parameters, the effect, where it is enforced, the failure mode it starts from, the obligations it helps evidence by default and the pattern it builds. Without JavaScript, use this list and the fields above as a worksheet.

Write your own rule takes one condition on one field of the input (is missing, equals, does not equal, is below, is above, is one of, is not one of), for one action, with any of the four effects. Comparison operators never match a missing field; use "is missing" to catch one.

What you get

• The card, three ways. Markdown for the people who approve it; YAML and JSON for machines, checked in this browser against policy-card.v1.json [3]. The executable module is authoritative over the prose.
• An OPA/Rego module. Rego v1 syntax, which OPA 1.x requires (if on every rule with a body, contains for multi-value rules) [7], with the rule's parameters at the top, a decision, a blocks rule the CI hook fails on and the verdict the pattern asks for.
• Its unit tests. opa test runs every rule prefixed with test_ and mocks the input with with; a test that is undefined or not true fails [6]. The generated cases cover a compliant input, each way the rule fails and an input the rule does not govern.
• A Cedar stub and its tests. For teams that authorise with Cedar: a forbid (or, for the allow effect, a permit) with the rule id in an @id annotation, and cases for cedar run-tests [9][13].
• An example input and the CI hook. A compliant input document, and a GitHub Actions workflow that checks and tests the module, records the verdict as a build artefact and fails the job on a deny [5][11][14][15].

Use it in a repository

1. Commit the card and the modules under policies/, next to the system they govern, and review every change as a diff.
2. Run opa check --strict and opa test on the module and its tests [5][6], then add the cases your own inputs need.
3. Write the step that builds the input (from the registry, the eval store or the change itself) and wire the workflow: opa eval --fail-defined on the blocks rule fails the job when the decision is deny [5].
4. For runtime rules, have the gateway or guardrail ask OPA for the verdict on every call, for example with POST /v1/data/aige/cards/<package>/verdict and the request as input [8], and act on its decision.
5. Sign each verdict and write it to the evidence store, as the AI policy template's module does [3]: the verdict left by every evaluation is the evidence the pattern produces [1].

Rego and Cedar read the same rule differently

OPA/Rego computes any decision you name, so the module returns deny, require_approval or alert as the card says. Cedar returns permit or deny only: it denies by default, a matching forbid overrides every permit, and annotations do not change evaluation [9][10]. The stub therefore carries an @effect annotation the caller reads to route a deny, and a baseline permit so the card can be tested on its own; drop that baseline in a real policy set. Cedar also skips a policy whose evaluation errors [10], so a wrongly typed request can slip past a forbid: validate requests against a Cedar schema before you rely on it.

Samples, checked

The default card of every template is published under /templates/policy-cards/, generated by the same code as this page. On 2026-09-24 every sample passed opa check --strict and opa test with OPA 1.21.0, and cedar run-tests with cedar-policy-cli 4.13.0 [12][13]. What you generate with other values is not checked here: run the same commands before you use it.

Where this sits

The builder is layer 1 of the stack, Govern-as-Code: it turns a policy clause into a control that can fail a build or hold an action, which is what governance-as-code means and what the narrower policy-as-code does in CI/CD. In the IAPP's AIGP Body of Knowledge (version 2.1) it supports competency I.C, creating and implementing policies across the AI life cycle, and IV.C, applying those policies when an AI system is deployed and used [16]. This site is not affiliated with or endorsed by IAPP.

What this is not

The generated files are illustrative starting points, not finished controls: review them before use. The obligation mappings are illustrative, not a claim of conformity, and a rule that runs is evidence toward an obligation, not proof that it is met. Nothing you enter leaves your browser: there is no upload and no account, and the state lives only in the link you copy.