Policies and rules

The model

Account and organization levels

Both rules and policies exist at two levels. Account objects apply to every organization in the account; organization objects apply to one.

At evaluation time the two are merged, and the account side wins where they overlap:

• An account rule that fully covers an organization rule's scope suppresses it. The check still happens — once, under the account rule.
• An account rule that covers part of it narrows the organization rule to the scopes the account did not claim.
• An organization rule cannot downgrade an account block to warn. A laxer local policy quietly weakening a deliberate one is the thing this hierarchy exists to prevent.

The CLI receives the merged, deduplicated result. A product reached by the same rule through two routes — an organization-wide policy and one assigned to it directly — is measured once, not twice.

Targeting environments

Every policy names the environments it applies to. A production deployment can be gated harder than a development sandbox without maintaining two copies of every rule.

Policy: Production controls
  environments: [production]
  rules:
    - Budget exceeding            block
    - Max cost increase ($)       block
    - Required tag: cost_center   block

Policy: Everyday hygiene
  environments: [development, staging, production]
  rules:
    - Naming convention           warn
    - Required compute policy     warn

The environment comes from the --targetthe CLI ran with, mapped through your organization's environment settings. When finowl guard asks for rules, it asks for this product in this environment, and receives only what applies.

Severity

Introduce rules as warn. A rule that fires on twenty existing products the day it is created will be switched off within a week, and the lesson everyone takes is that the gate is noise.

Rules Finowl manages

Two attribution rules are created with every organization and cannot be edited or turned off. They require the product identity tag on compute, and every actual-cost figure on a product page is traced through them.

An organization able to weaken them would be switching off its own reporting — the product page would show a total attributed from a fraction of the spend, with nothing to indicate it. See Actual cost.

Putting a rule in force

1. Create the rule under Rules. Pick the type, fill its parameters, choose a scope where the type takes one, and set the severity.
2. Add it to a policy. Until this happens it is marked Never runs.
3. Target the policy's environments. A policy targeting no environment matches no run.
4. Assign the policy — organization-wide, or to specific products.
5. The next pipeline run picks it up. Nothing is redeployed and no workflow file changes.

Two families

Cost rulesmeasure money: a ceiling drawn from the product's own budget, and limits on how much any one change may add.

Governance rules measure the shape of the deployment: required tags, naming conventions, compute policies, and, where an organization uses them for its own grouping, serverless usage policies.

Why the CLI holds no policy file

Rules are fetched at run time, per product and per environment. A rule tightened this morning applies to this afternoon's pipeline, in every repository, with nothing to redeploy — and no repository can hold a stale copy of a control that was changed for a reason.