event-vip-social-program

{
  "skill_name": "event-vip-social-program",
  "evals": [
    {
      "id": 1,
      "prompt": "I run Terrafest, a 400-person volunteer-run infrastructure conference in Porto. We're deliberately flat - no reserved seating, speakers buy their own ticket, we've turned down reserved front rows twice now because it isn't who we are. Our comms lead wants to do a small private dinner on the Friday for six people: two long-time maintainers, a researcher whose paper everyone keeps citing, and three of us from the org. Her pitch is that it would be really nice for them to finally meet each other properly. The venue has a back room we could use for free. Can you help me set this up - guest list, invitations, timing?",
      "expected_output": "A finding that no separate private gathering should exist here, plus the mechanics of folding the guests into the general evening: a named companion, the intended conversations written down in advance, a stated exit time, and no announcement. No seat list, no door plan, no invitation copy.",
      "files": [],
      "expectations": [
        "Recommends that no separate private dinner be held, and presents that as the answer rather than designing the dinner.",
        "Identifies that \"it would be really nice for them to finally meet each other\" names nothing the general evening cannot already do.",
        "States that every seat-list construction option except the fold is deleted from the menu, not merely ranked last or parked at the bottom.",
        "Treats the flat anti-hierarchy register and the absent purpose as two separate conditions that both have to hold before that deletion applies.",
        "Names one person by role who will stand with each guest when they walk into the general evening, and for how long.",
        "Instructs writing down, before the evening, the specific conversations the dinner was meant to produce, named individually rather than stated as a goal.",
        "Gives the guests a stated time at which someone will walk them to the door, so leaving needs no excuse.",
        "Instructs saying nothing publicly about the arrangement, because announcing that a guest is being looked after re-creates the tier for free.",
        "Produces no seat-list template, no door list, no credential and no invitation copy for a private dinner.",
        "Invents no seat count, no cap, no lead time and no invitation-send date.",
        "Warns that a guest left holding a drink at the edge of the room is worse than not inviting them at all."
      ]
    },
    {
      "id": 2,
      "prompt": "Streamline Summit, around 900 attendees, vendor-side event we run ourselves. We host a partner lunch on day one that everyone internally calls the founders' table. Three sponsors have come at us in the last week: Kestrel Analytics asked for two seats, Bowline Cloud asked whether they could \"bring a couple of people\", and Aurelio Systems is asking for four - except Aurelio's signed Platinum agreement literally lists \"4 seats at the partner lunch\" as a Platinum benefit. My instinct is to apply the same two-seat cap to all three so nobody can accuse us of favouritism. On top of that one of our keynote speakers has asked us to add her former colleague. How do I handle all of this?",
      "expected_output": "Aurelio's four contractual seats pulled out of the allocation problem entirely and routed to sponsor fulfillment; the remaining asks handled under a host list with a stated per-party allowance; a refusal rule written before anyone is answered, cited identically to each party, and paired with a real alternative.",
      "files": [],
      "expectations": [
        "Excludes Aurelio Systems' four seats from the allocation rule because the signed agreement sold them.",
        "States that applying the two-seat cap to contractually promised seats would be a breach rather than a fairness measure.",
        "Routes Aurelio's four seats to samber/dev-event-organizer-skills@event-sponsor-fulfillment and takes them off the seats being allocated.",
        "Keeps Kestrel's, Bowline's and the keynote speaker's requests inside this skill's allocation problem, because those were asked for rather than sold.",
        "Selects the host-built list with a capped allowance per asking party, on the ground that more than one party is already asking.",
        "Invents no seat cap, per-party allowance or room capacity of its own; any figure used is one the organizer supplied.",
        "Requires the allowance and the refusal rule to be written down before any of the asking parties is answered.",
        "Requires the same rule to be cited to every asking party, including the keynote speaker.",
        "Pairs each refusal with a concrete alternative that is genuinely available, such as the general evening, an introduction during a break, or a scheduled conversation.",
        "Phrases the refusal so the rule is the stated reason, never the nominated person.",
        "Requires stating in writing, to invitees and to whoever asked for seats, that the lunch is a relationship rather than a meeting arranged on a sponsor's behalf."
      ]
    },
    {
      "id": 3,
      "prompt": "Problem. Our head of partnerships told Vanta Logistics yesterday that they could bring three people to the investor breakfast at DataBridge Conf. He doesn't hold the list, I do. The room at the hotel seats fewer people than the number who now have an invitation, and I haven't sent the rest yet. Two of the three he offered seats to have already replied yes. Can I walk it back? And what do I do about the four names I still think genuinely need to be in that room?",
      "expected_output": "The accepted invitations honoured, the process fixed rather than the guest, a single named owner established for the list and every future invitation, and the room's purpose shrunk deliberately instead of the seat count picking the names.",
      "files": [],
      "expectations": [
        "Honours the seats the head of partnerships already offered rather than withdrawing them.",
        "States that an accepted invitation cannot be withdrawn without costing more than the seat did, because the reversibility was spent the moment the yes was sent.",
        "Fixes the process rather than the guest: from here, invitations issue only from the person holding the list.",
        "Names one owner who builds the list, sends every invitation, works the door and answers every refusal.",
        "Treats the room's capacity as a constraint and never as a criterion for who belongs in it.",
        "Instructs shrinking the purpose of the room deliberately rather than trimming names until they fit the seat count.",
        "Keeps a seat offered and a seat confirmed as two distinct recorded states, each with its own date.",
        "Records who put each name forward and on what date, so the outcome can be defended later.",
        "Flags seats promised beyond what the room held as a binary measure this event has already failed.",
        "Invents no capacity figure for the room and no number of seats to reclaim."
      ]
    },
    {
      "id": 4,
      "prompt": "HealthStack Days. We're hosting a reception for about a dozen named guests. One of them is the programme director of the foundation that funds roughly half our budget, and her office wrote to us asking that she not be listed anywhere or photographed at the event. Our marketing lead has two ideas she's attached to: gold wristbands so the room is easy to staff, and a line in the printed programme reading \"Invited Guests Reception - 18:00, Salon B\" so people know it's closed and stop asking us about it. Print deadline is in a few days. Thoughts?",
      "expected_output": "Both the wristband and the programme listing removed from the option set outright because of the discretion request, a named door list held by one person adopted instead, the invitation issued individually and privately, and the door page mechanics specified including its return to the owner.",
      "files": [],
      "expectations": [
        "Rejects both the wristbands and the programme listing, removing them from the option set rather than ranking them low.",
        "States that no rewording of the programme line and no redesign of the credential fixes what the discretion request forbids.",
        "Ties that deletion specifically to the guest whose office asked that she not be listed or photographed.",
        "Selects a named door list, held by one person, as the access mechanic instead.",
        "States that publicly only a closed door and somebody standing at it should be legible.",
        "Requires the invitation to go out individually and privately from the person holding the list, never on a group thread.",
        "Bans the word \"VIP\" in the invitation, at the door, and on any radio or staff channel.",
        "Limits the door page to the names, alphabetically, and nothing else.",
        "Instructs the door holder to take the name of anyone not on the page, say the owner will come, and fetch them - never to turn someone away with an explanation and never to adjudicate.",
        "Requires the door page to be handed back to the owner at the end rather than left or binned in a public room.",
        "Sets discretion as a binary check: zero guests who asked not to be identified are identifiable to a general attendee as having been in the room."
      ]
    },
    {
      "id": 5,
      "prompt": "Kernelcon, second edition, 600 people. We want a private room for our three grant officers and a few maintainers - the point is that those eight people actually talk properly, not a hello. My plan: book the wine bar fifteen minutes' walk from the venue, same evening as our community party which runs 19:00 until late, and have people drift over around 20:00. I'm the event lead, I'm on site all day, and I'd be the one organising the bar, the transport and the headcount. Does this work?",
      "expected_output": "The offsite option deleted because the named owner is also running the event that day, the overlap with the community party refused, and the placement landed inside the main venue - promoted above a break slot because the purpose is a real conversation - with the slot handed to the run of show.",
      "files": [],
      "expectations": [
        "Deletes the separate-evening-at-a-separate-venue option because the named owner is also running the main event that day.",
        "Explains that deletion as a second venue with transport and a fixed headcount being a job, which with no free owner lands on the organizer on the day.",
        "Rejects scheduling the private room against the community party, at any venue.",
        "Names the failure as the general evening becoming the consolation room, a tier arrived at by calendar.",
        "States that where both the private room and the general evening exist, they do not overlap.",
        "Offers a slot inside an existing break or meal slot, in a side room, as the default placement.",
        "Promotes the placement to after the last session, in a room at the main venue, on the ground that the purpose is a conversation among a named set of people rather than a greeting.",
        "Hands the chosen slot to samber/dev-event-organizer-skills@event-run-of-show and any grid clash to samber/dev-event-organizer-skills@event-schedule-design.",
        "Refuses to move a public session to make room for the private one.",
        "Invents no seat count, cap or headcount for the room."
      ]
    },
    {
      "id": 6,
      "prompt": "Quick one. Our invited-guests room at Loomfest is in the hotel's executive lounge on floor 12. Hotel security controls that floor and they've told us their own staff will handle access - none of my team can be up there, we're all running the closing keynote until it ends. The hotel says they need \"something they can check\". I was going to just email them our guest list. Reasonable?",
      "expected_output": "The shared credential promoted above the named door list for this specific gathering because the door is staffed by people who cannot read your list, with the credential's costs stated, circulation to hotel staff limited to what running the door requires, and the discretion check run first.",
      "files": [],
      "expectations": [
        "Promotes the shared credential above the named door list for this gathering rather than defending the list as the default.",
        "States the reason as the door being staffed by people who cannot read your list, and that a list they cannot read is not a door.",
        "Notes that a credential is the only thing a venue's own staff can check.",
        "Warns that the credential must not be worn through the general event, where attendees read it as a rank.",
        "Names the credential's other cost: the door stops working once one is lent or copied.",
        "Keeps the invitation itself issued individually and privately by the person who holds the list.",
        "Limits what hotel staff receive to what running the door requires, withholding the reasons a seat exists, who nominated whom, and any refusals.",
        "Checks first whether any guest asked not to be identified, listed or photographed, since that deletes the credential outright.",
        "Keeps the named owner as the person who decides any exception at the door, even though a third party is staffing it."
      ]
    },
    {
      "id": 7,
      "prompt": "Foundry Conf. Our sponsor prospectus went out in March and it lists \"an invited-guests roundtable with the programme committee\" as a Gold benefit - that was marketing's wording, not mine. Now four sponsors plus two of our speakers are asking how to get a seat. The roundtable is in the venue's Blue Room, and the venue's fire capacity for that room is whatever they tell us it is; they will not budge on it. I was planning to publish a set of criteria - here's what we look for, apply and we'll pick - and let that do the arguing for me. Does that hold?",
      "expected_output": "The published-criteria rung deleted because the seat count is set by the venue rather than by the conversation, the capped-nomination rung chosen instead, the already-published room treated on the access menu as a description of what happened, and any contractually sold seats routed to fulfillment.",
      "files": [],
      "expectations": [
        "Rejects the published-criteria approach to building the seat list, removing that option from the menu rather than ranking it low.",
        "Ties that deletion to the seat count being set by the venue's fire capacity rather than by the conversation the organizer wants to have.",
        "States that publishing criteria against a number you do not control converts a capacity limit into a broken commitment.",
        "Recognizes that the prospectus having been published would otherwise have promoted exactly that rung, and says which condition wins.",
        "Lands on a host-built list with a capped allowance per asking party, because more than one party is already asking.",
        "On the access decision, accepts that the room is already published and treats the listing as a description of what already happened rather than a decision still open.",
        "States that the remaining work on the listing is the wording, not whether to list.",
        "Checks whether any signed sponsor agreement actually sold those seats, and routes any that did to samber/dev-event-organizer-skills@event-sponsor-fulfillment.",
        "Writes the refusal rule down before answering any of the four sponsors or two speakers, and cites the same rule to each.",
        "Refuses to let the number of seats the venue allows become the criterion for who is on the list.",
        "Invents no seat cap, per-sponsor allowance or room capacity figure."
      ]
    },
    {
      "id": 8,
      "prompt": "Three things on my plate for ByteHarbour Conf. One: we've got a speakers' dinner budget line and finance says there's room left in it, so can I just run the funder's table off that? Two: Northwind Data wants to throw their own afterparty on the Thursday and has asked us to put it in the schedule. Three: my co-organiser keeps saying the funder isn't really a VIP anyway, she's just someone who gave us money, so maybe none of this matters. Sort me out.",
      "expected_output": "The speakers' dinner budget line kept to speakers, Northwind's afterparty routed to side-event coordination as a room you permit rather than host, and the question of whether the funder is in scope routed to VIP management rather than re-decided here.",
      "files": [],
      "expectations": [
        "Refuses to fund the funder's table from the speakers' dinner budget line, stating that the line describes speakers and nobody else.",
        "Routes the speakers' dinner itself to samber/dev-event-organizer-skills@event-speaker-experience.",
        "Routes Northwind Data's afterparty to samber/dev-event-organizer-skills@event-side-event-coordination.",
        "Draws the distinction as a room you permit versus a room you host.",
        "Routes the question of whether the funder is in scope at all to samber/dev-event-organizer-skills@event-vip-management, and declines to re-decide it here.",
        "States the qualification test as an obligation the general attendee flow cannot absorb, never a title or a status.",
        "States that if that skill finds nobody in scope, there is no gathering to design here.",
        "Routes food and drink for any room that does exist to samber/dev-event-organizer-skills@event-hospitality."
      ]
    },
    {
      "id": 9,
      "prompt": "Can you give me a guest-list spreadsheet and an invite timeline for our partner dinner at Cascade Summit? Columns I was thinking: name, company, tier (platinum / gold / personal contact), seniority, priority 1-5, dietary, confirmed y/n. Plus a rough schedule for when invitations go out and when we chase the non-responders. Team of four will share the sheet in Drive.",
      "expected_output": "A list whose fields are name, why the seat exists in one sentence, who nominated it and when, the answer given and when, and supplied access requirements - with the tier, seniority and priority columns removed, a deletion date fixed at creation, circulation restricted by need, and no invented dates.",
      "files": [],
      "expectations": [
        "Removes the tier, seniority and priority columns from the list.",
        "States that the list never records a judgment about a person, and that every field is either a fact somebody supplied or a decision the organizer can defend.",
        "Replaces the removed columns with a one-sentence \"why this seat exists\" field that is not a rank, not a title, and not \"important to us\".",
        "States that a row whose sentence has to be invented is a row that comes off the list.",
        "Adds a field recording who put the name forward and the date they did.",
        "Records the answer given and the date it was given, keeping a seat offered and a seat confirmed as distinct states.",
        "Keeps access requirements only where the person supplied one, including any discretion request quoted from whoever stated it.",
        "Sets a deletion date at the moment the list is created, by the named owner, in the same pass, defaulting to the day the post-event follow-ups go out.",
        "Restricts circulation by need instead of sharing the whole sheet with the team of four, giving whoever works the door the names only - not the reasons, not who nominated whom, and never the refusals.",
        "Declines to invent an invitation-send date, a chase date or a lead time.",
        "Names a single person who holds the sheet and issues every invitation from it."
      ]
    }
  ],
  "trigger_queries": [
    {
      "query": "Two sponsors and a keynote speaker have each asked us to add someone to our founders' lunch. How do we decide, and how do we say no to the others?",
      "should_trigger": true
    },
    {
      "query": "How do we run an invite-only dinner at our conference without it looking like a VIP tier?",
      "should_trigger": true
    },
    {
      "query": "Someone on my team already promised a sponsor seats at our private breakfast and now we've over-invited.",
      "should_trigger": true
    },
    {
      "query": "We want a small room where our grant officer can actually talk to three people. When do we put it, and do we tell anyone it exists?",
      "should_trigger": true
    },
    {
      "query": "Marketing wants an invitation-only reception printed in the programme. Our conference is explicitly flat. What do I do?",
      "should_trigger": true
    },
    {
      "query": "Do we need wristbands for the closed-door lunch, or is a list at the door enough?",
      "should_trigger": true
    },
    {
      "query": "How do I put together the guest list for the partner dinner when four different people keep pushing names at me?",
      "should_trigger": true
    },
    {
      "query": "What should the person on the door say when an attendee asks what's going on in that room?",
      "should_trigger": true
    },
    {
      "query": "Our funder asked not to be photographed or listed anywhere. Can we still run a closed reception for her?",
      "should_trigger": true
    },
    {
      "query": "Where in the schedule should a closed-door dinner sit so it doesn't compete with our evening party?",
      "should_trigger": true
    },
    {
      "query": "How do I say no to a sponsor who wants two more seats at the maintainers' dinner without torching the relationship?",
      "should_trigger": true
    },
    {
      "query": "Is it even worth doing a separate private thing, or should we just look after them properly at the main evening?",
      "should_trigger": true
    },
    {
      "query": "We have a back room at the venue. Should we use it for a small closed session with our board members?",
      "should_trigger": true
    },
    {
      "query": "What goes on the door list for a closed gathering, and what happens to that page afterwards?",
      "should_trigger": true
    },
    {
      "query": "How long do we keep the seat list for the invited dinner?",
      "should_trigger": true
    },
    {
      "query": "Our CEO wants to host a dinner for a handful of customers during the conference. How do we pick who gets asked?",
      "should_trigger": true
    },
    {
      "query": "How do we invite people to a closed session without the invitation turning into a public thread?",
      "should_trigger": true
    },
    {
      "query": "Should the roundtable go in the printed schedule marked invitation-only, or stay unlisted?",
      "should_trigger": true
    },
    {
      "query": "We promised a private reception in the prospectus and now everyone wants in. Help.",
      "should_trigger": true
    },
    {
      "query": "Who should actually be the person sending the invitations for our closed lunch?",
      "should_trigger": true
    },
    {
      "query": "A sponsor is asking us to add their customer to the invited dinner as a favour. Do we?",
      "should_trigger": true
    },
    {
      "query": "Our room holds fewer people than we want to invite to the closed session. How do we cut the list?",
      "should_trigger": true
    },
    {
      "query": "How do we stop a small private gathering from reading as a status tier to everyone else at the event?",
      "should_trigger": true
    },
    {
      "query": "Can we hold the small dinner offsite on the same night as the community party?",
      "should_trigger": true
    },
    {
      "query": "The hotel staffs the floor our closed reception is on and won't work from our guest list. What now?",
      "should_trigger": true
    },
    {
      "query": "We're doing a closed breakfast for six people. What does the invitation actually need to say?",
      "should_trigger": true
    },
    {
      "query": "What do we measure afterwards to know whether the closed gathering was handled properly?",
      "should_trigger": true
    },
    {
      "query": "How do I make sure every sponsor who asked for seats gets the same answer from us?",
      "should_trigger": true
    },
    {
      "query": "My co-organiser invited someone to the private dinner without telling me and now we're over capacity. Can we un-invite them?",
      "should_trigger": true
    },
    {
      "query": "Our event is community-run and anti-hierarchy, but a big funder is coming. Do we owe her a separate room?",
      "should_trigger": true
    },
    {
      "query": "We already know we owe a visiting official a proper reception. How do we actually run the room?",
      "should_trigger": true
    },
    {
      "query": "Who decides at the door if someone turns up who isn't on the list?",
      "should_trigger": true
    },
    {
      "query": "Is a lunch break long enough for a closed-door conversation, or does it need its own evening?",
      "should_trigger": true
    },
    {
      "query": "We want a conversation to happen between five specific people and nobody else. How do we set that up at the conference?",
      "should_trigger": true
    },
    {
      "query": "How do we write the refusal so it doesn't read as a judgment about the person who was nominated?",
      "should_trigger": true
    },
    {
      "query": "Our sponsor agreement sold four seats at the partner lunch and we also have people just asking for seats. Do the same rules apply to both?",
      "should_trigger": true
    },
    {
      "query": "How many seats should we give each sponsor at the invited dinner?",
      "should_trigger": true
    },
    {
      "query": "Do we tell people there's a closed room, or just not mention it at all?",
      "should_trigger": true
    },
    {
      "query": "We run a vendor conference and a private room for key accounts is normal for us. What's the mechanic?",
      "should_trigger": true
    },
    {
      "query": "The venue's side room is basically a fishbowl, everyone can see in. Does that kill the idea?",
      "should_trigger": true
    },
    {
      "query": "How do we handle someone turning up whose name isn't on the door list, without making a scene?",
      "should_trigger": true
    },
    {
      "query": "Should the guest list for the closed dinner be shared with the whole organising team?",
      "should_trigger": true
    },
    {
      "query": "We're inviting a few people to something small during the conference. What do we need to have decided before the first invitation goes out?",
      "should_trigger": true
    },
    {
      "query": "Does a visiting deputy mayor count as someone we need to receive specially, or is that overkill?",
      "should_trigger": false
    },
    {
      "query": "How deep should the escort be for a minister visiting our conference for two hours?",
      "should_trigger": false
    },
    {
      "query": "Should we print VIP badges or set aside reserved seating for our sponsors' executives?",
      "should_trigger": false
    },
    {
      "query": "A guest is bringing their own security detail. How do we coordinate with them?",
      "should_trigger": false
    },
    {
      "query": "What's the test for whether somebody actually counts as a VIP at a community event?",
      "should_trigger": false
    },
    {
      "query": "What catering service style should we use for a 500-person conference lunch?",
      "should_trigger": false
    },
    {
      "query": "Should our conference be dry, or serve alcohol at the evening event?",
      "should_trigger": false
    },
    {
      "query": "What should actually be in a 30-minute coffee break?",
      "should_trigger": false
    },
    {
      "query": "Do we need to run an evening event at all on day one?",
      "should_trigger": false
    },
    {
      "query": "How do we cover vegan, halal and gluten-free across the whole event's catering?",
      "should_trigger": false
    },
    {
      "query": "Can we run two social activities in the same evening slot, or do they have to be on separate nights?",
      "should_trigger": false
    },
    {
      "query": "How many official social occasions should a three-day conference have?",
      "should_trigger": false
    },
    {
      "query": "How do we publish the social track so a non-drinker knows which activity is for them?",
      "should_trigger": false
    },
    {
      "query": "What's the inclusion floor our whole slate of social activities has to clear?",
      "should_trigger": false
    },
    {
      "query": "A user group wants to run a meetup during our conference week. Do we approve it?",
      "should_trigger": false
    },
    {
      "query": "Someone is using our event's name on their own afterparty page. What do we do?",
      "should_trigger": false
    },
    {
      "query": "What disclaimer should we put on third-party fringe events around our conference?",
      "should_trigger": false
    },
    {
      "query": "A sponsor wants to throw their own party on the Wednesday. What do we ask them for before we say yes?",
      "should_trigger": false
    },
    {
      "query": "How do we track everything a signed platinum sponsor was promised?",
      "should_trigger": false
    },
    {
      "query": "When should we release sponsor perks relative to payment landing?",
      "should_trigger": false
    },
    {
      "query": "What should go in the post-event sponsor report before we ask for a renewal?",
      "should_trigger": false
    },
    {
      "query": "How do we price a gold sponsorship tier for a 900-person conference?",
      "should_trigger": false
    },
    {
      "query": "What clauses belong in our event sponsorship agreement?",
      "should_trigger": false
    },
    {
      "query": "What do we send a speaker the week after they accept?",
      "should_trigger": false
    },
    {
      "query": "How should we run the speakers' dinner at our conference?",
      "should_trigger": false
    },
    {
      "query": "Do we need a green room, and what goes in it?",
      "should_trigger": false
    },
    {
      "query": "How do we match buyers and sellers for 1:1 meetings at our event?",
      "should_trigger": false
    },
    {
      "query": "How many meetings can we honestly promise a sponsor in their package?",
      "should_trigger": false
    },
    {
      "query": "How do we absorb a no-show on a booked 1:1 meeting slot?",
      "should_trigger": false
    },
    {
      "query": "Build me a minute-by-minute run of show for day one.",
      "should_trigger": false
    },
    {
      "query": "Two of our tracks clash for the same audience. How do I fix the grid?",
      "should_trigger": false
    },
    {
      "query": "How long should the gap be between the last session and the evening event?",
      "should_trigger": false
    },
    {
      "query": "How should our check-in desk and badge pickup work?",
      "should_trigger": false
    },
    {
      "query": "Where should the quiet room go in the venue?",
      "should_trigger": false
    },
    {
      "query": "A guest uses a wheelchair and the room we picked is up a flight of stairs. What do we do?",
      "should_trigger": false
    },
    {
      "query": "Does our code of conduct cover parties that aren't at the venue?",
      "should_trigger": false
    },
    {
      "query": "Should we run an invite-only executive dinner instead of a user conference this year?",
      "should_trigger": false
    },
    {
      "query": "Is a multi-city roadshow better than one big summit for our developer audience?",
      "should_trigger": false
    },
    {
      "query": "How do we shortlist venues for a 600-person conference?",
      "should_trigger": false
    },
    {
      "query": "What should we ask a catering vendor for in an RFP?",
      "should_trigger": false
    },
    {
      "query": "How do we keep our conference feeling community-run as it grows?",
      "should_trigger": false
    },
    {
      "query": "Should we do early-bird pricing or a flat ticket price?",
      "should_trigger": false
    },
    {
      "query": "We want to run a standalone invite-only dinner for 20 prospects in Amsterdam, no conference attached. How do we shape it?",
      "should_trigger": false
    }
  ]
}

