One Mode Is Usually Two Modes

Most products marketed to the Orthodox consumer ship with a single Sabbath mode. For a light timer that is fine. For an oven, refrigerator, hot water system, or thermostat, it is a shortcut that shows up as customer complaints and as findings during certification review.

Shabbat and Yom Tov are different halachic regimes. Products that collapse them into one behavior are either too restrictive on Yom Tov, frustrating users who are permitted more, or insufficiently restrictive on Shabbat, which is the failure that ends a certification.

The Halachic Difference, Briefly

On Shabbat, the categories of prohibited work are complete. Nothing may be kindled, extinguished, cooked, or switched.

On Yom Tov, a defined carve-out exists for food preparation needs. Cooking for that day is permitted. Transferring an existing flame to light another is permitted. Creating a new fire from nothing is not. That distinction, between transferring existing energy and originating it, is the axis every Yom Tov engineering decision turns on.

Electricity does not map cleanly onto either category, and authorities differ. Most treat switching a circuit as prohibited on Yom Tov as it is on Shabbat. Some permit adjusting an already-running load, for example raising or lowering an oven's setpoint, where the circuit is already energized and the change is quantitative rather than an act of origination.

The engineering consequence is that you cannot design to "the halacha." You design to the written ruling of a specific authority, reviewed by the agency that will mark your product. What that review involves is set out in halachic certification for products.

What That Means Inside the Product

A Yom Tov mode typically differs from a Shabbat mode in four ways.

  • Setpoint adjustment may be allowed. An oven in Yom Tov mode commonly permits the user to change temperature, where in Shabbat mode the setpoint is frozen. This is the single most requested difference in the appliance category.
  • Heating loads may be user-initiated within limits. Where Shabbat mode requires the indirect-action architecture surveyed in grama mechanisms, Yom Tov mode may permit a more direct path for cooking loads specifically, while keeping indirect handling for lights, fans, and displays.
  • Suppression rules stay in force. Displays, tones, indicator changes, and automatic shutoff timers are generally suppressed identically in both modes. Do not assume a Yom Tov leniency on cooking extends to the user interface.
  • Door and sensor handling. An oven door switch that kills the element is a problem on both days, and a refrigerator door triggering a compressor or a light is handled identically in both, as described in Sabbath mode refrigerators.

Write these as two requirement sets with two verification suites. Sharing 80% of the firmware logic is fine; sharing the specification is not, because that is how a Yom Tov leniency leaks into Shabbat behavior in a later release.

The Hebrew Calendar Is a Firmware Requirement

Shabbat is trivial to schedule: every seventh day, boundaries set by local sunset. Yom Tov is not. Its dates come from the Hebrew lunisolar calendar, which does not align with the Gregorian one and moves by roughly eleven days a year with periodic leap months.

If your product enters its restricted mode automatically, the calendar becomes a hard engineering requirement with several parts.

Calendar computation. Embed a Hebrew calendar algorithm, ship a lookup table with a defined horizon, or fetch dates from a network service. Each has a maintenance implication: a table has an expiry, an algorithm must be validated against reference data, and a network dependency creates an availability requirement precisely when the user cannot intervene.

Location. Boundary times are local sunset and nightfall, requiring latitude, longitude, time zone, and a rule for the user's halachic time convention, since candle-lighting offsets and nightfall definitions vary by community.

Two-day observance. For a product sold in the United States this is not optional. Most Yom Tov days are observed for two days in the diaspora rather than one, changing both the schedule and the maximum restricted duration. Make it a configurable setting with a regional default.

Chol HaMoed. The intermediate days of Pesach and Sukkot are neither Yom Tov nor ordinary weekdays. Most products simply resume normal operation, but the transition in and out has to be handled correctly rather than leaving the device stuck in a restricted state for eight days.

Products that avoid all of this by delegating scheduling to a separate controller are making a legitimate engineering tradeoff, and the pattern is discussed in Shabbat timers and controllers.

Long Sequences Are the Real Test

The hardest case is not a single day. It is Yom Tov falling adjacent to Shabbat, producing a continuous restricted period of roughly 72 hours, which occurs several times in most years and reliably for Rosh Hashanah in many. In the diaspora, three-day sequences are routine rather than exceptional.

Everything comfortable for 25 hours becomes marginal at 72. Water reservoirs run dry. Real-time clock backup batteries drain. Timer programs holding 24 hours of schedule must hold three days. Thermal systems that drift 2 degrees F per day drift 6. Watchdogs that reboot into normal mode cause a compliance failure on day two. Memory leaks that never surfaced in testing surface here.

Design and test to the 72-hour case explicitly. Run a full three-day soak with the product in mode, instrumented, before certification. The categories where this matters most are hot water, covered in Shabbat hot water urns, climate control, and institutional installations where a failure affects hundreds of people rather than one household, a scale problem detailed in Shabbat technology for hotels and institutions.

Two sequence-specific items belong in the requirements. Define behavior on a power interruption spanning a mode boundary: what state the product resumes in, and whether it still knows what day it is. And define the handoff between consecutive restricted days, since Friday-into-Shabbat and Yom Tov-into-Shabbat are different transitions with different permitted behavior.

Who Decides

Every question above resolves to a ruling, not an engineering preference. Pick one rabbinic authority and one certifying agency at the start, get the Shabbat and Yom Tov behavior differences in writing before architecture is fixed, and treat any later change as an engineering change with its own verification. A product that shipped with a single blended mode, or with a leniency the certifying body did not accept, generally cannot be fixed with a firmware patch, because the mode structure sits in the architecture alongside everything else described in how Sabbath mode is engineered.

Design Both Modes From the Start

Projects House specifies and builds dual-mode compliant products: separate Shabbat and Yom Tov requirement sets, Hebrew calendar and location handling, 72-hour soak validation, and a traceability package the certifying agency can review. Send your product category and target authority through our contact form.