@WsdlGuard("EnforceOMatic.orgCanUsePolicyRuleMDAPI")

OrgPermissions.EnforceOMatic && OrgPermissions.PolicyRuleMDAPI

PolicyJsonExpression

For human maintainers (not the agent): the Java source-of-truth lives at

enforce-o-matic-impl/java/src/enforce/o/matic/metadata/

and reference fixtures at

enforce-o-matic-impl/test/func/filemetadata/<name>/

. The agent should rely on the templates and reference docs in this skill bundle — those impl paths are not readable from the Vibes/MCP runtime.

*.policyRuleDefinition

*.policyRuleDefinitionSet

test/func/filemetadata/

Eval coverage: This skill is exercised by the team's ADK eval framework, not by

tests/evals/

under the skill directory. Five datasets covering the ACCESS / GOVERNANCE / RECORD / TRANSFORM variants live in

packages/adk-eval/eval/domains/platform-policy-rule-generate/datasets/

.

enforce-o-matic-api/java/src/enforce/o/matic/api/module/api/RuleBuilder.java

• effect=Transform

  ⇔

  category=TRANSFORM_POLICY_RULE_DEFINITION

  (bidirectional; mismatched throws

  INVALIDFORCATEGORY

  ).
• All other categories (

  ACCESS

  ,

  GOVERNANCE

  ,

  RECORD

  ,

  IDENTIFIED_RECORD

  ) accept either

  Permit

  or

  Forbid

  .

Note on the platform's auto-fill default: When

<category>

is omitted from authored XML, the impl-side save hook (

PolicyRuleDefinitionObject.saveHook_Validate

) fills it in from

effect

:

Permit→ACCESS

,

Forbid→GOVERNANCE

,

Transform→TRANSFORM

. This is a default-fill, not a validation. If you author an explicit category that contradicts this default, it is accepted and persisted as-is.

ACCESS_POLICY_RULE_DEFINITION

GOVERNANCE_POLICY_RULE_DEFINITION

ACCESS

GOVERNANCE

Important — honor the explicit category in the prompt. If the prompt says "ACCESS policy rule that denies …" or "GOVERNANCE policy rule that permits …", emit exactly that category. Do not silently swap to the auto-fill default just because effect is Forbid (or Permit). The platform accepts both. The agent must not override the user's stated intent.

INVALIDFORCATEGORY

ACCESS

GOVERNANCE

TRANSFORM

RECORD

ANY

DATASPACE

FIELD

RECORD

SPAN

1. Every

   <conditions>

   needs an

   <operator>

   . Missing operator → reject.
2. Every

   <conditions>

   needs at least one path element (

   <resourcePath>

   ,

   <principalPath>

   ,

   <contextPath>

   , or

   <valueDomain>

   ).

3. <contextPath>

   is exclusively

   SESSION_DATASPACE

   . Never put a resource path value there.
4. Scope × category must be in the §4 matrix. Common offenders: ACCESS/GOVERNANCE + RECORD scope; RECORD + ANY/FIELD scope; TRANSFORM + ANY/RECORD scope. (Effect is independent of category except for TRANSFORM — see §4.)

5. <resourceTransform>

   and

   effect=Transform

   are coupled. Transform effect needs a resourceTransform. Permit/Forbid must not have one.

6. <policyRuleResourceDomains>

   is required for RECORD (RLS) and FIELD-scope TRANSFORM; forbidden on ACCESS/GOVERNANCE.

7. <conjunctionExpression>

   indices must match actual

   <conditions>

   count. Off-by-one → reject.

8. <clause>

   inside

   <conditions>

   must match the wrapper (

   WHEN

   inside

   <when…>

   ,

   UNLESS

   inside

   <unless…>

   ).
9. JSON literals in

   <valueString>

   must escape

   "

   to

   "

   . Wrong escaping silently corrupts the literal.
10. Reference targets (

    <valueReference>

    ,

    <resourceDomain>

    ) must exist in the target org at deploy time.

11. SCALAR_ATTRIBUTE

    /

    PLURAL_ATTRIBUTE

    are not in

    RulePrincipalPathType

    — not in MDAPI contract. Use a runtime RuleProvider for those shapes.

12. IDENTIFIED_RECORD

    is not authorable via MDAPI —

    SESSION_CONSUMER_ID

    not in

    RuleContextPathType

    .