# Invitation and door mechanics

Do not invent quantities in any field below. No seat count, no lead time, no cap, no headcount - each reads as a benchmark once invented.

The field lists, the door page and every line of sample copy here are this skill's own construction, not wording lifted from an event. Keep the shape; rewrite the words. One principle shapes all of them: nothing in this file should outlive the event it serves unless the organizer chose to keep it.

## The seat list

Build it only once Menu A has landed above the fold. The fold deliberately has no list, which is both its cheapness and the reason every invitation it issues is verbal and unrecorded.

Fields, and nothing beyond them:

- **Name**, as the person or their office writes it.
- **Why this seat exists**, in one sentence. Not a rank, not a title, not "important to us". A row whose sentence has to be invented is a row that comes off the list.
- **Who put the name forward** - the host, a sponsor, a speaker, a team member - and the date. This is the field that makes a refusal defensible later, because it records which asks were made and which rule was applied to each.
- **Answer given**, and the date it was given. A seat offered and a seat confirmed are different states and conflating them is how a room ends up over-promised.
- **Access requirements**, only where the person supplied one: a fixed window, a route, a dietary need, a discretion request quoted from whoever stated it.

Three rules govern the artifact itself:

- **The deletion date is set when the list is created**, by the named owner, in the same pass. Default: the day the post-event follow-ups go out. A seat list carrying dietary answers and quoted requirements is a named-person record, and it is the artifact hardest to justify holding and easiest to forget.
- **The list never records a judgment about a person.** Every field is either a fact somebody supplied or a decision you made and can defend. This is what keeps it survivable if it leaks.
- **Circulation is by need.** Whoever works the door needs names and nothing else - not the reasons, not who nominated whom, and never the refusals.

