The queue

Who this is for: anyone holding protocols.engagement.read — typically Front Desk, Manager and Owner. Where: Protocols → Queue

A play that fires produces an engagement: one protocol, one target, one moment, one assignee. The queue is where those land and where they get worked.

This is the surface the whole module exists to serve. A play nobody acts on is a note in a database.

What a card carries#

An engagement is not a notification. It is a card with everything needed to act without going and looking things up:

On the card	What it is for
Instruction	What to do, in the words the play author wrote
Script	The suggested phrasing, where the play has one
Why	The reason this fired, in a sentence
Evidence	The facts behind the why — inspectable, not a summary
Debrief	The question you will be asked afterwards, visible before you act
Authority envelope	What you may offer without asking anyone
Expires	When this moment stops being the moment

The envelope being on the card is the point. A front-desk agent should not have to guess whether they are allowed to comp the breakfast — the card says what they may do, and going beyond it is an escalation, which is a recorded transition rather than a workaround.

Showing the debrief question before the action is also deliberate. Knowing you will be asked "did they take the upgrade?" changes how you make the offer.

The states#

State	Meaning
Proposed	Fired, waiting for someone to pick it up
Assigned	Claimed — it is yours
Acted	You did the thing; the debrief is now owed
Declined	You judged it not to apply, with a reason
Debriefed	The question is answered and its projection has been applied
Closed	Finished
Expired	The moment passed before anyone acted

The actions on a card follow the state: Assign to me, then Act or Decline, then Debrief, then Close. Filter by state from the header; All shows everything.

Declining is a real answer, not a failure. A play that fires on stays it should not is only discoverable if people are able to say so cheaply, and a decline with a reason is the signal that finds it. So is a run of expiries: it usually means the trigger is firing at the wrong moment rather than that the team is ignoring the queue.

Why the desk does not get buried#

A trigger flood — a hundred bookings landing at once, a badly-scoped signal — could bury a front desk under prompts and make the whole surface something people learn to ignore. So new engagements are throttled: at most five new proposals per role, per property, in a rolling hour.

Engagements that are already assigned keep delivering past that cap. It is only proposing more work that backs off. The intent is that the queue stays a place a person can actually clear.

Claiming is atomic#

Two people opening the queue at the same moment cannot both take the same engagement — the claim is settled server-side, and the second one is told it is already taken rather than being allowed to do the work twice. The same holds for an agent working the queue through list_engagements and submit_debrief: it claims through the identical path, under the identical permissions.

The debrief writes exactly one thing#

When you answer, the play's projection applies the change that answer implies to the target record — and nothing else. The change is caused (it points back at the engagement that produced it) and reversible.

There is no path from a debrief to an arbitrary field edit, and none from a model to a write. If you want a play to be able to change something, that change has to be declared in the play's projection first, by a person, in advance.

What's next#

• Authoring plays — where instructions, envelopes and debriefs are written.
• Governance — suppressing a guest, and the ceilings an envelope cannot exceed.
• Effectiveness — what all this debriefing is measuring.