Policy authoring basics

This page is a practical reference for writing policy rules in environment YAML files.

Rule anatomy

A policy rule typically includes:

• id
• optional description
• optional stage
• optional target
• if (condition list)
• then (action list)

Example: control enforcement from scope

rules:
  - id: API_SERVICE_CONTINUITY_SCOPE
    description: In-scope service continuity requires traffic filtering
    stage: init
    target: component
    if:
      - eq: { key: type, value: api }
      - eq: { key: serviceContinuity, value: inScope }
    then:
      - expect: { entity: component, control: trafficFiltering }

Common condition patterns

• equality checks (eq)
• inclusion checks (in, not_in)
• presence checks (present)
• topology-aware checks (upstream, downstream, connected variants)

Use only the minimal condition set needed to express intent.

Common action patterns

• expect / control addition patterns
• set for derived values
• scoring (score, map_score, mapped scoring)
• specification / map_specification
• icon actions where visual signaling is needed

Stage guidance

• init/pre: derive baseline controls/values
• default/post: apply main scoring/spec outputs
• final: final adjustments only

Naming conventions

Prefer:

• ENTITY_SCOPE_NAME_SCOPE
• clear functional suffixes for score/spec rules where needed

Examples:

• WEB_APPLICATION_SERVICE_CONTINUITY_SCOPE
• CONNECTED_SERVICE_CONTINUITY_SCOPE
• CONNECTION_SERVICE_CONTINUITY_SCOPE

Quality bar before merge

• Rule intent is one-line explainable.
• YAML is parse-valid.
• Rule triggers exactly when expected.
• Rule does not trigger when condition is not met.
• No accidental behavior change in unrelated environments.