## Issuing the invitation

One rule does most of the work: **the person who holds the list is the person who invites.** An invitation issued by anyone else is a seat allocated by someone who cannot see how many are left, and it is the single most common way a room gets over-promised.

Send it individually and privately. A group thread turns the guest list into a published document, which is the Menu B decision made by accident in the direction that menu exists to avoid.

What the message carries:

- **What the gathering is**, in plain words, without the word "VIP" and without a superlative. Illustrative: "A small room over the lunch break, so you can talk to the people you came to talk to" is complete.
- **When and where**, with the room named and the way in described - because the alternative is a guest arriving at a door they cannot identify and asking a general attendee about it.
- **Who else will be there**, in shape rather than by name unless every person on the list has agreed to be named. Some guests decide on this fact alone; some would decline to be listed to anyone.
- **What it costs them**, meaning what they will miss on the public programme.
- **How to say no**, made easy and made explicit. A guest who cannot decline cheaply accepts and does not come, which is worse than a decline.
- **One name and one way to reach it**, answered from the day before until the gathering ends.

Never publish the wording anywhere the general audience reads. The listing rung on Menu B is a deliberate decision with its own promotion condition, not something an invitation drifts into.

## Refusing an ask

Every asking party gets an answer, and the same rule is cited to each. That sentence is the whole of the defensibility this skill is built to buy, and it is cheap only if the rule was written before the first ask arrived. A conference-dinner host describes this exact review-and-refuse process: he manually reviews every RSVP against the room's purpose, and where someone does not fit, their access is respectfully declined. The two lines below standardize that discipline rather than leaving it to whoever is on the door that day.

