One Design, Many Videos

HyperFrames becomes a production system rather than a one-off animation when one reviewed composition can accept new content without losing its timing and visual logic. The focus here is the boundary between variation and structure: what belongs in declared variables, how nested instances and batch renders receive values, and how media and output formats change the delivery decision. This lets you decide whether a new version is a safe input to the same design or a source change that needs another review.

Variables preserve a reviewed design

A variable is an explicit permission to change part of a composition. A customer card might expose a title, accent color, logo, or featured-state switch while keeping its layout and motion stable. HyperFrames stores those permissions on the composition declaration, where each input has an ID, a type, a human-readable label, and a default. Supported types include strings, numbers, colors, booleans, enumerated choices, fonts, and images.

The declaration is more than documentation. It gives Studio a way to show an appropriate control, gives agents a meaning they can understand, and gives rendering a contract against which values can be checked. A color slot is not the same kind of input as a headline. An enum can be restricted to approved choices instead of accepting any string that happens to reach the composition. A useful label explains what the value means to the viewer—for example, “name of the brand this video promotes”—rather than only where the value appears on the screen.

Common cases do not need a large script. A text element can bind directly to a title variable, an image or video can bind its source to a media variable, and scalar values can become CSS custom properties. Code that calls getVariables() is appropriate when the value changes logic, such as whether a badge is shown or which branch of a scene is used. The distinction keeps simple content changes visible in the markup while leaving conditional behavior explicit in the composition code.

The values can enter at different boundaries. A composition's defaults make the template usable on its own. A parent can pass different values to each nested host, so two copies of the same card can carry different names and colors. A render command can override top-level defaults for one output, and a batch can apply one object per row to produce a family of files. In every case, the source layout and animation remain the common design unless the author explicitly edits them.

Imagine a five-second announcement card with a fixed entrance, a headline, a logo, and a closing accent. One render uses “Acme Pro” and a red accent; another uses “Northstar Pro” and green. The values change what the audience reads and sees, but the card still enters at the same point, occupies the same composition window, and follows the same motion. That is the useful form of reuse: variation is deliberate because the template has said what may vary.

Nested compositions make the boundary even clearer. The parent supplies a value through the host element, while the child reads that value alongside its declared default. The child still owns its local timeline.