Skip to content

CONCEPT Cited by 1 source

Runtime control points (compression)

Definition

A runtime control point in OpenZL is a per-frame branch point embedded in a compression Plan that reads lightweight statistics at encode time and picks a subgraph based on them. The chosen branch is recorded into the frame's Resolved Graph; the decoder just executes the recorded path. (Source: sources/2025-10-06-meta-openzl-an-open-source-format-aware-compression-framework.)

What it solves

Production data drifts. Even within a stable schema, frames vary: bursts, outliers, seasonal shifts, distributional changes. Two ways to handle this:

  1. Re-train the Plan against new samples (Meta's Managed Compression does this on a schedule). Handles structural drift; expensive.
  2. Branch at encode time within the existing Plan. Handles per-frame variation; cheap.

Control points are mechanism (2). The Plan already encodes several candidate subgraphs; the control point picks one per frame based on observed statistics.

Mechanism

From the OpenZL post:

"A compression config can include control points that read lightweight statistics at compression time (e.g., string repetition stats, run-length, histogram skew, delta variance) and choose the best branch of the Plan to go to next. Many technologies can be used, and textbook classifiers qualify. Control points handle bursts, outliers, and seasonal shifts without brute-force exploration: exploration is bounded, in order to maintain speed expectations. Taken branches are then recorded into the frame, and the decoder just executes the recorded path." (Source: sources/2025-10-06-meta-openzl-an-open-source-format-aware-compression-framework.)

Three key properties:

  • Statistics are lightweight — string repetition, run-length, histogram skew, delta variance. No heavy ML inference.
  • Classifiers can be simple — "textbook classifiers qualify." The control point is routing, not modeling.
  • Exploration is bounded — the set of candidate branches and the statistics read are fixed by the Plan; the control point doesn't explore freely. This preserves the Plan's compression-speed guarantees.

Zero decoder complexity

The crucial invariant: the decoder is untouched.

"Best of both worlds: dynamic behavior at compression time to handle variations and exceptions — without turning compression into an unbounded search problem — and with zero complexity added to the decoder."

The decoder reads the Resolved Graph (including which branch was taken) from the frame and executes it. It doesn't re-run the classifier, doesn't read statistics, doesn't branch.

This is what preserves the universal-decoder property across Plan evolution — the decoder doesn't know or care whether a Plan has control points. It just executes whatever graph is in the frame.

Two timescales of adaptation

In Meta's architecture (Source: sources/2025-10-06-meta-openzl-an-open-source-format-aware-compression-framework):

Adaptation Timescale Mechanism
Handles schema drift, seasonal shifts that outgrow the Plan's branches Days / weeks Managed Compression re-trains + rolls out a new Plan
Handles bursts, outliers, within-Plan variation Per frame Control points inside the Plan pick a branch at encode time

Control points operate at the per-frame timescale, filling in between re-training cycles.

Seen in

Last updated · 319 distilled / 1,201 read