Two illustrative lines, both refusing without making the refused person the reason:

- To a party who nominated somebody: _"The room seats what it seats, and we allocated it on <the rule>. I can't add a seat, but here is what I can do instead."_ Name the rule out loud. A refusal with no rule behind it reads as a judgment about the person nominated, and it is the version that generates a grievance.
- To a party who was already told yes by somebody else on your team: honour it, then fix the process rather than the guest. Withdrawing an accepted invitation costs more than the seat did, and the reversibility was spent the moment the yes was sent.

Always pair the refusal with the alternative that is genuinely available - the general evening, an introduction made during a break, a scheduled conversation. A refusal with nothing attached is where a sponsor relationship gets damaged over a seat nobody would have remembered.

Where the seats were **sold** rather than requested, this is not a refusal at all. A gathering promised inside a signed agreement is a deliverable, and it belongs to `samber/dev-event-organizer-skills@event-sponsor-fulfillment` against that agreement, not to this skill's allocation rule.

## Working the door

One person, one list, one printed page. Written by the named owner, never improvised on the day.

- **The names**, alphabetically, and nothing else on the page.
- **What to do with a name that is not on it**: take the name, say the owner will come, and go and get them. Never turn somebody away with an explanation, and never let the door-holder adjudicate - that is the owner's decision and it needs the list to make.
- **What to say to a curious attendee**, illustrative: _"It's a private meeting, it'll be done shortly."_ Short, true, complete. An explanation invites a negotiation about a seat.
- **Never say "VIP"**, to a guest or to anyone else, including on the radio. The word is the tier; once it is in the team's vocabulary the treatment follows it.
- **Never read the list aloud** or hold it face-out. The list working correctly is a list nobody else sees.
- **What happens at the end**: the door-holder hands the page back to the owner. It does not go in a bin in a public room.

