A Sabbath elevator works by running a fixed automatic cycle — stopping at every floor, opening and closing its doors on a timer, and traveling up and down — entirely independently of anyone inside it. Call buttons are disabled, displays are frozen, and passenger-triggered inputs are neutralized or replaced with timed delays, so a rider's presence causes no electrical change. It is one of the clearest examples of an engineering problem defined by religious law rather than by user requirements, and the design principles it illustrates transfer to any product that has to serve Sabbath-observant users.
The problem: a normal elevator is a wall of switches
Every interaction a passenger has with a conventional elevator closes an electrical circuit. Press a floor button and a contact makes. Stand in the doorway and a photo-eye or edge sensor changes state. Ride up and the floor indicator increments. Step in and the load cell registers your weight. For observant Jewish users, each of those actions is problematic on the Sabbath, which is why a standard elevator is not usable — and why the fix cannot be a firmware tweak. The same architectural logic drives Sabbath mode on appliances, where a reactive appliance becomes a scheduled one.
The solution: cycling that ignores the passenger
The control strategy is deliberately simple. On entering Sabbath mode, the controller stops being an elevator dispatcher and becomes a timed sequencer:
- The car travels a predetermined route, typically stopping at every served floor in order.
- Doors open and close on fixed dwell times, not on demand or on obstruction sensing.
- Hall and car call buttons are electrically isolated so a press produces no logged event, no lamp change, and no dispatch.
- Position indicators and audible announcements are frozen or silenced.
- Timing is generated by the controller's own clock, with the mode entered and exited by a preset schedule rather than by a person acting at the moment.
The passenger walks in and out and nothing they do changes any electrical state. That isolation — user completely decoupled from system behavior — is the central design idea.
Where it gets subtle
Even when the car drives itself, finer questions remain. A passenger's weight changes the load on the motor and therefore the current drawn; on a descent, that same weight arguably assists the braking or regenerative system. Rabbinic authorities differ on how to treat this, with descent generally viewed as the harder case, which is why approved Sabbath elevator controllers include specific provisions for these scenarios and why approval is typically conditioned on periodic inspection of the system.
There is also a hard constraint that engineers must never trade away: safety functions. US elevator installations are governed by ASME A17.1 and by local building and fire codes, which mandate door protection, emergency communication, firefighter recall and emergency operation, and overload protection. A Sabbath mode may not defeat any of them. In practice this means the door-protection behavior is redesigned rather than removed — long fixed dwell times, reduced closing force and speed, and retained but non-reactive protective devices where the code requires them — and that firefighter recall overrides Sabbath cycling immediately and unconditionally. Reconciling a religious constraint with a mandatory safety standard is exactly the kind of tension covered in product safety testing requirements.
What product developers can learn from it
The Sabbath elevator demonstrates four design principles that recur in nearly every kosher-oriented product:
- Deterministic cyclic operation instead of user response. Anything that must keep running does so on a fixed schedule, with no input dependency.
- Complete isolation of the user from electrical influence. Inputs are not merely ignored in software — they are isolated so no state changes anywhere, including logs and counters.
- All religious-law logic concentrated in one auditable controller. A single, well-defined module can be reviewed, tested, and certified. Logic scattered across five subsystems cannot.
- Periodic maintenance as a condition of approval. The certification covers a system in a verified state, not a system as originally shipped.
Point three is the one most often ignored, and it is an architecture decision, not a coding decision. It has to be made when you choose your controller and structure your firmware — see what firmware is and how to choose a microcontroller. It also constrains how you deploy updates, since a field update that alters approved behavior invalidates the approval; if you support remote updates, the design considerations in OTA firmware updates have to account for a certified configuration.
Who decides in the end
As always in this field: the engineer designs, but the ruling on whether a Sabbath elevator may be used, and under what conditions, belongs to a rabbinic authority or a halachic-technological institute. Our job as designers is to guarantee that the system does exactly what was approved, on every cycle and at every floor, with no surprises — and to document it well enough that a reviewer can verify the claim. That documentation discipline is the same one described in the product development process.
Building a product that has to work on the Sabbath
Sabbath-compatible behavior designed in from the specification stage is straightforward. Bolted on at the end, it is usually broken. Projects House develops products for US clients where religious-observance requirements sit alongside safety standards and normal cost targets — controller architecture, firmware, and the documentation an approving body needs. Describe what you are building through the contact form, and see our kosher product development guide for related engineering topics.