## Mechanical **Mechanical presets** capture reproducible clock behavior. They are intended to answer: *what mechanism is this clock currently running?* The mechanical domain includes the state needed to reproduce positions and movement: Drive definitions (including Fixed positions and Time-slave relationships), Motion stages, Epicycle settings, Position, element visibility, bezel order, and related Clock-owned mechanical parameters. Mechanical presets deliberately exclude the appearance of the instrument and all shared framework interface preferences. Applying one changes how the mechanism behaves without choosing a site color theme or typography. The preset library contains Factory presets supplied with the application and user-created presets stored under **My presets**. Saving, renaming, deleting, exporting, and importing operate on the clock preset domain rather than on shell state. The **Mechanical fingerprint** provides a compact deterministic representation of the same mechanical domain for comparison, validation, copy/paste, and transport. ## Style **Style presets** capture authored appearance of the clock instrument. They are intended to answer: *how should this clock be drawn?* The style domain includes Clock-owned visual choices for hands, bezels, face, center, marks, labels, grids, dimensions, and other appearance controls. It does not contain Drive, Motion, Epicycle, position mechanics, or other behavioral state. Style presets also deliberately exclude **shared framework color themes and typography**. Those are interface preferences owned by the site shell, so changing the site's theme or font does not redefine a clock Style preset and applying a Style preset does not restyle the surrounding application shell. The **Style fingerprint** is the deterministic compact representation of this authored clock-appearance domain. A complete **Current clock** export is separate and can carry the full reproducible Clock configuration when both mechanical and style state are needed together.