Governance

Who this is for: Owner — requires protocols.protocol.manage; reading evidence needs protocols.evidence.read. Where: Protocols, and Settings → Audit Log

A system that proposes actions about guests needs to be wrong in safe directions. This page is the set of checks that make that true.

The governing principle is deny by default, and check before composing. All of the controls below are read before an engagement is minted — not after it is proposed, and not at the moment someone presses the button. An action that cannot be checked against them does not surface at all. It never mints.

Consent, honoured at trigger time#

Marketing and profiling consent is modelled as guest data with provenance — where it came from and when — and it is checked when the trigger fires.

No consent, no targeted outreach. A play whose action is outreach simply does not fire for a guest who has not consented.

A service cue is exempt, and the distinction is the whole reason the two are separate categories. "Room 412 asked for extra towels at 9pm; follow up" is service. It is not marketing, it does not need marketing consent, and treating it as though it did would make the product useless for the thing hotels actually do.

Guest rights — access, objection, erasure — reach the profile and its evidence trail. That second half is what makes it real: an evidenced profile has to be correctable and deletable, not just the consent row sitting on top of it.

Ceilings a play author cannot exceed#

An authority envelope says what an assignee may offer. A guardrail says what the organisation permits an envelope to contain — a pricing or discount ceiling that binds every play, however it was authored.

The order matters: the guardrail is checked against the play, and the play's envelope is checked against the offer. Someone authoring an over-generous play does not create an over-generous engagement; the play is refused before it can fire.

A brand-voice gate applies the same way to a generated script. A script that does not pass it does not go out.

Suppression#

A suppression list is where no engagement fires at all — for a specific guest, a moment, or a segment. It is separate from consent on purpose: consent is the guest's decision, suppression is yours.

Use it for the cases every hotel has and no rule engine anticipates: the guest in the middle of a complaint, the VIP whose stay is being handled personally, the week the property is short-staffed.

Suppressing is reversible and does not touch the play.

What signals are not allowed to look at#

Classification carries a denylist holding signals to commercial behaviour rather than protected characteristics. A signal is a rule someone writes, so this is the layer that stops a well-meant rule from becoming a discriminatory one.

The mining corpus is separately PII-minimised — it is a set of (action, phrasing, outcome) tuples for finding patterns, never a targetable list of named guests — and carries its own retention window. Reading the evidence behind an engagement is gated on its own permission, protocols.evidence.read, rather than riding along with ordinary read access.

The kill switches#

Four, in increasing order of blast radius. None of them corrupts a past record.

Switch	Effect
Decline	Always available to the assignee on an assigned engagement, unconditionally. Nothing gates it.
Suppress a guest	No engagement fires for that target. Reversible.
Pause a signal	The classification loop behind it stops proposing. Plays stay authored.
Retire a play	It never composes another engagement, immediately — without touching any it already produced.

And above all of them: disabling the Protocols app on a hotel. That degrades straight to no prompts — no route answers, no signal fires. It is enforced twice over, once in permission resolution and once on the event stream, which is deliberate: a single check is a single thing to get wrong.

That a staff member can always decline is worth stating on its own. The person in the room is the last check, and nothing in this system is allowed to override them.

Every step is on the one audit trail#

Loop fired, play authored, engagement minted, assigned, acted, declined, debriefed, closed, expired, a profile delta written, an escalation requested and resolved, a script promoted, a play retired — all of it lands in the same Settings → Audit Log as every human action.

So does every block. A guardrail refusal, a suppression, a missing consent — each one is recorded. A block is a deliberate policy answer, not a failure, and the only way to know your governance is working is to be able to see it working.

There is no Protocols-only log. The audit row commits with the change it describes, in the same transaction — so a record can never survive an action that rolled back, or go missing on one that did not.

What's next#

• Authoring plays — envelopes, and what a ceiling binds.
• The queue — escalation and decline in practice.
• Audit log — the shared trail.