## The fold, done properly

Menu A's default is that no separate gathering exists. That is a decision with its own mechanics, not an absence, and doing it badly is how it acquires the reputation of being the lazy answer.

- **Name the person who will be standing with the guest** when they walk into the general evening, and for how long. The failure mode of the fold is a guest left holding a drink at the edge of a room, which is worse than not inviting them.
- **Make the introductions the gathering would have made.** Write down, before the evening, which conversations were the actual point - name them individually rather than as a goal, and make those happen by walking up to people. This is the whole of what a private room buys, and most of it carries over.
- **Give them a way out**: a stated time you will walk them to the door, so leaving needs no excuse.
- **Say nothing about any of it.** The fold's advantage over every other rung is that it produces no artifact, no door and no list - and announcing that a guest is being looked after re-creates the tier for free.

---
name: event-vip-social-program
description: Run the private gathering alongside a public technical event, once a named-guest programme already exists - how the seat list is assembled when sponsors, speakers and the organizer all put names forward, how invitations and the door work without publishing a tier, and where the gathering sits against the public programme. Use whenever the user mentions a private dinner or reception at a conference, refusing a sponsor's seat request, an invite-only room without a VIP badge, or when to schedule one - even if they never say "VIP". Folding it into the general evening is the default answer. Do NOT use to decide whether a guest qualifies - use samber/dev-event-organizer-skills@event-vip-management; food is samber/dev-event-organizer-skills@event-hospitality.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# Event VIP Social Program

You run a room that not everyone can walk into, at an event where everyone can walk into everything else. Three decisions, and only three, cover the job:

- How the seat list gets assembled when more than one party is putting names forward.
- How the invitation and the door work without publishing that a tier exists.
- Where the gathering sits against the public programme.

The default answer is that there is no separate room. That is a rung on the first menu, not a refusal to help, and at a community-run event it is the most common correct outcome.

## How little this skill owns, and why that is deliberate

Almost everything a reader means by "VIP social programme" already has an owner. What is left is narrow.

- **Whether a named-guest programme exists at all → not yours.** `samber/dev-event-organizer-skills@event-vip-management` decides it, on a test it states as an **obligation, never a title**, and its own most common correct answer is that nobody is left in scope. It also owns the escort depth, the guest's own visibility, and the obligation roster.
  - Run it first. If it finds nobody, this skill has nothing to do.
- **What is served, and whether an evening exists → not yours.** `samber/dev-event-organizer-skills@event-hospitality` decides the catering style, the alcohol posture, and whether an evening or social programme exists at all. Its reference file already separates the two artifacts you are standing between: `"the evening event" and "an invited dinner" are different artifacts`; it designs only the first.
- **The speakers' dinner → not yours.** `samber/dev-event-organizer-skills@event-speaker-experience` owns it, on its own budget line, and `event-hospitality` says from its own side that it will `never re-decide a speakers' dinner, a volunteer meal or a VIP table`. That budget line describes speakers and nobody else. Never carry it over to the rungs below.
- **A gathering that was sold → not yours to allocate.** `samber/dev-event-organizer-skills@event-sponsor-fulfillment` delivers what a signed agreement promised, gated on payment. Be precise about the split, because it is easy to get backwards:
  - A sponsor _asking_ for seats at your gathering is this skill's allocation problem.
  - A gathering the agreement _sold_ is that skill's deliverable, and you do not get to ration it.
- **Somebody else's party → not yours.** `samber/dev-event-organizer-skills@event-side-event-coordination` approves and deconflicts events run by third parties, and states the seam from its own side: `Where that skill's evening is the thing you provide, yours is the thing you permit.` A sponsor-hosted reception is theirs. Yours is a room you host.
- **The social track everyone can join → not yours.** `samber/dev-event-organizer-skills@event-official-social-program` designs the announced social programme for the whole audience. If the honest answer to "who is this for" is "anyone who wants to come", you are in that skill, not this one.
- **Choosing an invite-only dinner as the whole event → not yours.** `samber/dev-event-organizer-skills@business-event-formats` picks between company-run shapes where the dinner _is_ the event. Here the dinner is a room inside somebody else's conference.

What survives all of that is the private-gathering mechanics, and only those. `event-vip-management` hands them over explicitly and then designs none of them: `A guest's table is therefore yours; the food on it is not.` This skill is that table.

## How to use the menus and defaults

Every ranking below is a default, not a law - it shifts with context and with who executes it. After the interview, re-rank all three menus against what you already know. Any of these overturns a default rung:

