Indirect Action: The Engineering Principle

A grama mechanism is a device architecture in which a user's action does not cause an electrical or mechanical effect — the machine's own independent, continuously running cycle does. The user only alters a condition that the machine was going to sample anyway. Practically, that means the design must contain a process that runs on a fixed schedule regardless of any input, and the user's interaction must be arranged so it removes an obstacle or changes a state that the process later reads, rather than closing a circuit or triggering an event. Whether a given implementation satisfies halachic requirements is a ruling for a rabbinic authority or a certification agency, not for engineers; what follows is how to build a mechanism that such a ruling can be made about.

The Three Patterns That Actually Get Built

1. The Fixed-Interval Scanner

The controller runs a polling loop on a fixed period — the interval is a specification parameter — and samples its inputs at every tick regardless of whether anything changed. A user presses a button; nothing happens. Somewhere in the next interval, the scan runs on its own schedule, observes the new input state, and acts. Critically, the scan runs identically whether or not the button was ever pressed, and the button generates no interrupt, no wake event, and no acknowledgment.

This is the most common pattern and the easiest to implement badly. In firmware terms it means no interrupt-driven input handling on the user path, no event queue that a press enqueues, and no sleep-wake behavior tied to the input. The loop is the actor; the input is only data the loop happens to find. If the microcontroller is asleep and the press wakes it, the pattern is broken — a distinction worth understanding alongside what firmware is and how a controller handles inputs.

2. Removal of an Inhibit

Rather than making a circuit, the user removes something that was preventing an action the device would otherwise have taken. A shutter blocks an optical path; sliding it away lets a beam that was already being emitted reach a detector that was already looking for it. Nothing was created — an obstruction was withdrawn from an ongoing process. The design requirement is that the emitter, detector, and their sampling all run continuously and independently, and the user's part is purely subtractive.

3. Deliberate Separation in Time

The effect is separated from the act by a defined delay, implemented so that the delay is a property of the machine's cycle rather than a timer the user started. The distinction matters enormously: a countdown that begins because the user pressed something is a user-initiated action with a delay. A fixed cycle that will act at its next boundary regardless is not. Sequencing that runs autonomously, with the user's input as one more sampled condition, is the pattern that holds up.

Design Requirements That Follow

  • The cycle must be genuinely independent. Same period, same power draw, same behavior whether a user is present or absent. Any optimization that skips work when there is no input destroys the property — and such optimizations are exactly what power-management design normally pushes you toward, so the conflict must be resolved explicitly.
  • No feedback on the user's action. No LED lighting on press, no beep, no haptic, no display change. Any acknowledgment is itself an effect caused by the user, and it is the single most common design mistake.
  • The user must not be able to accelerate the cycle. No "press twice to speed up," no priority handling, no shortening of the interval under load.
  • The input must not generate energy. Rules out piezoelectric switches, generator-style buttons, and anything that harvests the press. Prefer a passive change of state: a mechanical shutter, a magnet moved out of range, a resistance change in an already-energized divider.
  • The input must not measurably change power dissipation. Design the sensing path so it draws the same current in both states, which usually means a continuously biased sensor read by the scan rather than a switch that opens or closes a load.
  • Deterministic worst-case latency. The user needs to know the maximum wait, and the specification needs to guarantee it. A best-effort interval is not a specification.
  • Verifiable in schematic and in code. Someone reviewing the design must be able to point at the loop that runs unconditionally and at the absence of any interrupt on the user path. Bury the logic in a framework's event system and it becomes unreviewable — which in practice means unapprovable.
  • Fail-safe behavior. Define what happens on power loss, brownout, reset, and sensor failure. Recovery must resume the independent cycle without user interaction.

Choosing Hardware for It

The architecture pushes specific component choices. A microcontroller with a reliable, low-drift timebase matters more than raw speed, since the cycle period is a design guarantee — the trade-offs in how to choose a microcontroller apply with the timebase weighted heavily. On the actuation side, motion driven by the cycle rather than by the user leans toward continuously energized or cyclically commanded drives, so the comparison in stepper versus servo versus DC motor is worth revisiting with duty-cycle constancy as a criterion. And sensor selection should favor continuously powered analog or optical sensing over mechanical switching, because a continuously biased sensor is far easier to keep electrically indistinguishable between states.

Where This Shows Up in Real Products

  • Water dispensers and urns — the classic application, where a scanned request pattern replaces a valve switch and the pump runs on its own cycle.
  • Elevators and access control — call handling by scheduled scan rather than by call button, a design space explored in how Sabbath elevators work.
  • Medical and monitoring devices — where a measurement genuinely must be available on demand and cannot wait for a schedule.
  • Appliances with a Sabbath mode — ovens, refrigerators, and warming drawers, where indirect action supplements the scheduled behavior described in Sabbath mode appliances.
  • Home automation — the small number of interactive devices that a scheduled system cannot cover, discussed in kosher smart home automation.
  • Assistive equipment — beds, lifts, and mobility aids where the user's independence over Shabbat depends entirely on this architecture.

The Bottom Line

Grama design is an unusually strict form of an ordinary engineering skill: making a system's behavior fully specified and independent of the things you would normally let influence it. The mechanism has to be simple enough to explain in one paragraph, visible in the schematic, traceable in the code, and unchanged by any optimization a later developer might add — which is why it belongs in the architecture and the requirements document rather than in a firmware revision late in the project. It also needs a rabbinic authority's review, and that review goes far more smoothly when the design documentation shows exactly which loop acts and why the user's action does not. More on this engineering discipline in our kosher product development hub.

Build the Mechanism Right the First Time

Projects House has designed indirect-action mechanisms into dispensers, monitoring systems, and access equipment — electronics, firmware, and the documentation a certification review needs. Tell us about your product through the contact form and we will help you architect a mechanism that holds up to both engineering and halachic scrutiny.