← Host Visit
API
Tokens

Run Host Visit from your own code

Both metered lanes are available over HTTP and each returns one JSON object. The division of labour: the page routes everything that belongs to another plan, fixes the value axis, applies both menus' delete rules, ranks the candidates, keeps the host's restriction list as stated and counts the four-item pass gate - all free, in hostkit.js. The run writes the expedition brief or the host brief; the page then holds the reply to its own picks and rejects any number (hostreply.js).

Base URL and the response shape

Every endpoint lives under https://api.skillsafe.ai/v1/app-api, and every response has one shape:

{ "ok": true,  "data":  { ... } }
{ "ok": false, "error": { "code": "...", "message": "..." } }

The token is minted for this app (the guest call takes {"slug":"host-visit"}), so no slug header is needed afterwards. Send it as Authorization: Bearer …. The run body is the input object, sent bare.

StatusCodeMeaning
400validation_errorThe body is not a JSON object, or a required key (task, visit, host, facts) is missing.
401unauthorizedNo token, or a stale one. Mint a guest token or sign in again.
402insufficient_creditsThe balance is under min_credits. Price with /estimate first.
403forbiddenA guest token tried to run: both lanes are metered and need a personal sign-in.
404not_foundUnknown job id.
429rate_limitedBack off and retry.
5xxserver_errorTransient. Retry with the same Idempotency-Key so a retry never double-bills.

The task field comes first