13. Standard tag/classification dev names are fully-qualified dotted paths (e.g.

    DataGovernanceTags.ExternalData.Visibility.Public

    ). Retrieve an existing rule to get the exact string before authoring.
14. Min API versions:

    PolicyRuleDefinition

    = 64.0;

    PolicyJsonExpression

    conditions = 66.0;

    <replicated>

    = 260+;

    <builderCompatible>

    /

    <builderValidated>

    = 262+.

Note on

<conjunctionExpression>

shape: A bare top-level index (e.g.

<conjunctionExpression>1</conjunctionExpression>

) deploys cleanly — the impl-side parser accepts bare tokens at the top level, and most positive single-condition fixtures in

enforce-o-matic-impl/test/func/filemetadata/

use it. It is not a deploy-time validation error. It does, however, crash the Data Governance Policy Builder UI on load — see §7.

• Missing OR-of-ENTITYTYPE clause on ACCESS/GOVERNANCE rules → hard crash:

  Cannot use 'in' operator to search for 'Permit' in undefined

  . Required even when paired with

  TupleRead

  (where it's functionally redundant at runtime). Must include

  IS

  conditions for

  {"t":"Text","v":"OBJECT"}

  and

  {"t":"Text","v":"FIELD"}

  .
• Bare top-level condition index in

  <conjunctionExpression>

  (e.g.

  1

  , or

  (AND (OR 1 2) 3)

  ) → crash on builder load in

  buildCriteria

  . Deploy is unaffected, but the policy is uneditable in the UI. Always wrap:

  (AND 1)

  for a single condition;

  (AND (OR 1 2) (AND 3))

  instead of

  (AND (OR 1 2) 3)

  .

• category = ACCESS_POLICY_RULE_DEFINITION

  +

  effect = Forbid

  → the Data Governance Policy Builder UI (not MDAPI) collapses it to GOVERNANCE on save; round-trip via the builder will rewrite the category. MDAPI deploy is unaffected — the original ACCESS+Forbid combination is valid and deploys without modification. If your goal is UI round-trippability, prefer GOVERNANCE for Forbid; if the source of truth is MDAPI, ACCESS+Forbid is fine.
• Any

  <unlessPolicyRuleDefinitionClauseConjunction>

  block → silently dropped on first UI save.
• More than one

  <action>

  → only the first is kept.

• ruleConsumer

  ≠

  DATACLOUD

  → UI hardcodes DATACLOUD on save.
• Top-level

  (OR 1 2)

  conjunction → triggers

  // ERROR: Unsupported rule!

  path, rule silently dropped.

unless principal has permission X

WHEN ASSIGNED_PERMISSIONS_PATH CONTAINS_NONE X

unless resource has tag X

WHEN TAG CONTAINS_NONE X

unless record field = value

WHEN RECORDFIELD NOT_EQUALS value

references/ui-compatibility.md

1. Start from the closest template in

   references/templates.md

   — modify from there, don't start blank.
2. Pick category first (§4). Category fixes effect, resourceScopeType, and whether policyRuleResourceDomains/resourceTransform are required.
3. Lay out the bare rule: top-level fields only, no conditions. Match the category template in

   references/templates.md

   .
4. Add conditions one at a time, each with all four anchors:

   <clause>

   ,

   <operator>

   , one path element, and the value.
5. Update

   <conjunctionExpression>

   — 1-indexed prefix notation. Bare top-level index (e.g.

   1

   ) deploys but breaks the UI; wrap as

   (AND 1)

   if UI editability matters (§7).
6. Run the UI-compatibility check (§7 /

   references/ui-compatibility.md

   ). If any item trips, attempt the "unless" rewrite first; if not possible, get explicit operator confirmation before continuing.
7. Update

   package.xml

   — list each

   <members>

   for both types.
8. Set

   <builderCompatible>

   on the set to

   true

   if §7 checklist passes;

   false

   if intentionally API-only.
9. Sanity-check against §6 (guardrails) before considering done.
10. Validate with dry-run before any non-dry deploy to a persistent org. Surface errors using the error reference in

    references/deploy-errors.md

    .

• Runtime / Cedar — does the rule enforce what's intended? (action choice, condition shape)
• MDAPI deploy validity — does it deploy? (§6 guardrails, scope×category, tag dev names, org perms)
• UI editability — can the builder render and re-save it? (§7 checklist, OR-of-ENTITYTYPE requirement)