Skip to content

PATTERN Cited by 1 source

Logging mode → enforcement mode rollout

Pattern

When rolling out a correctness-constraint enforcement system (e.g. IFC, an egress firewall, a validation layer), first deploy in logging mode — detect and record violations without blocking — then remediate the surfaced violations, then flip to enforcement mode where the same system blocks violations as a hard stop.

This is a two-phase rollout on the enforcement-severity axis, not on the traffic axis. Traffic is unchanged. Only the decision "violation → block or record" flips at the end.

Why

Constraint systems find violations at runtime that code review / testing would not have surfaced. Flipping straight to enforcement would break production for all those unknown violations. Logging mode makes the surface visible and gives operators a remediation window with zero user-facing impact.

Mechanism

  1. Deploy the enforcement system (for Meta PAI: annotate sources and sinks, stand up the zone).
  2. Logging mode: the system detects every violation and records it — no blocking.
  3. Remediate: operators close violations one by one (Meta's three remediation cases: annotate sink / block flow / mark as reclassified). For each violation the decision may require engineering work; PZM is Meta's UX for this.
  4. Flip to enforcement mode: once all violations are remediated, the zone flips. From that point forward, any new violation is blocked automatically — even for code changes that introduce new violating flows.

Quote from the 2024-08-31 Meta PAI post:

"During the initial rollout of a new requirement, Policy Zones can be configured to allow remediations of flow violations in 'logging mode.' Once Policy Zones enforcement is enabled, any data flow with unremediated violations is denied. This also prevents new data flow violations, even if code changes or new code is added."

Relationship to fail-open vs fail-closed

Logging mode is a form of fail-open (the violation is recorded but the request proceeds); enforcement mode is fail-closed (the violation breaks the request). The two-phase rollout is essentially "start fail-open while the policy is incomplete, flip to fail-closed once the policy is complete" — see concepts/fail-open-vs-fail-closed.

Variants on this wiki

  • Policy Zones (Meta) — the canonical privacy example.
  • Detection-in-depth → enforcement — security detection pipelines often follow the same shape (e.g. patterns/data-driven-allowlist-monitoring-mode).
  • Feature-flag rollouts with observability hooks — not a perfect match because those are on the traffic axis, but share the "observe, remediate, then commit" discipline.

Trade-offs

  • Logging mode is non-blocking by design; the window must be bounded because during it, violations in production continue to happen. Meta doesn't publish a target window length; it's per-requirement.
  • Violation fatigue: a noisy initial deployment can produce so many violations that operators can't triage them. Annotation simplification (via patterns/separate-annotation-from-requirement) and good PZM UX are the counters.
  • Remediation UX matters more than the runtime: the 2024-08-31 post's fifth lesson is "Build tools; they are required" — PZM "reducing engineering efforts by orders of magnitude" is what makes multi-year rollout feasible.

Seen in

Last updated · 319 distilled / 1,201 read