- A venue with a side room.
- A team member who already owns the relationship with whoever is asking for seats.
- A list that survived from last edition.
- An organizer who already knows every guest personally.

No quantity is prescribed anywhere - no seat count, no cap, no lead time, no headcount - because invented numbers read as benchmarks. Every number that does appear is either quoted from published guidance or a reader's own words about their own room, never a threshold this skill sets.

## The named owner

Designate one contact person who holds the seat list, builds it, sends the invitations, works the door, and answers every refusal. Governance and organizational practice establish the pattern. That same person decides any exception to the list at the door.

- Carries over to a private gathering: the role.
- Does not carry over: a protocol office's own staffing, or its authority over a building.

## Interview

Ask one question at a time, multiple-choice where possible. Questions 4, 7 and 8 exist because the menus below diverge sharply on time-to-effect, durability and effort ceiling - those defaults cannot be picked for the user.

1. Has `samber/dev-event-organizer-skills@event-vip-management` already run, and did it find anybody in scope? If not, stop and run it. It decides whether a named-guest programme exists at all, and this skill assumes that answer rather than re-deciding it.
2. Who owns the event and what does its register say about status - flat and explicitly anti-hierarchy, or comfortable recognizing who is in the room?
3. Name each guest the gathering exists for, and say in one sentence what the room does that the general evening cannot. For each: did they, or their office, ask not to be identified, listed or photographed?
4. How long until doors, and are the room booking, the schedule and any printed programme still open? Does any guest have a fixed arrival or departure window, and does any existing slot fit inside it?
5. Who else is asking for seats - sponsors, speakers, board members, your own team - and what did each ask for, in their words? Has anybody already been told yes, and by whom?
6. What does the room seat, and who set that number: the venue, the budget, or the conversation you actually want to have?
7. Who owns this by name - builds the list, sends the invitations, works the door, and answers the party who gets refused? Are they also running the main event that day? Reversibility is not symmetric here: a seat can be added, and an issued invitation cannot be withdrawn without costing more than the seat did.
8. One-off, or does this recur edition after edition? And has anything about it already been published or promised, in what artifact - a prospectus, an agreement, a schedule, an email?
9. Which assets re-rank the defaults: a venue with a usable side room, a team member who already holds the relationship with whoever is asking, a list from last edition?

## Community vs vendor pole

Who owns the event moves one menu, on the same community-versus-vendor split the rest of this collection argues.

- **Community pole.** A room not everyone can enter contradicts the register `samber/dev-event-organizer-skills@event-cultural-identity` sets. Menu A's fold is not a compromise at this pole. It is usually the right answer, and the burden sits on whoever wants the room to name what it does that the general evening cannot.
- **Vendor/corporate pole.** A private room is ordinary and often the reason a guest came. The seats are then scarce for a stated reason, and the defensibility half of Menu A's value carries most of the weight.

Say which pole a recommendation assumes wherever they differ. The pole moves Menu A's default and nothing else. Menus B and C hold their order across both.

## Workflow

1. Run the interview. If Q1 says no named-guest programme exists, stop and route to `samber/dev-event-organizer-skills@event-vip-management`.
2. Answer Q3's second half first: what does the room do that the general evening cannot? If nothing survives that question, Menu A's default is the answer and the rest of this skill does not run.
3. Set the seat-list construction rule (Menu A). Then build the list - its fields, its named owner, its circulation, and its deletion date, decided now - from [references/invitation-and-door-mechanics.md](references/invitation-and-door-mechanics.md).
4. Set the invitation and access mechanics (Menu B). Issue invitations from the same reference: individually, privately, by the person holding the list.
5. Set the placement against the public programme (Menu C), then hand the slot to `samber/dev-event-organizer-skills@event-run-of-show` and the grid clash to `samber/dev-event-organizer-skills@event-schedule-design`. Tell them the slot. Never move a public session to make room for a private one.
6. Write the refusal rule down before the first ask arrives, and cite the same one to every party. The rule is the whole of the defensibility, and it is cheap only in advance.
7. Hand off what is not yours:
   - Catering and drink for the room: `samber/dev-event-organizer-skills@event-hospitality`.
   - Any access need: `samber/dev-event-organizer-skills@event-accessibility-inclusion` - a guest who cannot enter the room is an access question first.
   - Anything a guest's own security detail requires: `samber/dev-event-organizer-skills@event-vip-management`.
   - The code-of-conduct reach over a private room: `samber/dev-event-organizer-skills@event-code-of-conduct`, which decides which spaces its scope clause covers.
8. Present section by section - purpose, list rule, list, invitation and door, placement, refusal rule - and get explicit approval per section before finalizing.

If your harness has persistent memory, record per edition:

- What the room was for.
- Who asked for seats, and what each was told.
- Which rule was cited.
- Whether the list was deleted on its date.
- Whether any attendee mentioned the room afterward.

Next edition starts from that instead of re-arguing the same asks.

## Menu A - seat-list construction rule

How the list gets assembled when the organizer, sponsors and speakers all have names to put forward. Two value axes run close to opposite, which is why this menu prints two value orderings rather than one.

- effort (organizer-hours, arbitration between asking parties, the conversations a refusal costs, records kept): `open nomination with published criteria and a host veto > host list + capped nominations per asking party > host-nominated only > no separate list`
- value, the room is right (the people the gathering exists for are actually in it): `host-nominated only > host list + capped nominations > open nomination with criteria > no separate list`
- value, the answer is defensible (every party who asked can be told why, and the same rule was applied to each): `open nomination with criteria > host list + capped nominations > no separate list > host-nominated only`
- compliance cost (review triggered, reversibility spent): `open nomination with criteria > host list + capped nominations > host-nominated only == no separate list`
- efficiency: `no separate list > host list + capped nominations > host-nominated only > open nomination with criteria`

**Dominance check: four rungs, six pairs, zero strict dominance relations - and two distinct mechanisms account for all six, not one.**

Four pairs are blocked because the two value axes run opposite, and in each the rung that puts the right people in the room is the rung whose rule is hardest to defend:

- Open nomination against capped nominations.
- Open nomination against host-nominated only.
- Capped nominations against host-nominated only.
- Host-nominated only against the fold.

The remaining two pairs are blocked by cost rather than by opposition, the busier rung winning both value axes and losing on effort:

- Open nomination against the fold.
- Capped nominations against the fold.

This menu is **clean by construction on four pairs and by a cost trade on two, which is not a pass either way**. The efficiency line rests on each rung's own argument below.

The compliance `==` is argued: compliance is the one axis on which the two cheap rungs come out equal, since effort already separates them and this axis deliberately does not.

- **Host-nominated only:** creates a small named-person list carrying one retention decision. A list nobody was told about can still be shortened - it holds an artifact and spends no reversibility.
- **The fold:** holds no artifact at all. Every invitation it issues is verbal, unrecorded and impossible to withdraw cleanly - it spends reversibility and holds nothing.

Equal exposure, opposite halves. The two busier rungs sit above both because capped nominations means holding names a sponsor supplied about somebody else, and published criteria are a commitment you can be held to next edition.

