Policies

Policies turn evidence gaps into decisions.

A policy should say what evidence is required, where it applies, whether it is shadow/advisory/enforce, and what action an operator should take when it fires.

Example policy shape.

policy.yaml

name: production-runtime-readiness
description: Require identity, runtime health, rollback evidence, and GitOps readiness before production promotion.
mode: shadow
appliesTo:
  environments: ["production"]
  services: ["checkout-api"]
requires:
  - release.sourceSha
  - artifact.digest
  - kubernetes.rollout.ready
  - prometheus.errorRate.withinBudget
  - gitops.application.healthy
  - rollback.available
decision:
  missingEvidence: HOLD
  failedEvidence: BLOCK
operatorAction:
  hold: "Wait for connector freshness or attach approved evidence."
  block: "Stop promotion and fix runtime or rollback condition."

Policy fields

Fieldname

MeaningStable policy identifier.

Operational guidanceUse names operators understand, such as production-runtime-readiness.

Fieldmode

Meaningshadow, advisory, or enforce.

Operational guidanceStart shadow; move only after evidence is trustworthy.

FieldappliesTo

MeaningService, environment, namespace, criticality, or owner scope.

Operational guidanceKeep scope narrow so policies are explainable.

Fieldrequires

MeaningFacts that must exist and pass.

Operational guidancePrefer explicit evidence requirements over generic risk wording.

Fielddecision.missingEvidence

MeaningVerdict when evidence is absent or stale.

Operational guidanceHOLD is safer than ALLOW for missing production evidence.

Fielddecision.failedEvidence

MeaningVerdict when evidence exists and fails.

Operational guidanceBLOCK when runtime, rollback, or policy failure makes promotion unsafe.

FieldoperatorAction

MeaningWhat humans should do next.

Operational guidanceMake the console useful by telling operators where to look.

Field	Meaning	Operational guidance
name	Stable policy identifier.	Use names operators understand, such as production-runtime-readiness.
mode	shadow, advisory, or enforce.	Start shadow; move only after evidence is trustworthy.
appliesTo	Service, environment, namespace, criticality, or owner scope.	Keep scope narrow so policies are explainable.
requires	Facts that must exist and pass.	Prefer explicit evidence requirements over generic risk wording.
decision.missingEvidence	Verdict when evidence is absent or stale.	HOLD is safer than ALLOW for missing production evidence.
decision.failedEvidence	Verdict when evidence exists and fails.	BLOCK when runtime, rollback, or policy failure makes promotion unsafe.
operatorAction	What humans should do next.	Make the console useful by telling operators where to look.

Policy examples by use case

Immutable artifact

Require image digest and source SHA. Block mutable tags in production.

Runtime health

Require fresh p95/error-rate evidence below threshold before promotion.

Rollback readiness

Require previous good revision, database compatibility note, or rollback runbook evidence.

Namespace safety

Hold when the target namespace does not match the service registration.

Approval required

Require human approval for high-risk services, data migrations, or policy overrides.