GlossaryGlosarium
What are member quiet hours?What are member quiet hours?
A window — 21:00 to 07:59 in the member’s own timezone — during which the fleet refuses to commit anything member-facing. The cadence and the hours belong to the recipient, not to the organiser’s clock, and not to the server’s.A window — 21:00 to 07:59 in the member’s own timezone — during which the fleet refuses to commit anything member-facing. The cadence and the hours belong to the recipient, not to the organiser’s clock, and not to the server’s.
Glossary / What are member quiet hours?
Member quiet hours are a protected window in which the fleet does not message a member. The window is 21:00 through 07:59, and it is evaluated in the member's own timezone, not the organiser's and not the server's. A member in WIB and a member in WIT each reach their own quiet hours when it is late where they are — the same wall-clock moment can be quiet for one of them and not for the other — and the organiser is looking at a third clock entirely.
The check happens before delivery, per recipient, at commit time. When it fails, the runtime refuses with `quiet_hours` and the message says what time it is in that member's zone — because "you messaged me at the wrong hour" and "the system believes it was a reasonable hour in my timezone" are very different conversations, and only the second one is worth having. Three things make this a real protection rather than a setting. It cannot be widened by a grant: no permission from the human seat moves the window. It cannot be widened by the organisation tier, because the organisation may narrow a class but the window is not a class. And it is evaluated per recipient, so a batch that would be quiet for one member and not for another is not quietly sent to the first and dropped for the second — the commit is refused.
The rule underneath it is simple: the cadence and the hours belong to the recipient. A community that tells people "we will message you about events" has not told them "we will message you about events at two in the morning". The quiet hours are where that promise is kept.
The related protections work the same way. The per-member cap counts commits to that member across every lane in a rolling twenty-four hours, not per lane, so a partnership does not become a second quota. And a member's stop — one row, cross-lane, with no API that clears it — outranks the organiser's permission.
Related
| Term | |
|---|---|
| What are once-vs-always grants?A grant is a permission the human seat issues for one action class. It comes in two kinds: allow_once, consumed after a single use, and allow_always, which must name the scope it covers. Collapsing the two is the bug that turns a helper into an unattended bot. | Read → |
| What is per-action autonomy?Per-action autonomy means every class of work gets its own rung on a three-step ladder — draft, opt-in-auto, or never — instead of one switch for the whole agent. An unset class behaves as never, never is a floor, and the narrower of the pack and the organisation always wins. | Read → |
| What does it mean that a hand-off is not a sent message?In version 0 the transport refuses to deliver. An approved message comes back to the organiser as a hand-off — the exact text and the exact audience — for them to send themselves. Nothing is sent on a member’s behalf, and nothing is described as sent. | Read → |
By Filbert Then · Last updated · Suggest a correction
See the fleet runLihat armadanya berjalan
Run the seeded cycle, decide the proposals, then read the audit trail.Jalankan siklus contoh, putuskan usulannya, lalu periksa audit trail-nya.