- **No separate list** - the default: there is no private gathering, and the guest is walked into the general evening by a named person. It is also the only rung that cannot produce a tier.
  - It wins the ratio because near-zero effort only pays when what the rung buys is still non-zero, and here it usually is. Most of what a private room buys is a short, nameable set of conversations, and those can be made by walking up to people.
  - Done properly, it has its own mechanics in the reference file: a named companion, the introductions written down in advance, a stated exit time. Done lazily, it is a guest holding a drink at the edge of a room, which is worse than not inviting them.
  - **Promotion condition, keyed to Q3:** move up one rung when Q3 names something the room does that the general evening genuinely cannot - a discretion request a public room breaks, or a conversation that needs a fixed set of people and no others. "It would be nice for them to meet" is not that, and it is the answer this question exists to catch.
- **Host list + capped nominations per asking party** - the organizer builds the list, and each asking party gets the same stated allowance. Second on both value axes and second on effort, it wins the ratio over host-only because the asks arrive whether or not you have a rule for them.
  - The cap is the cheapest artifact that turns every ask into one answer, and it costs one number and one sentence over building the list alone.
  - Published event-planning guidance for exactly this scenario states the same mechanic: agree a funding party's allocation as a number before any money changes hands, since "you have 20 spots" is a different conversation than "who would you like to invite."
  - **Promotion condition, keyed to Q5:** this is the rung whenever Q5 names more than one party already asking for seats.
- **Host-nominated only** - the organizer builds the list and accepts no nominations. Tops the room-is-right axis, because nobody knows the must-have names better than the host and every seat given to a nomination is a seat the host did not allocate.
  - It sits third on efficiency because its saving is real, and the grievance it generates lands precisely on the relationships the room was meant to serve.
  - **Promotion condition, keyed to Q5:** this is the rung when Q5 finds no asking party at all - a cap nobody is asking against is an artifact built for nothing.
- **Open nomination with published criteria and a host veto** - the starved rung: top of effort, top of compliance cost, top of the defensibility axis, and efficiency never picks it. It also loses the room-is-right axis to every rung above the fold, because it selects on who applied rather than on who had to be there.
  - **Promotion condition, keyed to Q8:** promote it when Q8 says the gathering was already published or sold in an artifact people can read. Once something is promised in a document, an unpublished rule is the shape a complaint takes, and criteria stop being optional.
  - Seniority never promotes this rung, and neither does the size of a cheque.
- **Deleted when Q6 says the seat count was set by the venue or the budget rather than by the conversation: the open-nomination rung.** Delete it from this menu and from the axis lines above. Publishing criteria against a number you do not control is a promise you cannot keep, and it converts a capacity limit into a broken commitment.
- **Deleted when Q2 says a flat, explicitly anti-hierarchy register and Q3 names no obligation the general evening breaks: every rung except the fold.** Delete them from this menu and from the axis lines above.
  - Evaluate both halves separately: Q2 alone leaves a discretion obligation unmet, and Q3 alone at the vendor pole deletes nothing.
  - Where both hold, a private room at an event whose identity refuses tiers is the tier with a door on it - parked at the bottom of a menu, it returns next planning cycle as a proposal.

## Menu B - invitation and access mechanics

How the invitation goes out and how the door is worked. This menu decides whether _the gathering_ is legible; `samber/dev-event-organizer-skills@event-vip-management`'s visibility menu decides whether _the guest_ is.

Do not re-rank that one here, but decide the two together, because a published room makes a guest list a public tier even when every badge is identical.

- effort (production and print deadlines, distribution, the questions it generates, a person on a door): `shared credential > published listing with an invited-guests label > named door list > verbal invitation only`
- value, the door works (the right people get in and nobody else does): `named door list > shared credential > published listing > verbal invitation only`
- value, it does not read as a tier: `verbal invitation only > named door list > shared credential > published listing`
- efficiency: `named door list > verbal invitation only > shared credential > published listing`

**Dominance check: four rungs, six pairs, two genuine strict dominance relations - this menu is clean by care, and it is the only one of the three that could have failed.**

The named door list beats the shared credential on both value axes at lower effort, and beats the published listing the same way. The efficiency line honours both.

Of the remaining four pairs, three are blocked because the value axes run opposite:

- Shared credential against verbal invitation only.
- Published listing against verbal invitation only.
- Named door list against verbal invitation only.

One pair, shared credential against published listing, is blocked by cost instead: the credential wins both value axes while costing more.

In the named-list-against-verbal pair, the named list owns the door and verbal owns discretion, so only the efficiency ratio orders them.

No compliance-cost axis is printed, and the skip is argued: rung for rung it would reproduce the does-not-read-as-a-tier ordering exactly, adding a line and no information. What it would have carried is the asymmetry, and that belongs in the rungs themselves - a credential can be dropped next edition, and a room printed in the programme cannot be unpublished.

- **Named door list** - the default. One person holds one page of names at the door. The invitation went out individually and privately from that same person.
  - Publicly there is a closed door and somebody standing at it, and nothing else is legible.
  - It wins its menu outright: it is the only rung where the door actually works, and it is second on discretion behind doing nothing.
  - A professional association's own exhibitor policy states the same discipline as a rule rather than a preference: hospitality-suite access is invitation only from the event holder, and the organizer's own attendee list may never be used to promote the room.
  - Costs one person for the length of the gathering and one printed page. The page, the what-to-say lines, and what happens to a name that is not on it are in the reference file.
- **Verbal invitation only** - no list, no door, no artifact. Tops the discretion axis and sits second on efficiency: near-zero effort, and nothing exists that could leak. Its cost is that the door, if there is one, is worked on recognition, which is the worst possible admission rule - the one that turns away exactly the person nobody on your team happens to know.
  - **Promotion condition, keyed to Q5:** it holds whenever Q5 finds no asking party. With no competing asks, there is nobody a list has to be defensible against.
- **Shared credential** - a wristband, token or badge marker that admits its holder. A starved rung, strictly dominated by the named list: more effort, a worse door once one is lent or copied, and a visible object that attendees read as a rank while it is worn through the general event.
  - **Promotion condition, keyed to Q7:** promote it only when Q7 says nobody from your team will be on that door, because the gathering runs in a space somebody else staffs. A list they cannot read is not a door. A credential is the only thing a venue's own staff can check.
- **Published listing with an invited-guests label** - the room appears in the schedule, marked as invitation-only. The other starved rung, dominated by the named list and last on efficiency: it announces the room to everybody, controls nobody, and generates a stream of requests you then have to refuse.
  - **Promotion condition, keyed to Q8:** promote it when Q8 says the room is already published in an artifact people can read. At that point the listing is not a choice you are making - it is a description of what already happened, and the remaining work is the wording rather than the decision.
- **Deleted when Q3 names any guest who asked not to be identified, listed or photographed: the shared credential and the published listing.** Delete both from this menu and from the axis lines above. A credential worn through the public event and a room named in the programme each publish exactly what that guest asked you not to publish, and no wording fixes either.

## Menu C - placement against the public programme

When and where the room sits. Three rungs, because the fold is Menu A's decision and does not reappear here.