Two lanes - brief (the expedition brief for the organizing team) and host (the brief sent to the host's counterpart; it needs a host that has said yes and the sentence of what the audience is coming to understand). A missing or unknown task is answered as brief. Both lanes send the same four fields.

The input

FieldRequiredWhat
taskyesbrief or host. If it is missing or neither, do brief and set "task": "brief".
visityesthe visit, why the audience needs to be there, the audience's question, the attendee list and vehicle, the organizer's runway and relationships, what is already proposed, the sentence of what the audience is coming to understand, and what else was asked about.
hostyesthe host, its yes and condition, the counterpart and whether they can commit colleagues' time, the restrictions and who stated them, the clearance owner, who writes the agenda, and what the organizer asks of the host's people.
factsyesthe routing list, the value axis, both postures with their picks, candidates in order and rungs, the restriction list, the handoffs, the gates, the signals and every finding tagged [fix], [check] or [info], most urgent first.
retry_notenooptional; if present, your previous reply was unusable - follow it.

The rules the model applies

House rules

The replies

brief

  1. summary - one sentence, at most 35 words: the recommended postures and the first thing to settle.
  2. routing - one object per topic the page routes out, in its order: topic (the page's), owner (the page's). [] when nothing is routed.
  3. axis - pick (place or fit, the page's), why (one sentence from why the audience needs to be there).
  4. dependency_candidates - one object per candidate in the page's order: posture (room, hostled, negotiated or circuit), tradeoff (one sentence: what it buys and what it costs here).
  5. dependency - the page's pick.
  6. access_candidates - one object per candidate in the page's order: posture (open, rules, undertaking or clearance), tradeoff (one sentence).
  7. access - the page's pick.
  8. deleted - one object per rung the page marks deleted, the dependency menu first and then the access menu, each in the page's rung order (a starved rung is not deleted - leave it out): rung (its name), reason (one sentence).
  9. restrictions - the page's restriction list, one string each, as the input gives them. [] when none are listed.
  10. brief_sentence - what the audience is coming to understand, in one sentence from the input; "to be named" when the input has none.
  11. handoffs - one short string per handoff the page lists, in its order, naming the owner and what goes to it.
  12. flips - 2 to 4 objects: choice (dependency or access), flip (one sentence: the interview answer that would flip it).
  13. checks - one object per gate in the page's order: check (the page's short name, exactly), pass (true or false, as the page says).
  14. caveats - at most 4 short strings in all: [fix] findings first in the page's order (only the first four when there are more), then [check] findings in the page's order while room remains. [] when there are none of either.
{
  "task": "brief",
  "summary": "one sentence",
  "routing": [ { "topic": "Transport and the headcount", "owner": "event-hospitality and event-vendor-sourcing" } ],
  "axis": { "pick": "place", "why": "one sentence" },
  "dependency_candidates": [ { "posture": "hostled", "tradeoff": "one sentence" } ],
  "dependency": "hostled",
  "access_candidates": [ { "posture": "rules", "tradeoff": "one sentence" } ],
  "access": "rules",
  "deleted": [ { "rung": "Host representative in your own room", "reason": "one sentence" } ],
  "restrictions": [ "a restriction as stated" ],
  "brief_sentence": "one sentence",
  "handoffs": [ "an owner - what goes to it" ],
  "flips": [ { "choice": "dependency", "flip": "one sentence" } ],
  "checks": [ { "check": "Host's yes", "pass": true } ],
  "caveats": [ "a caveat" ]
}

The page holds it to its own picks: the routing list, the axis, both postures' candidates in order and picks, every deleted rung named (and no starved one), the restrictions as stated, the handoffs (the vehicle named when there is one) and the gates; any digit is flagged, since every site count, group size or lead time is the host's to state.

host

  1. to - the named counterpart, exactly ("to be named" when the input has none).
  2. subject - specific: the visit and what the audience is coming to understand.
  3. understand - one or two sentences: what the audience is coming to understand, and why it needs to be there in person.
  4. ask - one or two sentences: what the organizer asks the host's people to do, at the page's dependency posture.
  5. see - one or two sentences: what the organizer hopes to see, said as the host's call to make; when the page's posture is the host's engineer in the organizer's own room, what the organizer hopes to hear instead.
  6. repeat - one or two sentences: what attendees will be told they may repeat afterwards, at the page's access posture, naming each restriction from the input.
  7. will_not - one or two sentences: what the organizer will not do (for example publish without the agreed clearance, or turn the visit into a product demonstration).
  8. confirm - one short string per item of the four-item pass threshold (the host's yes, the named counterpart, the restriction list stated by the host, the clearance owner) that the page's gates mark missing, plus the condition attached to the yes if there is one: what the organizer needs back in writing. [] when nothing is missing.
  9. note - one sentence, at most 30 words, for the organizer: what to settle before sending.
{
  "task": "host",
  "to": "the counterpart",
  "subject": "a specific subject",
  "understand": "one or two sentences",
  "ask": "one or two sentences",
  "see": "one or two sentences",
  "repeat": "one or two sentences",
  "will_not": "one or two sentences",
  "confirm": [ "what to confirm in writing" ],
  "note": "one sentence"
}

The page requires the named counterpart, what the audience is coming to understand and what is asked of the host's people, the access posture in what attendees may repeat (never more freedom than it allows), every missing pass item asked back in writing, and no digit anywhere.

Worked examples - every lane, every sample

These are the page's three free samples (fictional hosts, events and people; no figures). Each input is exactly what the page sends; each reply is the saved reply the sample replays, shipped as the validating model wrote it; the last line is the page's own check. The factory sample has no host brief: nobody at a host has said yes.

Northwind datacentre visit (the host wants signatures) - brief

Axis place; one host site, host-led; per-attendee written undertaking; pass threshold 3 of 4; 5 of 7 gates.

Input:

{
 "task": "brief",
 "visit": "Visit: Northwind Infra Summit datacentre visit; the visit is the programme\nWhy be there: a thing that cannot be shown on a slide yes (a working hyperscale hall and its cooling plant); the audience's question is experiential (how a hall this size is run day to day)\nAttendees: list bounded and known before the day; a vehicle carries them yes\nOrganizer side: runway to survive a host's withdrawal no; standing relationships with candidate hosts one; an organizer works inside a candidate host no\nOn the table: proposed dependency posture Multi-host circuit; proposed access posture none\nWhat the audience is coming to understand: how a hyperscale hall is cooled, powered and staffed through an ordinary shift\nAlso asked about: the coach from the conference hotel, lunch on site, and whether we can film the walk",
 "host": "Host: Tarnwick Cloud; yes, in writing; conditioned on a per-attendee written undertaking\nCounterpart: Ines Varlotte; can commit colleagues' time no\nRestrictions: stated by someone who speaks for the host; No photography inside the hall; No customer names repeated outside the building; the visit shows only what the host already publishes no\nClearance: owner not named; still running the queue when requests arrive unknown\nHost marketing writes the agenda: no\nWhat we ask the host's people to do: a walk through the hall and the cooling plant with the shift lead",
 "facts": "Routing: Transport and the headcount -> event-hospitality and event-vendor-sourcing; Catering on the move -> event-hospitality; Capturing and publishing the visit -> event-production, then event-content-repurposing\nValue axis for the dependency menu: place\nHost dependency: the page's pick is hostled; candidates in order hostled; rungs Host representative in your own room deleted; One host site, host-led default; One host site, negotiated agenda deleted; Multi-host circuit starved\nAccess: the page's pick is undertaking; candidates in order undertaking, rules; rungs Open on the record deleted; Named ground rules, no instrument default; Per-attendee written undertaking promoted; Host-controlled, organizer-relayed clearance deleted\nRestriction list: No photography inside the hall; No customer names repeated outside the building\nHandoffs: event-code-of-conduct - the sites and the vehicle - a shuttle is neither the venue nor a social event, for the scope clause; event-venue-sourcing - the per-site requirements sheet; event-hospitality and event-vendor-sourcing - transport, catering and the headcount fixed before departure; event-production - anything recorded on site; corporate-event-strategy - goals, cost and measurement\nChecks (5 of 7): Host's yes (The host's yes is in writing, with any condition attached to it) passed; Named counterpart (A named counterpart inside the host) passed; Restriction list (The access posture rests on a restriction list stated by someone who speaks for the host) passed; Clearance owner (Someone is named to handle anything an attendee wants to publish afterwards) MISSING; Proposed dependency (Any host-dependency posture already proposed survives its delete rules (passes when none is proposed)) MISSING; Proposed access (Any access posture already proposed survives its delete rules, and a signed undertaking has a bounded list) passed; Brief sentence (One sentence says what the audience is coming to understand, and the host's marketing team does not write the agenda) passed\nSignals to record afterwards: Whether any host withdrew, and at what notice; Whether the agenda that ran matched the brief that was sent; How many attendees asked to publish something, and how long each waited; Whether the host would receive you again - the only signal that compounds\nFindings (11):\n[fix] proposed_dep_starved (dependency): The proposed multi-host circuit is starved - it needs standing relationships with several hosts and runway together, or one withdrawal deletes the programme after the travel is booked.\n[fix] no_clearance_owner (access): Nobody is named to handle what attendees want to publish afterwards - one of the four things that must exist in writing before attendees are told where they are going.\n[check] withdrawal (dependency): A host that withdraws deletes the programme, not a room - and there is no runway to survive it; carry that into every date and deposit decision.\n[check] pass (measurement): Pass threshold: 3 of 4 in writing (the host's yes, the counterpart, the restriction list, the clearance owner) - self-set, no benchmark.\n[info] routed (scope): Routed out before either menu: transport and the headcount (event-hospitality and event-vendor-sourcing), catering on the move (event-hospitality) and capturing and publishing the visit (event-production, then event-content-repurposing).\n[info] room_deleted (dependency): The talk in your own room is deleted: a working hyperscale hall and its cooling plant cannot be shown on a slide, and a talk is not a smaller version of standing on the floor.\n[info] negotiated_deleted (dependency): The negotiated agenda is deleted: nobody inside the host can commit colleagues' time, so it would be the host-led visit plus meetings - the worst cell on the menu.\n[info] open_deleted (access): Open on the record is deleted: the host stated a restriction, and publishing an open posture over it is a rule broken before the coach leaves.\n[info] clearance_deleted (access): Relayed clearance is deleted: nobody is named to run the queue - an unrun queue breaks a promise to the host and strands every write-up.\n[info] undertaking (access): The undertaking is promoted: the host conditioned its yes on it and the list is bounded - whatever the instrument is, counsel names it, not this page.\n[info] vehicle (host): The scope clause has to name the vehicle as well as the sites."
}

Reply:

{
 "task": "brief",
 "summary": "The recommended postures are a host-led site and a per-attendee written undertaking; naming a clearance owner is the first item to settle ahead of any travel commitment.",
 "routing": [
  {
   "topic": "Transport and the headcount",
   "owner": "event-hospitality and event-vendor-sourcing"
  },
  {
   "topic": "Catering on the move",
   "owner": "event-hospitality"
  },
  {
   "topic": "Capturing and publishing the visit",
   "owner": "event-production, then event-content-repurposing"
  }
 ],
 "axis": {
  "pick": "place",
  "why": "A working hyperscale hall and its cooling plant cannot be shown on a slide, and the audience's question is experiential: how a hall this size is run day to day."
 },
 "dependency_candidates": [
  {
   "posture": "hostled",
   "tradeoff": "A host-led site puts the whole audience on Tarnwick Cloud's floor under its agenda, but since there is no runway to survive a withdrawal, losing Tarnwick Cloud at this stage would end the programme rather than simply changing rooms."
  }
 ],
 "dependency": "hostled",
 "access_candidates": [
  {
   "posture": "undertaking",
   "tradeoff": "A per-attendee written undertaking meets the condition Tarnwick Cloud put on its yes and fits a bounded, known attendee list, but it adds a written commitment from every attendee beyond the default ground rules."
  },
  {
   "posture": "rules",
   "tradeoff": "Telling attendees the ground rules ahead of the trip is the simplest access posture, but it would not satisfy the condition Tarnwick Cloud attached to its yes, which calls for a written undertaking from every attendee."
  }
 ],
 "access": "undertaking",
 "deleted": [
  {
   "rung": "Host representative in your own room",
   "reason": "A working hyperscale hall and its cooling plant cannot be shown on a slide, and a talk in your own room is not a smaller version of standing on the floor."
  },
  {
   "rung": "One host site, negotiated agenda",
   "reason": "Nobody at Tarnwick Cloud can commit colleagues' time, so a negotiated agenda would only be the host-led visit with meetings added, the weakest combination on offer."
  },
  {
   "rung": "Open on the record",
   "reason": "Tarnwick Cloud has stated restrictions, and publishing on an open posture over them would break a rule before the visit even begins."
  },
  {
   "rung": "Host-controlled, organizer-relayed clearance",
   "reason": "Nobody is named to run the queue, so relayed clearance would break a promise to the host and leave every attendee's write-up stranded."
  }
 ],
 "restrictions": [
  "No photography inside the hall",
  "No customer names repeated outside the building"
 ],
 "brief_sentence": "How a hyperscale hall is cooled, powered and staffed through an ordinary shift.",
 "handoffs": [
  "event-code-of-conduct - the sites and the vehicle for the scope clause, since a shuttle is neither the venue nor a social event",
  "event-venue-sourcing - the per-site requirements sheet",
  "event-hospitality and event-vendor-sourcing - transport, catering and the headcount fixed before departure",
  "event-production - anything recorded on site",
  "corporate-event-strategy - goals, cost and measurement"
 ],
 "flips": [
  {
   "choice": "dependency",
   "flip": "If the organizer gained standing relationships with several hosts and the runway to survive a host withdrawing, a multi-host circuit would stop being starved."
  },
  {
   "choice": "dependency",
   "flip": "If Ines Varlotte could commit colleagues' time, a negotiated agenda would no longer be deleted."
  },
  {
   "choice": "access",
   "flip": "If someone were named to run the clearance queue when requests arrive, host-controlled, organizer-relayed clearance would stop being deleted."
  }
 ],
 "checks": [
  {
   "check": "Host's yes",
   "pass": true
  },
  {
   "check": "Named counterpart",
   "pass": true
  },
  {
   "check": "Restriction list",
   "pass": true
  },
  {
   "check": "Clearance owner",
   "pass": false
  },
  {
   "check": "Proposed dependency",
   "pass": false
  },
  {
   "check": "Proposed access",
   "pass": true
  },
  {
   "check": "Brief sentence",
   "pass": true
  }
 ],
 "caveats": [
  "The proposed multi-host circuit is starved: it needs standing relationships with several hosts and runway together, or a withdrawal would end the programme after travel is booked.",
  "Nobody is named to handle what attendees want to publish afterward, an item that needs to be in writing before travel is confirmed.",
  "A host that withdraws deletes the programme, not a room, and there is no runway to survive that here; weigh that against any date or deposit decision.",
  "The pass threshold is self-set, measured against the host's yes, the named counterpart, the restriction list and the clearance owner being in writing, with no outside benchmark."
 ]
}

The page's check: kept - nothing to flag

Northwind datacentre visit (the host wants signatures) - host

Axis place; one host site, host-led; per-attendee written undertaking; pass threshold 3 of 4; 5 of 7 gates.

Input:

{
 "task": "host",
 "visit": "Visit: Northwind Infra Summit datacentre visit; the visit is the programme\nWhy be there: a thing that cannot be shown on a slide yes (a working hyperscale hall and its cooling plant); the audience's question is experiential (how a hall this size is run day to day)\nAttendees: list bounded and known before the day; a vehicle carries them yes\nOrganizer side: runway to survive a host's withdrawal no; standing relationships with candidate hosts one; an organizer works inside a candidate host no\nOn the table: proposed dependency posture Multi-host circuit; proposed access posture none\nWhat the audience is coming to understand: how a hyperscale hall is cooled, powered and staffed through an ordinary shift\nAlso asked about: the coach from the conference hotel, lunch on site, and whether we can film the walk",
 "host": "Host: Tarnwick Cloud; yes, in writing; conditioned on a per-attendee written undertaking\nCounterpart: Ines Varlotte; can commit colleagues' time no\nRestrictions: stated by someone who speaks for the host; No photography inside the hall; No customer names repeated outside the building; the visit shows only what the host already publishes no\nClearance: owner not named; still running the queue when requests arrive unknown\nHost marketing writes the agenda: no\nWhat we ask the host's people to do: a walk through the hall and the cooling plant with the shift lead",
 "facts": "Routing: Transport and the headcount -> event-hospitality and event-vendor-sourcing; Catering on the move -> event-hospitality; Capturing and publishing the visit -> event-production, then event-content-repurposing\nValue axis for the dependency menu: place\nHost dependency: the page's pick is hostled; candidates in order hostled; rungs Host representative in your own room deleted; One host site, host-led default; One host site, negotiated agenda deleted; Multi-host circuit starved\nAccess: the page's pick is undertaking; candidates in order undertaking, rules; rungs Open on the record deleted; Named ground rules, no instrument default; Per-attendee written undertaking promoted; Host-controlled, organizer-relayed clearance deleted\nRestriction list: No photography inside the hall; No customer names repeated outside the building\nHandoffs: event-code-of-conduct - the sites and the vehicle - a shuttle is neither the venue nor a social event, for the scope clause; event-venue-sourcing - the per-site requirements sheet; event-hospitality and event-vendor-sourcing - transport, catering and the headcount fixed before departure; event-production - anything recorded on site; corporate-event-strategy - goals, cost and measurement\nChecks (5 of 7): Host's yes (The host's yes is in writing, with any condition attached to it) passed; Named counterpart (A named counterpart inside the host) passed; Restriction list (The access posture rests on a restriction list stated by someone who speaks for the host) passed; Clearance owner (Someone is named to handle anything an attendee wants to publish afterwards) MISSING; Proposed dependency (Any host-dependency posture already proposed survives its delete rules (passes when none is proposed)) MISSING; Proposed access (Any access posture already proposed survives its delete rules, and a signed undertaking has a bounded list) passed; Brief sentence (One sentence says what the audience is coming to understand, and the host's marketing team does not write the agenda) passed\nSignals to record afterwards: Whether any host withdrew, and at what notice; Whether the agenda that ran matched the brief that was sent; How many attendees asked to publish something, and how long each waited; Whether the host would receive you again - the only signal that compounds\nFindings (11):\n[fix] proposed_dep_starved (dependency): The proposed multi-host circuit is starved - it needs standing relationships with several hosts and runway together, or one withdrawal deletes the programme after the travel is booked.\n[fix] no_clearance_owner (access): Nobody is named to handle what attendees want to publish afterwards - one of the four things that must exist in writing before attendees are told where they are going.\n[check] withdrawal (dependency): A host that withdraws deletes the programme, not a room - and there is no runway to survive it; carry that into every date and deposit decision.\n[check] pass (measurement): Pass threshold: 3 of 4 in writing (the host's yes, the counterpart, the restriction list, the clearance owner) - self-set, no benchmark.\n[info] routed (scope): Routed out before either menu: transport and the headcount (event-hospitality and event-vendor-sourcing), catering on the move (event-hospitality) and capturing and publishing the visit (event-production, then event-content-repurposing).\n[info] room_deleted (dependency): The talk in your own room is deleted: a working hyperscale hall and its cooling plant cannot be shown on a slide, and a talk is not a smaller version of standing on the floor.\n[info] negotiated_deleted (dependency): The negotiated agenda is deleted: nobody inside the host can commit colleagues' time, so it would be the host-led visit plus meetings - the worst cell on the menu.\n[info] open_deleted (access): Open on the record is deleted: the host stated a restriction, and publishing an open posture over it is a rule broken before the coach leaves.\n[info] clearance_deleted (access): Relayed clearance is deleted: nobody is named to run the queue - an unrun queue breaks a promise to the host and strands every write-up.\n[info] undertaking (access): The undertaking is promoted: the host conditioned its yes on it and the list is bounded - whatever the instrument is, counsel names it, not this page.\n[info] vehicle (host): The scope clause has to name the vehicle as well as the sites."
}

Reply:

{
 "task": "host",
 "to": "Ines Varlotte",
 "subject": "Northwind Infra Summit datacentre visit: how a hyperscale hall is cooled, powered and staffed through an ordinary shift",
 "understand": "Attendees are coming to understand how a hyperscale hall is cooled, powered and staffed through an ordinary shift. This cannot be shown on a slide, so seeing the hall and its cooling plant in person is the only way to answer it.",
 "ask": "We ask that Tarnwick Cloud's people lead our attendees on a walk through the hall and the cooling plant, with the shift lead on hand to answer questions.",
 "see": "What we hope to see on the walk - how much of the floor, the plant and the shift lead's routine is shown - is entirely Tarnwick Cloud's call to make.",
 "repeat": "Each attendee will sign a written undertaking before the visit, and will be told afterwards that they may repeat only what it permits, honoring both restrictions Tarnwick Cloud has stated: No photography inside the hall; No customer names repeated outside the building.",
 "will_not": "We will not publish anything from the visit, including any photographs or write-ups, until clearance has been agreed and confirmed in writing. We will not ask anyone to photograph inside the hall or name any of Tarnwick Cloud's customers outside the building.",
 "confirm": [
  "A named owner to handle anything an attendee wants to publish after the visit, confirmed in writing",
  "The per-attendee written undertaking that Tarnwick Cloud's yes is conditioned on, confirmed in writing"
 ],
 "note": "Name a clearance owner for anything attendees want to publish, and confirm the per-attendee undertaking the host's yes depends on, before sending this brief."
}

The page's check: kept - nothing to flag

Platform Guild CI visit (a specific question) - brief

Axis fit; host representative in your own room; named ground rules, no instrument; pass threshold 3 of 4; 6 of 7 gates.

Input:

{
 "task": "brief",
 "visit": "Visit: Platform Guild CI visit; the visit is the programme\nWhy be there: a thing that cannot be shown on a slide no; the audience's question is specific and technical (how they keep a large monorepo's CI fast without a dedicated build team)\nAttendees: list bounded and known before the day; a vehicle carries them no\nOrganizer side: runway to survive a host's withdrawal yes; standing relationships with candidate hosts one; an organizer works inside a candidate host no\nOn the table: proposed dependency posture One host site, host-led; proposed access posture Named ground rules, no instrument\nWhat the audience is coming to understand: how one engineering organization keeps a large monorepo's CI fast with no dedicated build team\nAlso asked about: members want to blog about what they learn",
 "host": "Host: Quillbrae; yes, in writing; no condition\nCounterpart: Sam Thellaby; can commit colleagues' time yes\nRestrictions: your own assumption; Do not name their build vendor; the visit shows only what the host already publishes no\nClearance: owner Priya Venhallow; still running the queue when requests arrive yes\nHost marketing writes the agenda: no\nWhat we ask the host's people to do: time with the engineers who own the CI pipeline, answering our members' questions",
 "facts": "Routing: Capturing and publishing the visit -> event-production, then event-content-repurposing\nValue axis for the dependency menu: fit\nHost dependency: the page's pick is room; candidates in order room, negotiated, hostled; rungs Host representative in your own room available; One host site, host-led default; One host site, negotiated agenda available; Multi-host circuit starved\nAccess: the page's pick is rules; candidates in order rules, open, clearance; rungs Open on the record available; Named ground rules, no instrument default; Per-attendee written undertaking starved; Host-controlled, organizer-relayed clearance available\nRestriction list: Do not name their build vendor\nHandoffs: event-code-of-conduct - the sites, for the scope clause; event-production - anything recorded on site; corporate-event-strategy - goals, cost and measurement\nChecks (6 of 7): Host's yes (The host's yes is in writing, with any condition attached to it) passed; Named counterpart (A named counterpart inside the host) passed; Restriction list (The access posture rests on a restriction list stated by someone who speaks for the host) MISSING; Clearance owner (Someone is named to handle anything an attendee wants to publish afterwards) passed; Proposed dependency (Any host-dependency posture already proposed survives its delete rules (passes when none is proposed)) passed; Proposed access (Any access posture already proposed survives its delete rules, and a signed undertaking has a bounded list) passed; Brief sentence (One sentence says what the audience is coming to understand, and the host's marketing team does not write the agenda) passed\nSignals to record afterwards: Whether any host withdrew, and at what notice; Whether the agenda that ran matched the brief that was sent; How many attendees asked to publish something, and how long each waited; Whether the host would receive you again - the only signal that compounds\nFindings (6):\n[check] assumed_restriction (access): The restrictions come from your own assumption, not from the host - self-imposed secrecy is how an expedition produces nothing anyone can use; ask the host.\n[check] pass (measurement): Pass threshold: 3 of 4 in writing (the host's yes, the counterpart, the restriction list, the clearance owner) - self-set, no benchmark.\n[info] routed (scope): Routed out before either menu: capturing and publishing the visit (event-production, then event-content-repurposing).\n[info] close_skill (dependency): The question is specific and nothing needs to be seen on site - the honest answer is the host's engineer in your own room; close the expedition rather than design travel around a conversation that fits in a session.\n[info] proposed_dep_alt (dependency): The proposed one host site, host-led is a candidate, not the recommendation - the brief should state the trade-off.\n[info] rules_before (access): State the ground rules to attendees before the session - a rule learned in the room is accepted under pressure."
}

Reply:

{
 "task": "brief",
 "summary": "The recommended postures are host representative in your own room and named ground rules, no instrument, with confirming the restriction list directly with Quillbrae the first item to settle.",
 "routing": [
  {
   "topic": "Capturing and publishing the visit",
   "owner": "event-production, then event-content-repurposing"
  }
 ],
 "axis": {
  "pick": "fit",
  "why": "The audience's question is specific and technical: how they keep a large monorepo's CI fast without a dedicated build team."
 },
 "dependency_candidates": [
  {
   "posture": "room",
   "tradeoff": "A host representative in your own room gives Platform Guild direct answers to a specific, technical question without any travel, but it costs attendees any chance to see Quillbrae's engineers and pipeline directly."
  },
  {
   "posture": "negotiated",
   "tradeoff": "A negotiated agenda works because Sam Thellaby can commit colleagues' time to a specific set of answers, but it still asks the group to travel for a conversation that does not need to happen on site."
  },
  {
   "posture": "hostled",
   "tradeoff": "A host-led site visit would put Platform Guild inside Quillbrae's offices for a broader look, but it spends a trip on a question that is specific and technical rather than something that needs to be seen."
  }
 ],
 "dependency": "room",
 "access_candidates": [
  {
   "posture": "rules",
   "tradeoff": "Named ground rules with no instrument keep the visit simple for a specific technical conversation, but the restriction they would state, not naming Quillbrae's build vendor, still needs to come from Quillbrae rather than from assumption."
  },
  {
   "posture": "open",
   "tradeoff": "Open on the record would let members blog freely about what they learn, but it risks breaking the assumed restriction on naming Quillbrae's build vendor if that restriction turns out to be real."
  },
  {
   "posture": "clearance",
   "tradeoff": "Host-controlled, organizer-relayed clearance is available since Priya Venhallow is named and able to run the queue, but it adds a review step beyond the simple ground rules this specific-question visit otherwise needs."
  }
 ],
 "access": "rules",
 "deleted": [],
 "restrictions": [
  "Do not name their build vendor"
 ],
 "brief_sentence": "How an engineering organization keeps a large monorepo's CI fast with no dedicated build team.",
 "handoffs": [
  "event-code-of-conduct - the sites, for the scope clause",
  "event-production - anything recorded on site",
  "corporate-event-strategy - goals, cost and measurement"
 ],
 "flips": [
  {
   "choice": "dependency",
   "flip": "If the audience needed to see Quillbrae's CI pipeline running rather than hear engineers explain it, a host-led site visit would replace a conversation in your own room."
  },
  {
   "choice": "dependency",
   "flip": "If Platform Guild's questions grew specific enough to need several of Sam Thellaby's colleagues across a working session, a negotiated agenda would replace the room conversation."
  },
  {
   "choice": "access",
   "flip": "If members' plans to blog grew detailed enough to need review before anything goes out, host-controlled, organizer-relayed clearance would replace named ground rules, since Priya Venhallow already runs that queue."
  }
 ],
 "checks": [
  {
   "check": "Host's yes",
   "pass": true
  },
  {
   "check": "Named counterpart",
   "pass": true
  },
  {
   "check": "Restriction list",
   "pass": false
  },
  {
   "check": "Clearance owner",
   "pass": true
  },
  {
   "check": "Proposed dependency",
   "pass": true
  },
  {
   "check": "Proposed access",
   "pass": true
  },
  {
   "check": "Brief sentence",
   "pass": true
  }
 ],
 "caveats": [
  "The listed restriction, not naming Quillbrae's build vendor, comes from assumption rather than from anyone who speaks for the host; ask Quillbrae directly before relying on it.",
  "The pass threshold is self-set, measured against the host's yes, the named counterpart, the restriction list and the clearance owner being in writing, with no outside benchmark."
 ]
}

The page's check: kept - nothing to flag

Platform Guild CI visit (a specific question) - host

Axis fit; host representative in your own room; named ground rules, no instrument; pass threshold 3 of 4; 6 of 7 gates.

Input:

{
 "task": "host",
 "visit": "Visit: Platform Guild CI visit; the visit is the programme\nWhy be there: a thing that cannot be shown on a slide no; the audience's question is specific and technical (how they keep a large monorepo's CI fast without a dedicated build team)\nAttendees: list bounded and known before the day; a vehicle carries them no\nOrganizer side: runway to survive a host's withdrawal yes; standing relationships with candidate hosts one; an organizer works inside a candidate host no\nOn the table: proposed dependency posture One host site, host-led; proposed access posture Named ground rules, no instrument\nWhat the audience is coming to understand: how one engineering organization keeps a large monorepo's CI fast with no dedicated build team\nAlso asked about: members want to blog about what they learn",
 "host": "Host: Quillbrae; yes, in writing; no condition\nCounterpart: Sam Thellaby; can commit colleagues' time yes\nRestrictions: your own assumption; Do not name their build vendor; the visit shows only what the host already publishes no\nClearance: owner Priya Venhallow; still running the queue when requests arrive yes\nHost marketing writes the agenda: no\nWhat we ask the host's people to do: time with the engineers who own the CI pipeline, answering our members' questions",
 "facts": "Routing: Capturing and publishing the visit -> event-production, then event-content-repurposing\nValue axis for the dependency menu: fit\nHost dependency: the page's pick is room; candidates in order room, negotiated, hostled; rungs Host representative in your own room available; One host site, host-led default; One host site, negotiated agenda available; Multi-host circuit starved\nAccess: the page's pick is rules; candidates in order rules, open, clearance; rungs Open on the record available; Named ground rules, no instrument default; Per-attendee written undertaking starved; Host-controlled, organizer-relayed clearance available\nRestriction list: Do not name their build vendor\nHandoffs: event-code-of-conduct - the sites, for the scope clause; event-production - anything recorded on site; corporate-event-strategy - goals, cost and measurement\nChecks (6 of 7): Host's yes (The host's yes is in writing, with any condition attached to it) passed; Named counterpart (A named counterpart inside the host) passed; Restriction list (The access posture rests on a restriction list stated by someone who speaks for the host) MISSING; Clearance owner (Someone is named to handle anything an attendee wants to publish afterwards) passed; Proposed dependency (Any host-dependency posture already proposed survives its delete rules (passes when none is proposed)) passed; Proposed access (Any access posture already proposed survives its delete rules, and a signed undertaking has a bounded list) passed; Brief sentence (One sentence says what the audience is coming to understand, and the host's marketing team does not write the agenda) passed\nSignals to record afterwards: Whether any host withdrew, and at what notice; Whether the agenda that ran matched the brief that was sent; How many attendees asked to publish something, and how long each waited; Whether the host would receive you again - the only signal that compounds\nFindings (6):\n[check] assumed_restriction (access): The restrictions come from your own assumption, not from the host - self-imposed secrecy is how an expedition produces nothing anyone can use; ask the host.\n[check] pass (measurement): Pass threshold: 3 of 4 in writing (the host's yes, the counterpart, the restriction list, the clearance owner) - self-set, no benchmark.\n[info] routed (scope): Routed out before either menu: capturing and publishing the visit (event-production, then event-content-repurposing).\n[info] close_skill (dependency): The question is specific and nothing needs to be seen on site - the honest answer is the host's engineer in your own room; close the expedition rather than design travel around a conversation that fits in a session.\n[info] proposed_dep_alt (dependency): The proposed one host site, host-led is a candidate, not the recommendation - the brief should state the trade-off.\n[info] rules_before (access): State the ground rules to attendees before the session - a rule learned in the room is accepted under pressure."
}

Reply:

{
 "task": "host",
 "to": "Sam Thellaby",
 "subject": "Platform Guild CI visit: how one engineering organization keeps a large monorepo's CI fast with no dedicated build team",
 "understand": "Our members want to understand how one engineering organization keeps a large monorepo's CI fast with no dedicated build team. That is a specific, technical question best answered directly by the engineers who do it, not from a slide or a write-up.",
 "ask": "We ask that the engineers who own Quillbrae's CI pipeline join a working session with us, rather than host an on-site visit, to answer our members' questions about how you keep a large monorepo's CI fast without a dedicated build team.",
 "see": "We hope to hear, directly from them and in their own words, the practices and trade-offs that keep a large monorepo's CI fast day to day, rather than see any prepared materials.",
 "repeat": "Members will be told the ground rules before the session: they are free to write about what they learn, including a blog post, but the one restriction stands - Do not name their build vendor.",
 "will_not": "We will not let anything we publish name Quillbrae's build vendor, and we will not ask for anything beyond a conversation about how your team keeps CI fast.",
 "confirm": [
  "Confirmation in writing that Do not name their build vendor is the restriction Quillbrae actually wants stated, since it was our own assumption"
 ],
 "note": "Ask Quillbrae to state the restriction themselves instead of relying on your own assumption, since nothing has yet been confirmed in writing."
}

The page's check: kept - nothing to flag

Makers Meetup factory tour (nobody has said yes) - brief

Axis place; multi-host circuit; named ground rules, no instrument; pass threshold 0 of 4; 2 of 7 gates.

Input:

{
 "task": "brief",
 "visit": "Visit: Makers Meetup factory tour; the visit is the programme\nWhy be there: a thing that cannot be shown on a slide yes (a board assembly line running); the audience's question is experiential\nAttendees: list open until the door; a vehicle carries them yes\nOrganizer side: runway to survive a host's withdrawal yes; standing relationships with candidate hosts several; an organizer works inside a candidate host yes\nOn the table: proposed dependency posture none; proposed access posture Open on the record\nWhat the audience is coming to understand: how small-batch hardware actually gets built\nAlso asked about: a shuttle between the factories, and photos for our newsletter",
 "host": "Host: not named; nobody has said yes\nCounterpart: not named; can commit colleagues' time unknown\nRestrictions: the host has stated none; the visit shows only what the host already publishes no\nClearance: owner not named; still running the queue when requests arrive unknown\nHost marketing writes the agenda: yes\nWhat we ask the host's people to do: not written",
 "facts": "Routing: Transport and the headcount -> event-hospitality and event-vendor-sourcing; Capturing and publishing the visit -> event-production, then event-content-repurposing\nValue axis for the dependency menu: place\nHost dependency: the page's pick is circuit; candidates in order circuit, hostled, negotiated; rungs Host representative in your own room deleted; One host site, host-led default; One host site, negotiated agenda available; Multi-host circuit promoted\nAccess: the page's pick is rules; candidates in order rules, open; rungs Open on the record available; Named ground rules, no instrument default; Per-attendee written undertaking starved; Host-controlled, organizer-relayed clearance deleted\nRestriction list: none listed\nHandoffs: event-code-of-conduct - the sites and the vehicle - a shuttle is neither the venue nor a social event, for the scope clause; event-venue-sourcing - the per-site requirements sheet; event-hospitality and event-vendor-sourcing - transport, catering and the headcount fixed before departure; event-production - anything recorded on site; corporate-event-strategy - goals, cost and measurement\nChecks (2 of 7): Host's yes (The host's yes is in writing, with any condition attached to it) MISSING; Named counterpart (A named counterpart inside the host) MISSING; Restriction list (The access posture rests on a restriction list stated by someone who speaks for the host) MISSING; Clearance owner (Someone is named to handle anything an attendee wants to publish afterwards) MISSING; Proposed dependency (Any host-dependency posture already proposed survives its delete rules (passes when none is proposed)) passed; Proposed access (Any access posture already proposed survives its delete rules, and a signed undertaking has a bounded list) passed; Brief sentence (One sentence says what the audience is coming to understand, and the host's marketing team does not write the agenda) MISSING\nSignals to record afterwards: Whether any host withdrew, and at what notice; Whether the agenda that ran matched the brief that was sent; How many attendees asked to publish something, and how long each waited; Whether the host would receive you again - the only signal that compounds\nFindings (14):\n[fix] no_host (host): No host has said yes - this is a choice between formats, not a design; business-event-formats owns that choice, and nothing goes to attendees until a host agrees in writing.\n[fix] marketing_agenda (host): The host's marketing team is writing the agenda - a host-led visit that becomes a product demonstration costs the audience a journey to watch a webinar; check the agenda against the brief sentence.\n[fix] assumed_absence (access): The host has stated no restriction and nobody confirmed the visit shows only what is public - silence is off-limits, not permission; get the restriction list from the host.\n[fix] no_counterpart (host): No named counterpart inside the host - name the person before any agenda is discussed.\n[fix] no_clearance_owner (access): Nobody is named to handle what attendees want to publish afterwards - one of the four things that must exist in writing before attendees are told where they are going.\n[check] pass (measurement): Pass threshold: 0 of 4 in writing (the host's yes, the counterpart, the restriction list, the clearance owner) - self-set, no benchmark.\n[info] routed (scope): Routed out before either menu: transport and the headcount (event-hospitality and event-vendor-sourcing) and capturing and publishing the visit (event-production, then event-content-repurposing).\n[info] room_deleted (dependency): The talk in your own room is deleted: a board assembly line running cannot be shown on a slide, and a talk is not a smaller version of standing on the floor.\n[info] circuit_promoted (dependency): The circuit is promoted: standing relationships with several hosts and runway enough that one withdrawal does not collapse the day.\n[info] insider (dependency): An organizer works inside a candidate host - a cold approach becomes a calendar invitation; re-rank that host's rung above the default.\n[info] clearance_deleted (access): Relayed clearance is deleted: nobody is named to run the queue - an unrun queue breaks a promise to the host and strands every write-up.\n[info] rules_before (access): State the ground rules to attendees before they travel - a rule learned at the door is accepted under pressure.\n[info] proposed_access_alt (access): The proposed open on the record is a candidate, not the recommendation - the brief should state the trade-off.\n[info] vehicle (host): The scope clause has to name the vehicle as well as the sites."
}

Reply:

{
 "task": "brief",
 "summary": "The recommended postures are a multi-host circuit and named ground rules with no instrument, but nothing can move until a host actually says yes in writing.",
 "routing": [
  {
   "topic": "Transport and the headcount",
   "owner": "event-hospitality and event-vendor-sourcing"
  },
  {
   "topic": "Capturing and publishing the visit",
   "owner": "event-production, then event-content-repurposing"
  }
 ],
 "axis": {
  "pick": "place",
  "why": "A board assembly line running cannot be shown on a slide, and the audience's question is experiential."
 },
 "dependency_candidates": [
  {
   "posture": "circuit",
   "tradeoff": "A multi-host circuit fits an organizer with standing relationships across several hosts, including a host worked from inside, and the runway to survive a withdrawal from any of them, but it still depends on getting each site to say yes and arranging a vehicle between them."
  },
  {
   "posture": "hostled",
   "tradeoff": "A host-led site keeps the day simpler than a circuit, but it puts the whole visit at risk if that host withdraws, instead of spreading the risk across several hosts the organizer already has standing relationships with."
  },
  {
   "posture": "negotiated",
   "tradeoff": "A negotiated agenda remains possible since nobody has confirmed that no counterpart can commit colleagues' time, but no counterpart is named yet to make that agenda specific."
  }
 ],
 "dependency": "circuit",
 "access_candidates": [
  {
   "posture": "rules",
   "tradeoff": "Named ground rules give attendees a known set of expectations without needing any instrument, but they still have to be checked against a real restriction list from the host rather than against the silence recorded so far."
  },
  {
   "posture": "open",
   "tradeoff": "Open on the record was the posture already proposed and would support photos for the newsletter, but it rests on the host truly publishing everything shown, which nobody has yet confirmed."
  }
 ],
 "access": "rules",
 "deleted": [
  {
   "rung": "Host representative in your own room",
   "reason": "A board assembly line running cannot be shown on a slide, and a talk in your own room is not a smaller version of standing on the floor."
  },
  {
   "rung": "Host-controlled, organizer-relayed clearance",
   "reason": "Nobody is named to run the queue, so relayed clearance would break a promise to the host and leave every attendee's write-up stranded."
  }
 ],
 "restrictions": [],
 "brief_sentence": "How small-batch hardware actually gets built.",
 "handoffs": [
  "event-code-of-conduct - the sites and the vehicle for the scope clause, since a shuttle is neither the venue nor a social event",
  "event-venue-sourcing - the per-site requirements sheet",
  "event-hospitality and event-vendor-sourcing - transport, catering and the headcount fixed before departure",
  "event-production - anything recorded on site",
  "corporate-event-strategy - goals, cost and measurement"
 ],
 "flips": [
  {
   "choice": "dependency",
   "flip": "If the organizer's standing relationships turned out not to reach enough hosts for a circuit, the circuit would lose its footing and a host-led site would become the pick instead."
  },
  {
   "choice": "dependency",
   "flip": "If the audience's question became specific and technical rather than experiential, a host's engineer answering in your own room could replace any site visit."
  },
  {
   "choice": "access",
   "flip": "If a host's yes arrived conditioned on a per-attendee written undertaking with the attendee list bounded before the day, the access pick would move from named ground rules to that undertaking."
  }
 ],
 "checks": [
  {
   "check": "Host's yes",
   "pass": false
  },
  {
   "check": "Named counterpart",
   "pass": false
  },
  {
   "check": "Restriction list",
   "pass": false
  },
  {
   "check": "Clearance owner",
   "pass": false
  },
  {
   "check": "Proposed dependency",
   "pass": true
  },
  {
   "check": "Proposed access",
   "pass": true
  },
  {
   "check": "Brief sentence",
   "pass": false
  }
 ],
 "caveats": [
  "No host has said yes; until a host does so in writing, this remains a choice between visit formats for business-event-formats to own, not a settled design.",
  "The host's marketing team is currently set to write the agenda, which risks a visit that turns into a product demonstration rather than what the audience comes to understand.",
  "The host has stated no restriction, but nobody has confirmed the visit shows only what the host already publishes; get an actual restriction list from the host rather than assuming silence means permission.",
  "No named counterpart exists inside any host yet; name someone before any agenda gets discussed."
 ]
}

The page's check: kept - nothing to flag

The choices CSV for the first sample

menu,option,status,picked
host dependency,Host representative in your own room,available,
host dependency,"One host site, host-led",default,yes
host dependency,"One host site, negotiated agenda",available,
host dependency,Multi-host circuit,starved,
access,Open on the record,available,
access,"Named ground rules, no instrument",default,yes
access,Per-attendee written undertaking,starved,
access,"Host-controlled, organizer-relayed clearance",deleted,

Build the input yourself

Load the engine in node (global.window = global; require("./hostkit.js"); require("./hostreply.js")), then:

const K = HostKit, R = HostReply;
const f = K.form({ name: "Datacentre visit", hostYes: "yes", hostCondition: "undertaking", physical: "yes", counterpart: "to be named",
  restrictionSource: "host", restrictions: "No photography inside the hall", attendeeList: "bounded", understand: "how the hall is run" });
// f.routes, f.axis, f.recDep, f.depCandidates, f.depRungs, f.recAccess, f.accCandidates, f.accRungs, f.handoffs, f.passCount
// f.checks, f.findings
K.choicesCSV(f)                                // menu, option, status, picked
const b = K.buildInput(f, "brief");            // or "host"
const wire = K.toWire(b.input);                // POST this to /estimate and /run
// then: const reply = R.normalize(R.parseReply(job.output.output), "brief");
// R.check(reply, b)                           // {status: kept or flagged, notes}

Get a token for the steps below from /tokens.html.

Step 1 — a tiny client helper

One function that sends JSON and unwraps the response. Paste a personal token from /tokens.html, or leave it empty and mint a guest token in step 2.

BASE="https://api.skillsafe.ai/v1/app-api"
TOKEN="paste-your-token-here"   # from https://host-visit.skillsafe.ai/tokens.html
api() { # api METHOD PATH [JSON-BODY]
  curl -s -X "$1" "$BASE$2" -H "Content-Type: application/json" \
    ${TOKEN:+-H "Authorization: Bearer $TOKEN"} ${3:+--data "$3"}
}

Step 2 — a token

A guest token is enough for /me and /estimate. A run is metered, so it needs a personal token: sign in on /tokens.html and copy it from there.

# a guest token (enough for /me and /estimate); a run needs your personal token from /tokens.html
TOKEN=$(curl -s -X POST "$BASE/guest" -H "Content-Type: application/json" -d '{"slug":"host-visit"}' | jq -r '.data.token')

Step 3 — GET /me

Who the token is (subject_type: user or guest) and the credit balance.

api GET /me | jq '.data | {subject_type, credits}'

Step 4 — POST /estimate

Free. The body is the run input itself, the bare object (never wrapped in {"input": ...}). hold_credits is a reservation, not the price; min_credits is what the balance must cover; model_alias reads gpt-terra.

# input.json: the run input object - {"task": "brief", "visit": "Visit: ...; the visit is the programme ...", "host": "Host: ...; yes, in writing ...", "facts": "Routing: ...; Value axis for the dependency menu: place ..."}
# - see the input table
api POST /estimate "$(cat input.json)" | jq '.data | {hold_credits, min_credits, model, model_alias, markup_bps, warnings}'

Step 5 — POST /run, then poll the job

Send an Idempotency-Key built from the lane and the input: a retry with the same key never bills twice. The page uses host-visit:<task>:<inputHash>:a<attempt> - the lane is part of the key - and its one automatic reformat retry is a new attempt number, named in the page as one extra run. A brief carries summary, routing, axis, dependency_candidates, dependency, access_candidates, access, deleted, restrictions, brief_sentence, handoffs, flips, checks and caveats; a host brief carries to, subject, understand, ask, see, repeat, will_not, confirm and note. Neither contains a digit. The code below prints the headline parts of either (list items are plain strings).

KEY="host-visit:brief:$(shasum -a 256 input.json | cut -c1-16):a1"
JOB=$(curl -s -X POST "$BASE/run" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: $KEY" --data @input.json | jq -r '.data.job_id')
while :; do
  J=$(api GET "/jobs/$JOB"); S=$(echo "$J" | jq -r '.data.status')
  case "$S" in succeeded|failed|cancelled) break;; esac; sleep 2
done
echo "$J" | jq -r '.data.output.output' > reply.json   # one JSON object, the reply contract
echo "$J" | jq '.data | {charged_credits, truncated}'
jq -r '.summary // .format, .note // .dependency, ((.handoffs // .caveats)[] | "\(.handoff // .caveat): \(.text // .text)")' reply.json
jq -r '.understand // .note // empty' reply.json   # what the audience is coming to understand (host brief)

Step 6 — POST /run-stream

The same run as Server-Sent Events, with the same input.json. Browsers receive progress ticks rather than text deltas; the final done event carries the reply.

# Server-Sent Events: tick/delta events while the job runs, then a final event with the job
curl -N -s -X POST "$BASE/run-stream" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: host-visit:brief:$(shasum -a 256 input.json | cut -c1-16):a1" --data @input.json