Authoring plays

Who this is for: Owner and Manager — requires protocols.protocol.manage. Where: Protocols → Plays

A play is one piece of your operating knowledge, written down so it can fire, be acted on, and be measured.

If you are starting from nothing, Seed starter templates installs a handful of worked plays you can read, edit, or throw away. Reading one is the fastest way to understand what the fields are asking for.

The fields#

Field	What it is
Key	Stable identifier. It never changes, across every version.
Name	What people call it
Department	Who owns it — Protocols is department-agnostic, so this is yours to decide
Target kind	What it fires about: a guest, a stay, a check
Hypothesis	What you believe is true, and are about to test
Instruction	What the assignee should actually do
Moment	When it fires
Routed permission	Which permission a person must hold to receive it — not a named individual
Priority	Ranking against other plays competing for the same queue
Debrief outcomes	The answers the assignee may give afterwards
Measured metric	The number this play is judged on
Status	Draft, running or retired

Two of these are worth dwelling on.

Hypothesis is not decoration. It is the sentence that makes the play falsifiable. "Repeat corporate guests offered the corner room at check-in take it often enough to pay for the upgrade" is a claim Effectiveness can eventually agree or disagree with. "Improve the guest experience" is not.

Routed permission, not a person. A play is delivered to whoever holds the permission at that property on that shift. Staff change; the play should not need editing when they do.

An edit mints a version#

Changing a running play does not change it. It creates a new version, and the old one stays exactly as it was.

This looks like bookkeeping and is actually the thing that makes measurement possible. An engagement that ran three weeks ago is interpretable only against the version it ran under — its instruction, its envelope, its debrief options. Mutate that in place and every past record silently starts lying about what was asked of the person.

It also means effectiveness is measured per version. If you tighten a trigger that was firing too widely, the fix is scored separately from the problem, rather than averaged into it.

New version on a play opens the editor pre-filled with the current version. A version's status — draft, running, retired — is what decides whether it fires.

The authority envelope#

Every version carries an authority envelope: what an assignee may do without asking anyone. In its simplest form it is a may and a may not, in plain words. Where a play authorises something priced — a discount, a comp, an upgrade — the envelope also carries the ceiling.

The envelope does two jobs at once:

• On the queue card, it tells the person what they are allowed to offer, so they do not have to ask.
• At compose time, it is what a proposed offer is checked against. Going beyond it is an escalation — a recorded state transition, not a workaround — and the decision is deterministic, never a model call.

An envelope cannot exceed the organisation's own guardrail ceilings, whatever a play author types. See Governance.

Rolling a play out gradually#

A promoted version does not have to reach everyone at once. A version carries a rollout percentage, and the split is deterministic on a cohort hash — the same target always lands on the same side of it. So a play can be run against a slice of the house and compared honestly against the slice that did not get it.

What's next#

• The queue — what an assignee sees when your play fires.
• Effectiveness — whether the hypothesis held.
• Governance — the ceilings and consents your play runs inside.