- effort (a second venue, transport, a headcount fixed before anyone travels, a room booking, an owner's evening): `a separate evening at a separate venue > after the last session, in a room at the main venue > inside an existing break or meal slot, in a side room`
- value, the conversation actually happens (people arrive, stay, and talk without a clock running): `a separate evening at a separate venue > after the last session > inside an existing break`
- efficiency: `inside an existing break > after the last session > a separate evening at a separate venue`

**Dominance check: three rungs, three pairs, zero strict dominance relations - and one mechanism, a cost trade, accounts for all three.** The value axis runs rank-identical to effort - more effort buys a deeper conversation - so every pair resolves the same way: the busier rung wins on conversation depth and loses on effort. That is the "blocked by cost rather than by opposition" category Menu A uses for its two cost-trade pairs, not two independent goods in tension.

Whether the guest's absence goes unnoticed is not a second, independent axis here. It runs exactly rank-identical to inverse effort. Printed beside conversation depth, it would make the zero-dominance result read as two goods disagreeing when it is one axis and its own mirror image, forcing the efficiency line to cheapest-first for a reason that looks like evidence and is not.

The conversation-depth axis stays printed because it carries each rung's actual argument, even though it does no dominance work on its own: it agrees with effort by construction. The efficiency line rests on the arguments below.

No compliance-cost axis, and the skip is argued: where the room sits triggers no review that where it sits changes. The reviews this subject does trigger attach to the list and to the door, and they are on Menu A and in the reference file.

- **Inside an existing break or meal slot, in a side room** - the default. It wins the ratio the way Menu A's fold does: near-zero incremental effort only pays when the conversation depth bought is still non-zero, and a short slot still buys a real one because the room and the people are already there. Its real limit is depth: a break ends whether the conversation did or not.
  - **Promotion condition, keyed to Q3:** move up one rung when Q3 says the room's purpose is a conversation among a named set of people rather than a greeting - a break holds a greeting and does not hold a conversation.
- **After the last session, in a room at the main venue** - second on the value axis and second on effort, so it never wins the ratio outright, and it is the rung most events that need a real room should land on. It buys a conversation with no clock while keeping everybody in one building. It has one specific failure, and it is the one to watch: scheduled against the general evening it turns that evening into the consolation room, which is the tier arrived at by calendar.
  - Real event-production practice runs the same logic at the level of the whole evening calendar, not just this one room: a named event producer sequences a multi-evening conference by audience rather than by venue - a first-timers night, an executive/VIP night and a general-admission night, each on its own evening rather than competing for the same one.
- **A separate evening at a separate venue** - the starved rung: top of effort, top of the conversation axis, and efficiency never picks it. Two promotion conditions apply, each evaluated on its own rather than as one trigger.
  - **Keyed to Q4:** promote when Q4 names a guest window that no slot inside the event's own day fits - at that point the choice is this rung or nothing.
  - **Keyed to Q9:** promote when Q9 says the venue has no side room that is not read as a room. This is an absent asset, not a preference, and the one case where offsite is the only place a private gathering can physically be.
  - Before committing to any offsite option, document its hard operating constraints - fixed capacity, an off-peak-only availability window, a surcharge for something the venue does not normally do - rather than stopping at "vendor contacted." A dealbreaker found after the invitation went out costs far more than the same finding at comparison time.
- **Deleted when Q7 says the named owner is also running the main event that day: the separate evening at a separate venue.** Delete it from this menu and from the axis lines above. A second venue with transport and a fixed headcount is a job, and a job with no free owner becomes the organizer's on the day, on top of running the event - which is the failure that takes the main event down with it.

## Failure modes

- **The private room scheduled opposite the general evening.** Everybody can see which room the interesting people went to, and the general evening becomes the consolation prize. If both exist, they do not overlap. A documented conference reception lost much of its expected crowd for the mirror-image reason: the session before it ended an hour before the reception opened, and attendees left the building rather than wait out the gap. The mechanism draining the room is the scheduling seam itself, not something specific to a private gathering.
- **Building a list for a room nobody could say the purpose of.** Q3's second half exists for this, and the honest answer is usually the fold.
- **Rationing seats that were sold.** A gathering promised in a signed agreement is a deliverable, and applying your allocation rule to it is a breach dressed as fairness. Route it to `samber/dev-event-organizer-skills@event-sponsor-fulfillment` and take it off the list.
- **Letting the seat count pick the list.** Capacity is a constraint, never a criterion. When the room is smaller than the purpose, shrink the purpose deliberately rather than letting the venue decide who mattered.
- **The invitation issued by somebody who does not hold the list.** The most common way a room gets over-promised, and the most expensive to fix, because an accepted invitation cannot be quietly withdrawn.
- **The credential that walks out into the general event.** A wristband worn for the rest of the day is a visible tier you did not decide to build, and it is legible to every attendee who did not get one.
- **Re-deciding whether the guest qualifies.** That test belongs to `samber/dev-event-organizer-skills@event-vip-management`, it is stated as an obligation rather than a title, and re-running it here produces two owners for one judgment.
- **The list that outlives the event.** A seat list carrying dietary answers and quoted requirements is a named-person record. The deletion date is set when the list is created, by name, in the same pass.
- **Refusing without a rule.** A refusal with nothing behind it reads as a judgment about the person nominated, which is the version that damages a relationship over a seat nobody would have remembered.
- **The gathering read as a sponsor-arranged meeting.** A speaker-and-partner dinner meant as informal networking is one small step from looking like a transaction the moment attendees suspect seats were sold for access. State the distinction in writing to whoever is invited and whoever asked for seats: this room is a relationship, not a meeting arranged on a sponsor's behalf.

## Measurement

No industry standard exists to calibrate these four signals against. Set your own targets before the event, and never adjust them after the data arrives.

- **Every asking party got an answer, and the same rule was cited to each (binary).** Check the list's nomination field against the parties Q5 named. A party with no recorded answer is the finding.
- **Discretion held (binary).** Zero guests who asked not to be identified were identifiable to a general attendee as having been in the room. Any published photograph, listing or credential bearing on one of them fails this outright.
- **Seats promised versus seats that existed (binary).** Zero invitations issued beyond what the room held. A single over-promise means the invitation went out from somebody who was not holding the list.
- **List deletion (binary).** The seat list is gone by its stated date, confirmed by the named owner.

## Invocation examples

- "Two sponsors and a keynote speaker have each asked us to add someone to the founders' lunch. How do we decide, and how do we say no to the others?"
- "We want a small room where our grant officer can actually talk to three people. When do we put it, and do we tell anyone it exists?"
- "Marketing wants an invite-only reception listed in the programme. Our conference is explicitly flat. What do I do?"
- "Someone on my team already told a sponsor yes and the room seats fewer than we've now invited."

Expected output: a gathering brief containing:

1. What the room does that the general evening cannot, or the finding that nothing survives that question.
2. The seat-list construction rule with its cap or criteria.
3. The list itself, with its fields, named owner, circulation and deletion date.
4. The invitation and access mechanics with the door page.
5. The placement, with the slot handed to the run of show.
6. The refusal rule, written before the first ask.
7. The handoffs.

Presented section by section for approval. Where Menu A lands on the fold, the output is that finding plus the fold's own mechanics, and nothing else.