event-learning-expedition-design
Decides whether to take your audience to someone else's building or office and what rules to set.
Installation
Paste this into Claude Code, Cursor, or any agent that can run commands.
SKILL.mdShow the author's original SKILL.md
--- name: event-learning-expedition-design description: Decide whether to take a technical audience into an organization the organizer does not control, and on what terms - when a host's own premises, operation and staff are the programme rather than a room rented and filled by the organizer. Sets the host-dependency posture (host speaker hosted in-house, one host site host-led or to a negotiated agenda, a multi-host circuit) and the access posture, meaning what the host lets attendees see and repeat afterwards. Use whenever asked to design a learning expedition, company tour, field trip, site-visit programme or executive immersion. Do NOT use for catering - use samber/dev-event-organizer-skills@event-hospitality - or multi-venue logistics - use samber/dev-event-organizer-skills@event-production. States no legal threshold or instrument. license: MIT metadata: author: Samuel Berthe version: "1.0.1" --- # Event Learning Expedition Design You take your own audience into somebody else's building, where that organization's working operation is the programme. Two decisions follow, and this skill owns nothing else: how much of your agenda depends on a host you cannot direct, and what the host lets your attendees see and repeat. ## Read first: the scope is much narrower than the name A "learning expedition" sounds like a whole event format. Inside this collection it is not, and pretending otherwise hands you advice a sibling skill gives better. Most of what the format is taken to include already has an owner here, and each owner covers it in more depth than this skill can: - **Several sites in one agenda.** Not a new mechanic. `samber/dev-event-organizer-skills@event-venue-sourcing`'s reference file settles it: multi-venue events _"inherit this whole sheet once per site, plus the transit time between them and a single named owner per site. That much is straightforward extension."_ Take the sheet from there. - **Transport and the headcount problem.** `samber/dev-event-organizer-skills@event-hospitality` ranks an offsite excursion below doing nothing at all: _"only one of them spends transport, a second building's own rules and insurance ask, and a headcount you cannot correct once the transport has left."_ That argument applies to you unchanged. One exception: a visit that is a social evening rather than the programme is that skill's subject, not this one's. - **Whether your policy reaches the coach and the host's floor.** `samber/dev-event-organizer-skills@event-code-of-conduct` owns the scope clause. Its reference file records MLH covering _"all hackathon venues, hackathon-related social events, hackathon-supplied transportation, and online interactions related to the event."_ and notes that _"a shuttle is neither the venue nor a social event"_. Hand it the sites and the vehicles, and take back the clause. - **Catering on the move, and every supplier who moves with you.** `samber/dev-event-organizer-skills@event-hospitality` for the service style, `samber/dev-event-organizer-skills@event-vendor-sourcing` for the contract. - **Who you invite and why.** `samber/dev-event-organizer-skills@business-event-formats`. Its shape ladder ranks the account-depth family, and its compliance axis carries the mechanic people reach for here: _"an accepted invitation cannot be withdrawn without insult, and it lands on the guest's own gift and anti-bribery policy before it lands on yours."_ A named guest with a protocol obligation is `samber/dev-event-organizer-skills@event-vip-management`; a journalist is `samber/dev-event-organizer-skills@event-press-relations`. - **Capturing the visit and publishing anything from it.** `samber/dev-event-organizer-skills@event-production` through the master file, then `samber/dev-event-organizer-skills@event-content-repurposing`. Its rights gate governs you: _"Silence is off-limits, not permission."_ - **Why the event exists, what it costs and how it is measured.** `samber/dev-event-organizer-skills@corporate-event-strategy`. Perception shift and pipeline influence are that skill's goal-and-measurement vocabulary, not yours. **What is left is one structural fact, and it is real.** Everywhere else in this collection, a third party supplies either the room or the content. `samber/dev-event-organizer-skills@event-venue-sourcing` gets you a room you then fill. `samber/dev-event-organizer-skills@event-side-event-coordination` handles an event somebody else runs for their own reasons - _"Where that skill's evening is the thing you provide, yours is the thing you permit."_ Here the host supplies **both**. So a host who withdraws does not cost you a room you can re-book: it deletes the programme. Nothing in the collection covers that. Nothing covers what a host organization - which is not a speaker, not a sponsor and not a vendor - permits your attendees to see and to repeat. The consent chain this collection runs on goes organizer to speaker, and it has no branch for the organization that opened its floor. Route any question other than those two decisions to the owners above, and stop. This skill is short because those two decisions are all it owns. Do not invent a number for any deliverable built from this skill. A site count, group size, briefing length, lead time, or host-approval turnaround is the host's to state, and an invented number outlives the caveat attached to it. Describe the constraint qualitatively and ask the host. This skill states no legal threshold, jurisdiction, form, instrument name or monetary figure. That is the standing policy `samber/dev-event-organizer-skills@event-side-event-coordination` holds for liability and `samber/dev-event-organizer-skills@hackathon-cash-prize` holds for prize law. The access-posture rungs describe postures, not instruments, and any paper they need is counsel's to name. ## Interview Ask one question at a time, multiple-choice where possible. Every condition on both menus names the question it is keyed to, so answer these before ranking anything. 1. Has a host organization agreed in writing to receive your audience, or is this a format idea with nobody's yes behind it? If there is a yes, was it conditioned on anything? 2. Why does the audience need to be physically there: is there a thing that cannot be shown on a slide - a floor, a hall, hardware, a scale, a failure - or is the draw the people and the conversation? 3. What is the audience's own question: a specific technical one they could push a named engineer on, or an experiential one about how an organization operates day to day? 4. Inside the host, who is the named counterpart, and can that person commit their colleagues' time, or only their own? 5. Has the host stated a restriction - an area, a customer name, a photography rule - and did that come from someone who speaks for the host, or from your own assumption about what they would want? 6. Is the attendee list bounded and known before the day, or open until the door? 7. Who, by name, would run a post-event clearance queue, and for how long after the event would they still be doing it? 8. What is the effort ceiling and the date: how many people can own this end to end, how much runway exists, and how survivable does a host's cancellation have to be? 9. What already exists that the default ordering assumes away: a standing relationship with a candidate host, an organizer employed by one, a prior edition's expedition, or an agreement already signed with any of them? Both rankings below are defaults, not laws, and they shift with context and with who executes them. Re-rank against Q9 before recommending anything: an organizer who already works inside a candidate host turns a cold approach into a calendar invitation, and promotes that rung above whatever the default picked. ## Workflow 1. Run the interview, Q1 first. If nobody has said yes, you are choosing a format rather than designing one, and `samber/dev-event-organizer-skills@business-event-formats` owns that choice. 2. Route out everything in the scope section above before going further. Most of what arrives as "design our learning expedition" leaves before either menu is reached. 3. Fix the value axis on the first menu from Q2 and Q3 before ranking it. This is the mechanic `samber/dev-event-organizer-skills@business-event-formats` uses for its own shape ladder - take it from there rather than re-deriving it. 4. Pick the **host-dependency posture**, applying its delete rules before ranking. 5. Pick the **access-and-repeatability posture**, applying its delete rules before ranking. 6. Write the host brief: what your audience is coming to understand, what you are asking their people to do, and what you have told your attendees they may repeat. Send it before the host's internal approvals start, not after. 7. Hand off, explicitly and by name: - Sites and vehicles to `samber/dev-event-organizer-skills@event-code-of-conduct`, for the scope clause. - The per-site requirements sheet to `samber/dev-event-organizer-skills@event-venue-sourcing`. - Transport, catering and the headcount to `samber/dev-event-organizer-skills@event-hospitality` and `samber/dev-event-organizer-skills@event-vendor-sourcing`. - Anything recorded to `samber/dev-event-organizer-skills@event-production`. - Goals and measurement to `samber/dev-event-organizer-skills@corporate-event-strategy`. 8. Present each decision for validation before anything is promised to a host or published to attendees. A host's approval process is the point of no return: once their people have blocked the time, a change costs their goodwill, not your calendar. If your harness has persistent memory, record which host said yes and on what condition, the access posture agreed and who agreed it, and the restriction list. A host relationship is the only durable asset this format produces, and the one thing the next edition cannot rebuild from a document. ## Host-dependency posture How much of the agenda depends on an organization that has no obligation to you. Four rungs: - **Host representative in your own room**: you invite their engineer to speak where you already control the room. No site. - **One host site, host-led**: you go to them and they show what they show visitors. - **One host site, negotiated agenda**: you specify what your audience needs to see and they build to it. - **Multi-host circuit**: several host organizations in sequence. Two value axes, and they genuinely disagree. That is why Q2 and Q3 have to be answered before this menu is ranked. - effort (securing a host with no reason to say yes, briefing their staff, transit between sites, a headcount fixed before departure, an escort per site, and the rebuild when one host withdraws): `multi-host circuit > one host site, negotiated agenda > one host site, host-led > host representative in your own room` - value, **place** - what the audience sees on site that no talk reproduces: `multi-host circuit > one host site, negotiated agenda == one host site, host-led > host representative in your own room` - value, **fit** - the audience's own question gets answered, in their vocabulary, by someone they can push: `one host site, negotiated agenda > host representative in your own room > one host site, host-led == multi-host circuit` - compliance cost, as the review it triggers on the _host's_ side - visitor screening, site safety induction, their own confidentiality and customer-data rules - and what stops being reversible once your audience is standing in their building: `multi-host circuit > one host site, negotiated agenda > one host site, host-led > host representative in your own room` - efficiency, **place per unit effort**, the line to use when Q2 names a physical thing: `one host site, host-led > one host site, negotiated agenda > multi-host circuit > host representative in your own room` - efficiency, **fit per unit effort**, the line to use when Q3 names a specific technical question: `host representative in your own room > one host site, negotiated agenda > one host site, host-led > multi-host circuit` The place `==` is argued: a host-led visit and a negotiated one both put the audience inside one real building, and the building is what the axis measures. They differ in what is shown there, which is the other axis's job. The fit `==` is argued too, and at the same level rather than at zero: a host-led agenda is a host-led agenda whether the audience sees one of them or a sequence of them, so a circuit multiplies places without improving the answer to anybody's question. That tie does not survive division: equal fit at strictly higher effort is strictly worse fit-efficiency. That is why the circuit sits last on that line rather than level with the host-led rung. Compliance tracks effort rung for rung here. Admit that rather than presenting it as a second signal: both scale with how far inside somebody else's organization you go, and with how many organizations that is. The axis stays because the exposure is real - a host's screening and induction requirements are theirs to set and you cannot negotiate them down - but it discriminates nothing the effort axis did not already say. **Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations.** Covering all six takes two mechanisms, and one alone would cover only half: - **Blocked by opposed value axes (3 pairs):** own-room against host-led, own-room against the circuit, negotiated against the circuit. In each, whichever rung leads on place trails on fit. - **Blocked by cost alone (3 pairs):** own-room against negotiated, host-led against negotiated, host-led against the circuit. In each, the rung ahead leads on both value axes (tying one of them in the last two) and still costs strictly more on effort and on compliance. That accounts for all six. The two value axes are _not_ exact inverses of each other. They tie in different places, so this check carries real information rather than being clean by construction. - **One host site, host-led - the default.** It buys the whole "they were actually there" effect for the least coordination, and it is the rung a host can say yes to without convening anybody. **Promote it to the negotiated agenda when Q3 says the audience's question is specific _and_ Q4 names a counterpart who can commit their colleagues' time.** Both, not either: a specific question with nobody inside to route it produces a standard tour with your hopes attached. - **Host representative in your own room.** Tops the fit-efficiency line and costs almost nothing. When Q3 says the question is technical and specific, this is the honest recommendation: say so plainly and close this skill rather than designing travel around a conversation that fits in a session. **Delete it, from this menu and from every axis line above, when Q2 names a physical thing that cannot be shown on a slide.** A talk is not a smaller version of standing on the floor, and a deleted rung left at the bottom returns later as a cost saving. - **One host site, negotiated agenda.** The rung that answers a specific question, at the price of an internal owner inside the host. **Delete it, from this menu and from every axis line above, when Q4 finds no counterpart who can commit colleagues' time.** Without one it is not a cheaper negotiated agenda. It is the host-led rung plus meetings, which is the worst cell on this menu. - **Multi-host circuit - the starved rung.** Tops place, tops both cost axes, and neither efficiency line ever picks it. Promotion conditions are keyed to Q9 and Q8, each carrying its own weight: - **Q9**: standing relationships with more than one candidate host, so each additional site is a call rather than a cold approach. - **Q8**: enough runway that one host withdrawing does not collapse the day. Both conditions apply together, not either alone - a circuit built on cold approaches with no slack is the one configuration where a single withdrawal deletes the programme after the travel is booked. ## Access and repeatability posture What the host lets your attendees see, and what they may repeat afterwards. Four rungs: - **Open on the record**: nothing restricted. Attendees may photograph, write and speak freely. - **Named ground rules, no instrument**: a rule the organizer states and publishes, accepted by attending - a named area not photographed, nothing attributed to an individual, with nobody signing anything. - **Per-attendee written undertaking**: each attendee signs something before entry, on the host's terms. - **Host-controlled, organizer-relayed clearance**: attendees see freely, and the host reviews anything they want to publish afterwards, through you. - effort (negotiating with a host's legal function, collecting signatures, handling the person who refuses at the door, running a queue that outlives the event): `host-controlled, organizer-relayed clearance > per-attendee written undertaking > named ground rules > open on the record` - value, **access** - how much the host is willing to actually show: `per-attendee written undertaking > host-controlled, organizer-relayed clearance > named ground rules > open on the record` - value, **takeaway** - what an attendee can carry back and use without asking anyone: `open on the record > named ground rules > per-attendee written undertaking == host-controlled, organizer-relayed clearance` - compliance cost, as the review it triggers and the reversibility it costs: `per-attendee written undertaking > host-controlled, organizer-relayed clearance > named ground rules == open on the record` - efficiency, **access per unit effort**: `named ground rules > per-attendee written undertaking > open on the record > host-controlled, organizer-relayed clearance` - efficiency, **takeaway per unit effort**: `open on the record > named ground rules > per-attendee written undertaking > host-controlled, organizer-relayed clearance` The access ordering rests on one argument, and that argument stays genuinely contested. Its claim: what a host shows tracks how much residual risk the host still carries at the moment the audience walks in. An undertaking binds the room _before_ anyone sees anything, which is what actually unlocks a floor; a review-afterwards regime does not stop what was seen from being known, so it unlocks less despite feeling stricter. Two accounts bear on that claim, and they point in opposite directions: - **For a pre-entry instrument, and narrower than it sounds.** Securities law lets an issuer share material nonpublic information on a facility visit without triggering Regulation FD only when the visitor agreed to confidentiality beforehand, a legal permission with no after-the-fact equivalent. That is evidence a pre-entry instrument controls whether disclosure is _permitted_, not evidence that hosts show more once one is signed. - **Against the ordering, and the only documented account of what an NDA actually bought a visitor.** An engineer who signed a photography and social-media ban before a factory tour wrote that nothing he saw was information other, non-NDA visitors hadn't already published, and that the agreement's main effect was to raise his own sense of the visit's value rather than what he was shown. Treat the ordering as a defensible default, not a settled one: the strongest direct evidence on what hosts actually reveal runs the other way. For both accounts and the counter-cases beside them, read [references/precedent-and-evidence.md](./references/precedent-and-evidence.md). The takeaway `==` is argued: under both bottom rungs an attendee cannot repeat what they saw without somebody else's permission. They differ in who holds the pen and when, not in whether the attendee is free. The compliance `==` is argued at zero: neither of the top two rungs on that line creates any instrument or obligation at all, so neither triggers a review - they differ in what is said, not in what is signed. **The takeaway efficiency line discriminates nothing, and say so when using it.** It is rank-identical to inverse effort, so dividing takeaway by effort changes no position and the line collapses into cheapest-first - the one ordering a ranking exists to prevent. It stays the correct order when a freely repeatable takeaway is the whole point, but it cannot catch an error, so never let it pick the posture on its own. **Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations.** Covering all six takes two mechanisms: - **Blocked by opposed value axes (5 pairs):** open against ground rules, open against the undertaking, open against relayed clearance, ground rules against the undertaking, ground rules against relayed clearance. In each, the rung ahead on access is behind on takeaway. - **Blocked by a single cost axis (1 pair):** the undertaking against relayed clearance. The undertaking leads on access, ties on takeaway, and is _cheaper_ on effort, so effort does not block it and compliance is the only thing that does. Remove the compliance axis and the undertaking dominates relayed clearance outright. That accounts for all six. Be honest about what this check is worth. Access and takeaway are near-inverses of each other _by the nature of the subject_: what a host shows more of is what an attendee may repeat less of. So five of the six pairs are blocked by construction, and the undertaking-against-clearance pair is the only one where the check carries information - the pair a reader is most likely to get wrong. - **Named ground rules - the default.** What reassures a host is that somebody named is responsible for the room, not that a crowd of strangers each signed a page. It buys most of the host's willingness for a fraction of the cost of an instrument, and creates nothing anyone has to review. State the rules to attendees before they travel, not at the door - a rule someone learns after arriving is a rule you are asking them to accept under pressure. - **Open on the record.** Cheap, honest, and the right answer whenever the host is showing what its own website already shows. **Delete it, from this menu and from every axis line above, when Q5 reports a restriction stated by someone who speaks for the host.** Publishing an open-record posture over a site with a restricted area is a rule you have broken before the coach leaves. Parked at the bottom, it comes back as "let's just not make a fuss about it". - **Per-attendee written undertaking - the starved rung.** Tops access and tops compliance, and sits second on effort behind relayed clearance. So the takeaway line never picks it, and the access line picks it only once the ground rules have failed. Promotion conditions are keyed to Q6 and Q1, each carrying its own weight: - **Q6**: a bounded attendee list known before the day, because a signature drive against a list still open at the door is a door failure rather than a policy. - **Q1**: the host's yes was conditioned on it. Both conditions apply together, not either alone. Whatever the instrument turns out to be is counsel's to name, and this skill names none. - **Host-controlled, organizer-relayed clearance.** The only rung whose cost continues after the event ends. **Delete it, from this menu and from every axis line above, when Q7 names nobody to run the queue, or names someone who will not still be doing it when the requests arrive.** An unrun clearance queue is two failures at once: a promise to the host you will break, and an attendee's write-up that sits unpublished forever with no one to chase. ## Failure modes - **Designing the day before a host has said yes.** Q1 exists to stop this. A format with no host is a choice between formats, and `samber/dev-event-organizer-skills@business-event-formats` owns it. - **Treating a host like a venue.** A venue that falls through costs you a room you re-book. A host that falls through deletes the programme, because the host _was_ the programme. Carry that difference into every date and deposit decision, and never copy the several-venues-against-several-dates mechanic from `samber/dev-event-organizer-skills@event-venue-sourcing`. A second host is not a substitute for the first. It is a different event. - **Assuming a restriction the host never stated.** Self-imposed secrecy is the most common way an expedition produces nothing anyone can use. Q5 asks who the restriction came from precisely because the usual answer is "we assumed". - **Assuming the absence of a restriction.** The mirror failure, and the more expensive one. `samber/dev-event-organizer-skills@event-content-repurposing`'s rights gate has the rule for it: _"Silence is off-limits, not permission."_ - **Letting the host's marketing team write the agenda.** A host-led visit that turns into a product demonstration has cost your audience a journey to watch a webinar. Say at the brief stage what the audience is coming to understand, then check the agenda against that sentence. - **Re-deriving transport, catering or the per-site requirements sheet here.** All three have owners named in the scope section, and all three are better covered there than anything this skill could say. - **Forgetting the vehicle.** The scope clause has to name it. `samber/dev-event-organizer-skills@event-code-of-conduct`'s own reference file says why: _"a shuttle is neither the venue nor a social event"_. - **Inventing a number.** A site count, a group size, a lead time, a host-approval turnaround: every one is the host's to set, and none generalises from one host to the next. Ask the host, and record their answer as theirs. ## Measurement Every gate below is self-set rather than an external benchmark. Say so when you present them. Whether the event as a whole succeeded belongs to `samber/dev-event-organizer-skills@corporate-event-strategy`. **Pass threshold (structural, one only):** before any attendee is told where they are going, all four of these exist in writing with zero blanks: - The host's yes, and any condition attached to it. - The named counterpart inside the host. - The access posture, with the restriction list it was built from. - The person named to handle anything an attendee wants to publish afterwards. Iterate until the count is four. A blank in any of them is the failure this skill exists to catch. Signals worth recording afterwards, all self-set: - Whether any host withdrew, and at what notice. - Whether the agenda that ran matched the brief you sent. - How many attendees asked to publish something, and how long each waited. - Whether the host would receive you again. That last one is the only signal that compounds, and the one nobody writes down. ## Invocation examples - "We want to take our conference attendees to a hyperscaler's datacentre before the event opens. How do we structure it?" - "A hardware company offered to host our community for a factory tour. What do we need to agree before we say yes?" - "Our attendees want to see how a big engineering org actually runs CI. Should we visit one, or just get someone from one on stage?" - "The host wants everyone to sign something before entry. Is that normal, and what does it cost us?" - "Can attendees blog about what they saw on the site visit?" Expected output: an expedition brief with: 1. The routing list - everything in the request that belongs to another skill, named. 2. The host-dependency posture, with the rungs deleted and why each was cut. 3. The access-and-repeatability posture, with the restriction list it was built from. 4. The host brief itself. 5. The explicit handoffs. 6. For each choice, the interview answer that would flip it. Presented section by section for validation before anything is promised to a host. ## References - [references/precedent-and-evidence.md](./references/precedent-and-evidence.md) - read it for the one documented technical conference to have run a host-site programme, a same-named format that is not this skill's subject, the evidence on both sides of the access-ordering argument, and published group-size, site-count and lead-time ranges from named study-tour operators. Key handoffs to other skills in the collection: - `samber/dev-event-organizer-skills@business-event-formats` - whether this format is the right shape at all, and the account-depth family people reach for when they say executive immersion. - `samber/dev-event-organizer-skills@event-code-of-conduct` - the scope clause that has to name the host's premises and the vehicle. - `samber/dev-event-organizer-skills@event-hospitality` - transport, catering service style, the uncorrectable headcount, and the offsite evening when the visit is social rather than the programme. - `samber/dev-event-organizer-skills@event-vendor-sourcing` - the contract with any supplier who moves with you. - `samber/dev-event-organizer-skills@event-production` - capture through published master, if anything is recorded. - `samber/dev-event-organizer-skills@corporate-event-strategy` - goals, funding and what the event commits to being measured on. The scope section above routes to further siblings for venue requirements, content rights, VIP guests and press relations. Read it for the complete routing list.
Ships with 2 supporting files:
- evals/evals.json
- references/precedent-and-evidence.md
Mirrored from the author's public source. Install counts from the open skills registry.