Run Sponsor Why from your own code

Both metered lanes are available over HTTP and each returns one JSON object. The division of labour: the page settles the pole's rules, the one segment and the discovery result, writes the honesty gate and flags every claim that contradicts it, re-ranks the value-category lead menu, checks an activity for every claimed category, checks the six JTBD parts and a proof under every claim, and scores the value equation - all free, in whykit.js. The run writes the value case, or the prospectus copy for the segment with the discovery questions for the next call; the page then holds the reply to its own board (whyreply.js). It never invents an audience number, a return rate, a sponsor quote, a lead count or an outcome, and never promises pipeline at a community-run event.

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":"sponsor-why"}), so no slug header is needed afterwards. Send it as Authorization: Bearer YOUR_TOKEN. The run body is the input object, sent bare.

Status	Code	Meaning
400	validation_error	The body is not a JSON object, or a required key (`task`, `event`, `evidence`, `program`, `facts`) is missing. `notes` may be an empty string.
401	unauthorized	No token, or a stale one. Mint a guest token or sign in again.
402	insufficient_credits	The balance is under `min_credits`. Price with `/estimate` first.
403	forbidden	A guest token tried to run: both lanes are metered and need a personal sign-in.
404	not_found	Unknown job id.
429	rate_limited	Back off and retry.
5xx	server_error	Transient. Retry with the same `Idempotency-Key` so a retry never double-bills.

The task field comes first

Two lanes, chosen by task:

case - the value case for the organizer to act on: the verdict, the segment, the honesty gate first, the lead and co-lead, one coherence row per claimed category, the six-part statement with a proof under every claim, the value-equation result, the evidence still to collect and the caveats.
story - the prospectus copy for this one segment, exactly as a sponsor reads it (headline, opener, what you get with its proof, what we do not offer, who attends, the track record, the next step), plus the discovery questions for the next call and a note.

A missing or unknown task is answered as case. Both lanes send the same six fields; for the story, the facts also carry the case's lead, coherence and proofs (the page fills these from the case). The notes field may be an empty string.

The input

Field	Required	What
`task`	yes	`case` or `story`. If it is missing or neither, do `case` and set `"task": "case"`.
`event`	yes	the event basics and the interview answers Q1 to Q11: name, dates, city, planned attendance (a plan, never audience evidence), format, the pole, the segment and the Who, the prospect's need and how it was heard, what the segment does today, the revenue close date, one-off or compounding, the effort ceiling, the target sponsor or tier and its diligence, the hiring pressure, and the JTBD Why, What After and Alternatives, and the sponsor's fully loaded cost.
`evidence`	yes	one line per audience-evidence row (metric, value, source, edition or date), the track record and program counts, and the first-edition substitutes.
`program`	yes	one line per program activity (what it serves, when), one line per How claim (category, proof instrument, label), and the will-not-offer list.
`notes`	no	pasted notes such as discovery-call notes; may be empty. A request in the notes is never a commitment.
`facts`	yes	the page's verdict, the self-set lines, the pole and its rules, the segment, the discovery result, the honesty gate, the lead menu and the lead, the coherence rows, the JTBD parts, the claims, the proof menu, the track record, the audience rows, the value equation, the buying-influence handling, the evidence to collect, the story's offer rows, the discovery probes - each item with its own must line - for the story task the case carried over, and every finding tagged `[fix]`, `[check]` or `[info]`.
`retry_note`	no	optional; if present, your previous reply was unusable - follow it.

The rules the model applies

Discovery comes first: the fit between event and sponsor is found in discovery, not assumed in a deck. The prospect's need is asked of the prospect - a call or a short exchange, never a guess from its job ads - written down in its own words, and mapped onto a category. A need no category can carry honestly goes on the not-offered list.
The pole bounds every promise. Community-run: no attendee contact list is ever given or sold, no speaking slot is purchasable, lead capture happens only when an attendee volunteers it, aggregate demographics are the honest substitute for lead data, and recruiting is conversation-based (office hours, a staffed table), never scanned data. Vendor/foundation-run: pipeline and consented lead retrieval are on the table, bounded by attendee consent. The pipeline category exists only at the vendor pole; at a community-run event it is deleted, not demoted.
Sponsorship buys placement and access, never a talk slot, a judging result, or influence over the program or roadmap.
One segment at a time: product-feedback buyer, recruiting buyer, brand buyer or community-member sponsor (the page's pipeline buyer is its own label for the vendor pole). Never blend segments into one statement.
The honesty gate comes first: what the event will not offer is written down before what it will, and an unavailable category is deleted now, because a category parked for later silently reappears in the deck.
The value-category lead: brand exposure is the default anchor; the need found in discovery picks the co-lead. Product feedback and recruiting pay off on-site; brand exposure and community goodwill compound over editions. A near revenue deadline promotes the on-site categories; a compounding mandate promotes the slow ones; a cooling hiring market demotes recruiting to an optional co-lead and promotes staff-free visibility; community goodwill leads for a sponsor drawn from the community; pipeline leads only at a vendor-run event with consented lead retrieval and a sponsor whose stated job is pipeline.
Offer-activity coherence: the program carries an activity for every category claimed - a hiring corner for recruiting, a hands-on feedback session for product feedback, a staffed demo space attendees opt into for selling. Sponsor activities stay outside the CFP program.
The six-part JTBD template, for one segment: Who (a budget-holding role, not a company), Why (the job to be done), What Before (the status quo), How (what the event genuinely delivers, bounded by the pole), What After (the sponsor's improved state), Alternatives (what competes for the same budget line, and why this event wins for this segment).
A proof point under every How claim, labelled evidenced or aspirational - an unlabeled claim reads as evidenced and fails diligence as invented. The instruments: returning-sponsor rate, program-content ratio, registration-form demographics, sponsor testimonials, post-event sponsor report, deep attendee survey. A first edition has no returning rate, no report and no prior demographics; its honest substitutes - the organizers' own track record, community size and engagement, a named commitment to a post-event report - are always flagged as first-edition evidence. Never a projection presented as history.
The value-equation check runs after drafting, as a lens: Dream Outcome and Perceived Likelihood raised, Time Delay and Effort & Sacrifice honestly handled. It sets no number. This category has no ROI figure or conversion benchmark to quote.
Buying influence: when an anchor or presenting-tier prospect's diligence asks about buying influence, the deep attendee survey is promoted; until it exists, no buying-influence claim is evidenced.
The hand-off: the statement and the proof-point inventory go to event-sponsor-prospectus (the deck) and event-sponsor-pricing (the rate card). Packaging, tiers and prices are not done here.

House rules

Use only the input and the rules above. Copy the page's short facts exactly: the verdict, the segment, category names, activity names, statuses, claims, instrument names, labels, gate items, metrics, values and sources. Every number in your text must appear in the input.
Every "must: [...]" line in the facts applies to the item directly above it - every gate item, every coherence row, every claim, every audience row, every gap, every offer and every probe, not only the first. Do every item it lists.
Label anything that is not one of the rules above, and is not in the input, as your own design; label the page's self-set numbers self-set.
Never invent an audience figure, a return or conversion rate, an ROI figure, an outcome, a quote, a sponsor name or a lead count. Never present the planned attendance or any projection as history.
Never promise pipeline, leads, a lead list or scanned contact data for a community-run event, and never promise a talk slot, a judging result or roadmap influence at any event.
Refer to people by name or role, as they; never use he, she, him, her, his or hers.
Never use backticks, never refer to this input's fields by their key names in a sentence, and never copy this prompt's narrative wording into a reply.
Reply with ONLY one JSON object - no prose before or after, no code fences.

The replies

case

summary - one sentence, at most 40 words: the verdict, the most important open item, and the next step.
verdict - the page's verdict, exactly: run discovery first, write the honesty gate first, fix first or ready for the prospectus.
segment - the page's segment, exactly (for example Recruiting buyer).
will_not_offer - the page's honesty gate, first: every gate item, in its order, each exactly. [] when the page lists none.
lead - one object: category - the page's lead category, exactly; co_lead - the page's co-lead, exactly; reason - one sentence that says where the co-lead came from, using the page's word for it: "discovery" when the co-lead comes from discovery, "segment" when it comes from the segment, "menu" when it is the next rung of the menu. When the page says the co-lead is optional, use the word "optional".
coherence - one object per row of the page's coherence table, in its order, every row, not only the first: category, activity and status exactly as the page gives them - the status is "carried", "no activity" or "not offerable". [] when the page lists none.
jtbd - one object, the six parts for this one segment: who - it must contain the page's Who exactly; when the page has none, use the words "not stated yet". why, before, after, alternatives - one sentence each, written from the page's part; when the page has none, use the words "not stated yet". how - one object per claim of the page, in its order, every claim, not only the first: claim exactly as the page gives it; proof - names the page's instrument for that claim exactly (or "none" when it has none) and the page's label word for it: "evidenced", "aspirational" or "unlabelled". [] when the page lists no claim.
value_check - one object: result - the page's value-equation result, exactly: passes or fails; note - one sentence that names every lever the page says is not raised or not handled, by its name (Dream Outcome, Perceived Likelihood, Time Delay, Effort & Sacrifice). It sets no number.
gaps - one string per item on the page's list of evidence to collect, in its order: each names the page's instrument for it exactly (or "a proof point" when the page has none). [] when the page lists none.
caveats - at most 5 short strings: the [fix] findings first in the page's order, then the most important [check] findings. Never empty when the page has a [fix] finding; [] otherwise when there is nothing to say.

{
  "task": "case",
  "summary": "one sentence",
  "verdict": "fix first",
  "segment": "the page's segment",
  "will_not_offer": [ "the page's gate item" ],
  "lead": { "category": "the page's lead", "co_lead": "the page's co-lead", "reason": "one sentence" },
  "coherence": [ { "category": "the page's category", "activity": "the page's activity", "status": "carried" } ],
  "jtbd": {
    "who": "the page's Who",
    "why": "one sentence",
    "before": "one sentence",
    "how": [ { "claim": "the page's claim", "proof": "the page's instrument - evidenced" } ],
    "after": "one sentence",
    "alternatives": "one sentence"
  },
  "value_check": { "result": "passes", "note": "one sentence" },
  "gaps": [ "the page's instrument, for the claim" ],
  "caveats": [ "a caveat" ]
}

The page holds it to its own board: the verdict and the segment exactly; every gate item, in order; the lead and co-lead exactly, with "discovery", "segment" or "menu" in the reason (and "optional" when it is); every coherence row's category, activity and status; the Who; every claim exactly with its instrument and its label ("evidenced", "aspirational" or "unlabelled") in the proof; the value-equation result with every failing lever named; one gap per piece of evidence to collect; caveats when the page has a fix; and no number, quote, ROI figure, promise or pronoun the input does not hold. Required words are read tolerantly: "not yet evidenced" is aspirational, "recorded on the call" is discovery.

story

headline - one line for this segment. Never promise leads, a lead list, a talk slot, a judging result or roadmap influence.
opener - one paragraph naming the segment's job, using the page's job word for it: "feedback", "hiring", "awareness", "community" or "pipeline".
what_you_get - one object per row of the page's story offer list, in its order, every row, not only the first: category exactly as the page gives it; benefit - one or two sentences on what the event genuinely delivers (for recruiting at a community-run event, use the word "conversation" - never scanned data); proof - names the page's instrument exactly and the page's label word, "evidenced" or "aspirational". Only the page's rows - a category with an activity and a proof. [] when the page lists none.
what_we_do_not_offer - the honesty gate as stated: every gate item of the page, in its order, each exactly. [] when the page lists none.
audience - one object per row of the page's audience list, in its order, every row: metric, value and source exactly as the page gives them. Only the page's numbers, each with its source. [] when the page lists none.
track_record - one or two sentences: for a first edition, use the words "first edition" and name a substitute (the organizers' track record, the community numbers or the named commitment); otherwise name the editions run, with the page's number.
next_step - one sentence asking the sponsor for a call or a reply (use the word "call").
discovery_questions - one question per probe of the page, in its order, every probe: each ends with "?" and uses the probe's word ("need", the segment's word, "today", "pressure", "diligence"). Ask; never propose.
note - one sentence: when the page says "ready: no", begin with "Not ready for the prospectus:" and say what to fix first; otherwise use the word "prospectus" and say what happens next.

{
  "task": "story",
  "headline": "one line",
  "opener": "one paragraph",
  "what_you_get": [ { "category": "the page's category", "benefit": "one or two sentences", "proof": "the page's instrument - evidenced" } ],
  "what_we_do_not_offer": [ "the page's gate item" ],
  "audience": [ { "metric": "the page's metric", "value": "the page's value", "source": "the page's source" } ],
  "track_record": "one or two sentences",
  "next_step": "one sentence",
  "discovery_questions": [ "a question?" ],
  "note": "one sentence"
}

The page requires the segment's job word in the opener ("feedback", "hiring", "awareness", "community" or "pipeline"); one offer per page offer row with the category exactly and the instrument and label in the proof, and "conversation" for recruiting at a community-run event; the honesty gate exactly, in order; every usable audience row exactly; "first edition" and a substitute, or the editions run, in the track record; "call" in the next step; one question per probe, ending "?" with its word; a note beginning "Not ready for the prospectus:" unless the page is ready; and no lead promise at a community-run event.

Worked examples - both lanes

Four of the page's five free samples (fictional events, organizations, products and people). Each input is exactly what the page sends; each reply is the saved reply the sample replays, shipped unedited; the last line is the page's own check. The story inputs carry their sample's saved case, as the handoff does.

A 600-person community conference, recruiting buyer, a lead-gen claim slipped in - case

Verdict: fix first; ready: no; pole: community-run; segment: Recruiting buyer; lead: Brand exposure; co-lead: Recruiting; 4 claims, 3 gate items; value check: fails; 5 fix-level findings.

Input:

{
 "task": "case",
 "event": "Event: \"Kestrel DevConf 2027\" | dates: 2027-05-20 to 2027-05-21 | city: \"Kestrel Bay\" | planned attendance: 600 (the organizer's plan - not audience evidence) | format: \"a multi-day conference\" | as of: 2027-01-15\nQ1 pole: \"community-run\" | consented lead retrieval in place: no\nQ2 segment: \"Recruiting buyer\" | JTBD Who: \"Talent-acquisition leads hiring backend engineers\"\nQ3 the prospect's stated need, in its own words: \"We need senior backend engineers who already know event-driven systems - job boards bring us volume, not fit.\" | heard through: \"a call or short exchange with the prospect\"\nQ6 and JTBD What Before - what the segment does today without the event: \"Job-board ads, agency fees and cold LinkedIn outreach with low response\"\nQ7 revenue must close by: 2027-03-31 (75 days from the as-of date) | Q8 relationship: \"a compounding multi-edition asset\" | Q9 evidence effort ceiling: \"data already held only\" | Q9 organizer hours: not set\nQ10 target sponsor or tier: \"Nordlake Bank early-talent team, Gold tier\" | tier: \"another tier\" | its diligence asks about buying influence or seniority mix: no\nQ11 the segment's hiring pressure: \"recruiting now\"\nJTBD Why: \"Fill backend roles with candidates who have real distributed-systems exposure\" | JTBD What After: \"A warm, self-selected shortlist of candidates who already met the team\" | JTBD Alternatives: \"Career fairs give volume without self-selection, and job-board placement gives no conversation\"\nThe sponsor's fully loaded cost (fee, booth build, travel, staff days): \"The fee plus two engineers at the hiring corner for both days\"",
 "evidence": "Audience evidence (Q4) - 5 rows, one per line:\n- row 1: metric: \"Attendees\" | value: \"540\" | source: \"ticketing export\" | edition or date: \"2025 edition\"\n- row 2: metric: \"Attendees\" | value: \"610\" | source: \"ticketing export\" | edition or date: \"2026 edition\"\n- row 3: metric: \"Senior engineers or above\" | value: \"58%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n- row 4: metric: \"From companies of 200+ staff\" | value: \"41%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n- row 5: metric: \"Travelled from outside the region\" | value: \"22%\" | source: \"registration form\" | edition or date: \"2026 edition\"\nTrack record (Q5): editions run: 2 | sponsors eligible to return: 9 | returned: 6 | post-event sponsor report held: yes | attributable sponsor testimonials on hand: 0\nProgram counts: technical sessions: 32 | sponsor-delivered sessions: 0\nFirst-edition substitutes: organizers' track record: \"none\" | community size and engagement: \"none\" | a named commitment to a post-event report: no",
 "program": "Program activities - 3, one per line:\n- activity 1: \"Hiring corner\" | serves: \"Recruiting\" | when: \"both days, at every break\"\n- activity 2: \"Sponsor loop on the stage screen\" | serves: \"Brand exposure\" | when: \"between talks\"\n- activity 3: \"Community dinner\" | serves: \"Community goodwill\" | when: \"day 1 evening\"\nHow claims - 4, one per line:\n- claim 1: \"Staffed hiring-corner conversations with backend engineers\" | category: \"Recruiting\" | proof instrument: \"Registration-form demographics\" | label: \"evidenced\"\n- claim 2: \"Logo on the stage screen and the event site\" | category: \"Brand exposure\" | proof instrument: \"Returning-sponsor rate\" | label: \"evidenced\"\n- claim 3: \"Lead generation from the attendee list\" | category: \"Pipeline\" | proof instrument: \"Post-event sponsor report\" | label: \"evidenced\"\n- claim 4: \"Employer-brand lift with senior engineers\" | category: \"Brand exposure\" | proof instrument: \"none\" | label: \"aspirational\"\nThe honesty gate - what this event will not offer - 3, one per line:\n- will not offer 1: \"No attendee contact lists, given or sold\"\n- will not offer 2: \"No speaking slots for sponsors\"\n- will not offer 3: \"No badge scanning\"",
 "notes": "Call with the Nordlake talent team, 2027-01-10: they plan 12 backend hires this year; job boards bring volume, not fit. They asked whether we share attendee lists - we said no.",
 "facts": "Verdict: \"fix first\" | ready: no | fix-level findings: 5\nSelf-set lines: a revenue close date under 60 days from the as-of date is near | a summary cap of 40 words | at most 5 caveats. Never invented: an audience figure, a return or conversion rate, an ROI figure, a sponsor quote, a sponsor name, a lead count, an outcome.\nBoundary: sponsorship buys placement and access, never a talk slot, a judging result, or influence over the program or roadmap.\nPole (Q1): \"community-run\" | rules: [no attendee contact list is ever given or sold; no speaking slot is purchasable; lead capture happens only when an attendee volunteers it; aggregate demographics are the honest substitute for lead data; pipeline is deleted, not demoted] | categories that can honestly be offered: [\"Brand exposure\"; \"Product feedback\"; \"Recruiting\"; \"Community goodwill\"]\nSegment (Q2): \"Recruiting buyer\" | title signals: \"Hiring / Recruiting / Talent Acquisition / HR titles\" | segments the Who names: [\"Recruiting buyer\"]\n  segment must: [segment \"Recruiting buyer\" exactly]\nDiscovery (Q3): need: \"We need senior backend engineers who already know event-driven systems - job boards bring us volume, not fit.\" | heard through: \"a call or short exchange with the prospect\" | from the prospect: yes | maps to: \"Recruiting\"\nThe honesty gate (step 3) - will not offer, in this order - 3:\n- gate 1: \"No attendee contact lists, given or sold\"\n- gate 2: \"No speaking slots for sponsors\"\n- gate 3: \"No badge scanning\"\n  gate must: [will_not_offer copies every gate item above, in this order, each exactly; what_we_do_not_offer copies every gate item above, in this order, each exactly]\nValue-category lead menu (step 4), re-ranked - pick: \"Brand exposure\"\n- rung 1: \"Brand exposure\" | moved: promoted by Q8: a compounding multi-edition mandate promotes the slow categories\n- rung 2: \"Recruiting\" | moved: promoted by Q11: the target companies are recruiting tech staff now\n- rung 3: \"Product feedback\"\n- rung 4: \"Community goodwill\" | moved: promoted by Q8: a compounding multi-edition mandate promotes the slow categories\n- deleted, not demoted: \"Pipeline\" | reason: Q1: a community-run event - delete pipeline, don't demote it: a demoted pipeline promise parked at the bottom of the menu reappears in the prospectus as scope\nLead: category: \"Brand exposure\" | co-lead: \"Recruiting\" | co-lead from: \"discovery\" | co-lead optional: no\n  lead must: [category \"Brand exposure\" exactly; co_lead \"Recruiting\" exactly; reason uses the word \"discovery\"]\nCoherence (step 5) - one row per claimed category, in this order - 3:\n- row 1: \"Recruiting\" | activity: \"Hiring corner\" | status: \"carried\"\n  must: [category \"Recruiting\" exactly; activity \"Hiring corner\" exactly; status \"carried\" exactly]\n- row 2: \"Brand exposure\" | activity: \"Sponsor loop on the stage screen\" | status: \"carried\"\n  must: [category \"Brand exposure\" exactly; activity \"Sponsor loop on the stage screen\" exactly; status \"carried\" exactly]\n- row 3: \"Pipeline\" | activity: \"none\" | status: \"not offerable\"\n  must: [category \"Pipeline\" exactly; activity \"none\" exactly; status \"not offerable\" exactly]\nJTBD (step 6), one segment - parts: [Who: complete; Why: complete; What Before: complete; How: complete; What After: complete; Alternatives: complete]\n  jtbd must: [who contains \"Talent-acquisition leads hiring backend engineers\"; why, before, after and alternatives each say the part above, or the words \"not stated yet\" when it is missing]\nHow claims (step 7) - one per claim, in this order - 4:\n- claim 1: \"Staffed hiring-corner conversations with backend engineers\" | category: \"Recruiting\" | proof: \"Registration-form demographics\" | label: \"evidenced\" | evidence on hand: yes | payoff: \"lands on-site\" | in the story: yes\n  must: [claim \"Staffed hiring-corner conversations with backend engineers\" exactly; proof names \"Registration-form demographics\" and the word \"evidenced\"]\n- claim 2: \"Logo on the stage screen and the event site\" | category: \"Brand exposure\" | proof: \"Returning-sponsor rate\" | label: \"evidenced\" | evidence on hand: yes | payoff: \"compounds over editions\" | in the story: yes\n  must: [claim \"Logo on the stage screen and the event site\" exactly; proof names \"Returning-sponsor rate\" and the word \"evidenced\"]\n- claim 3: \"Lead generation from the attendee list\" | category: \"Pipeline\" | proof: \"Post-event sponsor report\" | label: \"evidenced\" | evidence on hand: yes | payoff: \"captured on-site, pays off after (the page's reading)\" | in the story: no\n  must: [claim \"Lead generation from the attendee list\" exactly; proof names \"Post-event sponsor report\" and the word \"evidenced\"]\n- claim 4: \"Employer-brand lift with senior engineers\" | category: \"Brand exposure\" | proof: \"none\" | label: \"aspirational\" | evidence on hand: no | payoff: \"compounds over editions\" | in the story: no\n  must: [claim \"Employer-brand lift with senior engineers\" exactly; proof names \"none\" and the word \"aspirational\"]\nProof-point instruments menu (step 7), re-ranked - pick: \"Returning-sponsor rate\"\n- rung 1: \"Returning-sponsor rate\"\n- rung 2: \"Registration-form demographics\"\n- rung 3: \"Program-content ratio\"\n- rung 4: \"Post-event sponsor report\"\n- rung 5: \"Sponsor testimonials\" | moved: demoted by Q9: the effort ceiling is data already held\n- rung 6: \"Deep attendee survey\" | moved: demoted by Q9: the effort ceiling is data already held\n- notes: Default rung: compute the returning-sponsor rate and the program-content ratio now, and change the registration form this edition to capture role, seniority and company size in aggregate - two or three required fields.\nTrack record (Q5): editions run: 2 | first edition: no | returning-sponsor rate: \"6 of 9 eligible returned (67%)\" | post-event sponsor report: yes | testimonials on hand: 0 | program-content ratio: \"32 technical to 0 sponsor-delivered\"\n  track record must: [track_record names the editions run, 2]\nAudience for the story - usable rows only, in this order - 5:\n- audience 1: metric: \"Attendees\" | value: \"540\" | source: \"ticketing export\" | edition or date: \"2025 edition\"\n  must: [metric \"Attendees\" exactly; value \"540\" exactly; source \"ticketing export\" exactly]\n- audience 2: metric: \"Attendees\" | value: \"610\" | source: \"ticketing export\" | edition or date: \"2026 edition\"\n  must: [metric \"Attendees\" exactly; value \"610\" exactly; source \"ticketing export\" exactly]\n- audience 3: metric: \"Senior engineers or above\" | value: \"58%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n  must: [metric \"Senior engineers or above\" exactly; value \"58%\" exactly; source \"registration form\" exactly]\n- audience 4: metric: \"From companies of 200+ staff\" | value: \"41%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n  must: [metric \"From companies of 200+ staff\" exactly; value \"41%\" exactly; source \"registration form\" exactly]\n- audience 5: metric: \"Travelled from outside the region\" | value: \"22%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n  must: [metric \"Travelled from outside the region\" exactly; value \"22%\" exactly; source \"registration form\" exactly]\nEvidence rows left out of the story (no number, no source, no date, or history at a first edition): [none]\nValue equation (step 8, after drafting): result: \"fails\" | levers: [Dream Outcome: raised; Perceived Likelihood: not raised; Time Delay: handled; Effort & Sacrifice: handled]\n  value must: [result \"fails\" exactly; note names every lever not raised or handled: \"Perceived Likelihood\"]\nBuying influence (Q10): target: \"Nordlake Bank early-talent team, Gold tier\" | tier: \"another tier\" | diligence asks about it: no | deep attendee survey promoted: no | handling: no buying-influence question in the diligence: registration-form demographics carry the composition claims\nTo collect before the next edition - one per claim not yet evidenced, in this order - 1:\n- gap 1: instrument: \"a proof point\" | for claim: \"Employer-brand lift with senior engineers\"\n  must: [names \"a proof point\"]\nStory - what you get, one row per claim the story can offer (a carried category and a proof), in this order - 2:\n- offer 1: category: \"Recruiting\" | claim: \"Staffed hiring-corner conversations with backend engineers\" | proof: \"Registration-form demographics\" | label: \"evidenced\"\n  must: [category \"Recruiting\" exactly; proof names \"Registration-form demographics\" and the word \"evidenced\"; benefit uses the word \"conversation\"]\n- offer 2: category: \"Brand exposure\" | claim: \"Logo on the stage screen and the event site\" | proof: \"Returning-sponsor rate\" | label: \"evidenced\"\n  must: [category \"Brand exposure\" exactly; proof names \"Returning-sponsor rate\" and the word \"evidenced\"]\nDiscovery questions for the next call - the Q3 probes for this segment, in this order - 5:\n- probe 1: what this partner actually needs from the event, in its own words (Q3)\n  must: [one question ending \"?\" that uses the word \"need\"]\n- probe 2: the hiring it is doing now, or the employer brand it wants (Q3)\n  must: [one question ending \"?\" that uses the word \"hiring\"]\n- probe 3: what it does today without the event (Q6)\n  must: [one question ending \"?\" that uses the word \"today\"]\n- probe 4: its hiring pressure now - recruiting, holding or cutting (Q11)\n  must: [one question ending \"?\" that uses the word \"pressure\"]\n- probe 5: whether its own diligence checklist asks about buying influence or seniority mix (Q10)\n  must: [one question ending \"?\" that uses the word \"diligence\"]\nCase must: [summary at most 40 words; verdict \"fix first\" exactly; caveats carry the fix findings first, at most 5]\nStory must: [opener names the segment's job (the word \"hiring\"); next_step asks for a call or a reply (the word \"call\")] | story note must: [begin \"Not ready for the prospectus:\" and say what to fix first]\nHand-off: the statement and the proof-point inventory go to event-sponsor-prospectus (the deck) and event-sponsor-pricing (the rate card); packaging, tiers and prices are not done here.\nFindings (14):\n[fix] claim_pole_3 (pole): \"Lead generation from the attendee list\" promises leads at a community-run event - structurally undeliverable: no lists, no scanning, and the organizer's own published rules say so. Substitute aggregate demographics plus conversation-based recruiting and feedback access.\n[fix] contradict_3 (gate): \"Lead generation from the attendee list\" contradicts the honesty gate (\"No attendee contact lists, given or sold\") - delete it now; a claim parked for later silently reappears in the deck.\n[fix] barred_pipeline (coherence): Pipeline is claimed but cannot be offered here (pipeline exists only at the vendor pole) - delete the claim.\n[fix] proof_none_4 (proof): \"Employer-brand lift with senior engineers\" carries no proof point - attach one a diligent sponsor would accept, from the instruments menu, or drop the claim.\n[fix] value_fails (value): The value-equation check fails on Perceived Likelihood (not every How claim carries a proof point a diligent sponsor would accept) - a draft that only lists benefits fails, whatever its length.\n[info] pole_rules (pole): Q1: community-run - no attendee contact list is ever given or sold, no speaking slot is purchasable, lead capture happens only when an attendee volunteers it, aggregate demographics are the honest substitute for lead data and pipeline is deleted, not demoted. The honest mix is brand exposure, recruiting via real conversations, product feedback from a technical opinionated audience, and community goodwill.\n[info] segment_titles (segment): Q2: Recruiting buyer - title signals: Hiring / Recruiting / Talent Acquisition / HR titles.\n[info] notes (discovery): The pasted notes are context: a request in the notes is never a commitment.\n[info] ratio_guarantee (record): Program-content ratio: 32 technical sessions to 0 sponsor-delivered - at a community-run event the ratio is a structural guarantee; say so in the statement.\n[info] lead (lead): Lead: Brand exposure; co-lead: Recruiting - picked by the need found in discovery.\n[info] recruit_talk (lead): At a community-run event recruiting is conversation-based - office hours, a staffed table, engineers visibly present - never scanned data. Say so explicitly.\n[info] value_lens (value): The value equation is a post-draft scoring lens, never the structure to fill in: Dream Outcome and Perceived Likelihood raised, Time Delay and Effort & Sacrifice honestly handled. It sets no number.\n[info] handoff (scope): Hand the statement and the proof-point inventory to event-sponsor-prospectus (the deck) and event-sponsor-pricing (the rate card) - packaging, tiers and prices are not done here. Validate it with the organizer section by section, never as one block.\n[info] scope (scope): Sponsorship buys placement and access, never a talk slot, a judging result, or influence over the program or roadmap. The page never invents an audience number, a return or conversion rate, a sponsor quote, a sponsor name, a lead count or an outcome."
}

Reply:

{
 "task": "case",
 "summary": "Fix first: a lead-generation claim breaks the community pole and the honesty gate, and one brand claim has no proof - delete the first, prove the second, then write the story.",
 "verdict": "fix first",
 "segment": "Recruiting buyer",
 "will_not_offer": [
  "No attendee contact lists, given or sold",
  "No speaking slots for sponsors",
  "No badge scanning"
 ],
 "lead": {
  "category": "Brand exposure",
  "co_lead": "Recruiting",
  "reason": "The need the prospect stated on the discovery call maps to Recruiting, so it is the co-lead beside Brand exposure."
 },
 "coherence": [
  {
   "category": "Recruiting",
   "activity": "Hiring corner",
   "status": "carried"
  },
  {
   "category": "Brand exposure",
   "activity": "Sponsor loop on the stage screen",
   "status": "carried"
  },
  {
   "category": "Pipeline",
   "activity": "none",
   "status": "not offerable"
  }
 ],
 "jtbd": {
  "who": "Talent-acquisition leads hiring backend engineers",
  "why": "Fill backend roles with candidates who have real distributed-systems exposure.",
  "before": "Job-board ads, agency fees and cold LinkedIn outreach with low response.",
  "how": [
   {
    "claim": "Staffed hiring-corner conversations with backend engineers",
    "proof": "Registration-form demographics - evidenced"
   },
   {
    "claim": "Logo on the stage screen and the event site",
    "proof": "Returning-sponsor rate - evidenced"
   },
   {
    "claim": "Lead generation from the attendee list",
    "proof": "Post-event sponsor report - evidenced"
   },
   {
    "claim": "Employer-brand lift with senior engineers",
    "proof": "none - aspirational"
   }
  ],
  "after": "A warm, self-selected shortlist of candidates who already met the team.",
  "alternatives": "Career fairs give volume without self-selection, and job-board placement gives no conversation."
 },
 "value_check": {
  "result": "fails",
  "note": "Fails on Perceived Likelihood (not every How claim carries a proof point a diligent sponsor would accept)."
 },
 "gaps": [
  "A proof point for Employer-brand lift with senior engineers"
 ],
 "caveats": [
  "\"Lead generation from the attendee list\" promises leads at a community-run event - structurally undeliverable: no lists, no scanning, and the organizer's own published rules say so.",
  "\"Lead generation from the attendee list\" contradicts the honesty gate (\"No attendee contact lists, given or sold\") - delete it now; a claim parked for later silently reappears in the deck.",
  "Pipeline is claimed but cannot be offered here (pipeline exists only at the vendor pole) - delete the claim.",
  "\"Employer-brand lift with senior engineers\" carries no proof point - attach one a diligent sponsor would accept, from the instruments menu, or drop the claim.",
  "The value-equation check fails on Perceived Likelihood (not every How claim carries a proof point a diligent sponsor would accept) - a draft that only lists benefits fails, whatever its length."
 ]
}

The page's check: kept - nothing to flag

The same, cleaned - every claim proven - story

Verdict: ready for the prospectus; ready: yes; pole: community-run; segment: Recruiting buyer; lead: Brand exposure; co-lead: Recruiting; 3 claims, 3 gate items; value check: passes; 0 fix-level findings.

Input:

{
 "task": "story",
 "event": "Event: \"Kestrel DevConf 2027\" | dates: 2027-05-20 to 2027-05-21 | city: \"Kestrel Bay\" | planned attendance: 600 (the organizer's plan - not audience evidence) | format: \"a multi-day conference\" | as of: 2027-01-15\nQ1 pole: \"community-run\" | consented lead retrieval in place: no\nQ2 segment: \"Recruiting buyer\" | JTBD Who: \"Talent-acquisition leads hiring backend engineers\"\nQ3 the prospect's stated need, in its own words: \"We need senior backend engineers who already know event-driven systems - job boards bring us volume, not fit.\" | heard through: \"a call or short exchange with the prospect\"\nQ6 and JTBD What Before - what the segment does today without the event: \"Job-board ads, agency fees and cold LinkedIn outreach with low response\"\nQ7 revenue must close by: 2027-03-31 (75 days from the as-of date) | Q8 relationship: \"a compounding multi-edition asset\" | Q9 evidence effort ceiling: \"data already held only\" | Q9 organizer hours: not set\nQ10 target sponsor or tier: \"Nordlake Bank early-talent team, Gold tier\" | tier: \"another tier\" | its diligence asks about buying influence or seniority mix: no\nQ11 the segment's hiring pressure: \"recruiting now\"\nJTBD Why: \"Fill backend roles with candidates who have real distributed-systems exposure\" | JTBD What After: \"A warm, self-selected shortlist of candidates who already met the team\" | JTBD Alternatives: \"Career fairs give volume without self-selection, and job-board placement gives no conversation\"\nThe sponsor's fully loaded cost (fee, booth build, travel, staff days): \"The fee plus two engineers at the hiring corner for both days\"",
 "evidence": "Audience evidence (Q4) - 5 rows, one per line:\n- row 1: metric: \"Attendees\" | value: \"540\" | source: \"ticketing export\" | edition or date: \"2025 edition\"\n- row 2: metric: \"Attendees\" | value: \"610\" | source: \"ticketing export\" | edition or date: \"2026 edition\"\n- row 3: metric: \"Senior engineers or above\" | value: \"58%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n- row 4: metric: \"From companies of 200+ staff\" | value: \"41%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n- row 5: metric: \"Travelled from outside the region\" | value: \"22%\" | source: \"registration form\" | edition or date: \"2026 edition\"\nTrack record (Q5): editions run: 2 | sponsors eligible to return: 9 | returned: 6 | post-event sponsor report held: yes | attributable sponsor testimonials on hand: 0\nProgram counts: technical sessions: 32 | sponsor-delivered sessions: 0\nFirst-edition substitutes: organizers' track record: \"none\" | community size and engagement: \"none\" | a named commitment to a post-event report: no",
 "program": "Program activities - 3, one per line:\n- activity 1: \"Hiring corner\" | serves: \"Recruiting\" | when: \"both days, at every break\"\n- activity 2: \"Sponsor loop on the stage screen\" | serves: \"Brand exposure\" | when: \"between talks\"\n- activity 3: \"Community dinner\" | serves: \"Community goodwill\" | when: \"day 1 evening\"\nHow claims - 3, one per line:\n- claim 1: \"Staffed hiring-corner conversations with backend engineers\" | category: \"Recruiting\" | proof instrument: \"Registration-form demographics\" | label: \"evidenced\"\n- claim 2: \"Logo on the stage screen and the event site\" | category: \"Brand exposure\" | proof instrument: \"Returning-sponsor rate\" | label: \"evidenced\"\n- claim 3: \"Employer-brand lift with senior engineers\" | category: \"Brand exposure\" | proof instrument: \"Registration-form demographics\" | label: \"evidenced\"\nThe honesty gate - what this event will not offer - 3, one per line:\n- will not offer 1: \"No attendee contact lists, given or sold\"\n- will not offer 2: \"No speaking slots for sponsors\"\n- will not offer 3: \"No badge scanning\"",
 "notes": "Call with the Nordlake talent team, 2027-01-10: they plan 12 backend hires this year; job boards bring volume, not fit. They asked whether we share attendee lists - we said no.",
 "facts": "Verdict: \"ready for the prospectus\" | ready: yes | fix-level findings: 0\nSelf-set lines: a revenue close date under 60 days from the as-of date is near | a summary cap of 40 words | at most 5 caveats. Never invented: an audience figure, a return or conversion rate, an ROI figure, a sponsor quote, a sponsor name, a lead count, an outcome.\nBoundary: sponsorship buys placement and access, never a talk slot, a judging result, or influence over the program or roadmap.\nPole (Q1): \"community-run\" | rules: [no attendee contact list is ever given or sold; no speaking slot is purchasable; lead capture happens only when an attendee volunteers it; aggregate demographics are the honest substitute for lead data; pipeline is deleted, not demoted] | categories that can honestly be offered: [\"Brand exposure\"; \"Product feedback\"; \"Recruiting\"; \"Community goodwill\"]\nSegment (Q2): \"Recruiting buyer\" | title signals: \"Hiring / Recruiting / Talent Acquisition / HR titles\" | segments the Who names: [\"Recruiting buyer\"]\n  segment must: [segment \"Recruiting buyer\" exactly]\nDiscovery (Q3): need: \"We need senior backend engineers who already know event-driven systems - job boards bring us volume, not fit.\" | heard through: \"a call or short exchange with the prospect\" | from the prospect: yes | maps to: \"Recruiting\"\nThe honesty gate (step 3) - will not offer, in this order - 3:\n- gate 1: \"No attendee contact lists, given or sold\"\n- gate 2: \"No speaking slots for sponsors\"\n- gate 3: \"No badge scanning\"\n  gate must: [will_not_offer copies every gate item above, in this order, each exactly; what_we_do_not_offer copies every gate item above, in this order, each exactly]\nValue-category lead menu (step 4), re-ranked - pick: \"Brand exposure\"\n- rung 1: \"Brand exposure\" | moved: promoted by Q8: a compounding multi-edition mandate promotes the slow categories\n- rung 2: \"Recruiting\" | moved: promoted by Q11: the target companies are recruiting tech staff now\n- rung 3: \"Product feedback\"\n- rung 4: \"Community goodwill\" | moved: promoted by Q8: a compounding multi-edition mandate promotes the slow categories\n- deleted, not demoted: \"Pipeline\" | reason: Q1: a community-run event - delete pipeline, don't demote it: a demoted pipeline promise parked at the bottom of the menu reappears in the prospectus as scope\nLead: category: \"Brand exposure\" | co-lead: \"Recruiting\" | co-lead from: \"discovery\" | co-lead optional: no\n  lead must: [category \"Brand exposure\" exactly; co_lead \"Recruiting\" exactly; reason uses the word \"discovery\"]\nCoherence (step 5) - one row per claimed category, in this order - 2:\n- row 1: \"Recruiting\" | activity: \"Hiring corner\" | status: \"carried\"\n  must: [category \"Recruiting\" exactly; activity \"Hiring corner\" exactly; status \"carried\" exactly]\n- row 2: \"Brand exposure\" | activity: \"Sponsor loop on the stage screen\" | status: \"carried\"\n  must: [category \"Brand exposure\" exactly; activity \"Sponsor loop on the stage screen\" exactly; status \"carried\" exactly]\nJTBD (step 6), one segment - parts: [Who: complete; Why: complete; What Before: complete; How: complete; What After: complete; Alternatives: complete]\n  jtbd must: [who contains \"Talent-acquisition leads hiring backend engineers\"; why, before, after and alternatives each say the part above, or the words \"not stated yet\" when it is missing]\nHow claims (step 7) - one per claim, in this order - 3:\n- claim 1: \"Staffed hiring-corner conversations with backend engineers\" | category: \"Recruiting\" | proof: \"Registration-form demographics\" | label: \"evidenced\" | evidence on hand: yes | payoff: \"lands on-site\" | in the story: yes\n  must: [claim \"Staffed hiring-corner conversations with backend engineers\" exactly; proof names \"Registration-form demographics\" and the word \"evidenced\"]\n- claim 2: \"Logo on the stage screen and the event site\" | category: \"Brand exposure\" | proof: \"Returning-sponsor rate\" | label: \"evidenced\" | evidence on hand: yes | payoff: \"compounds over editions\" | in the story: yes\n  must: [claim \"Logo on the stage screen and the event site\" exactly; proof names \"Returning-sponsor rate\" and the word \"evidenced\"]\n- claim 3: \"Employer-brand lift with senior engineers\" | category: \"Brand exposure\" | proof: \"Registration-form demographics\" | label: \"evidenced\" | evidence on hand: yes | payoff: \"compounds over editions\" | in the story: yes\n  must: [claim \"Employer-brand lift with senior engineers\" exactly; proof names \"Registration-form demographics\" and the word \"evidenced\"]\nProof-point instruments menu (step 7), re-ranked - pick: \"Returning-sponsor rate\"\n- rung 1: \"Returning-sponsor rate\"\n- rung 2: \"Registration-form demographics\"\n- rung 3: \"Program-content ratio\"\n- rung 4: \"Post-event sponsor report\"\n- rung 5: \"Sponsor testimonials\" | moved: demoted by Q9: the effort ceiling is data already held\n- rung 6: \"Deep attendee survey\" | moved: demoted by Q9: the effort ceiling is data already held\n- notes: Default rung: compute the returning-sponsor rate and the program-content ratio now, and change the registration form this edition to capture role, seniority and company size in aggregate - two or three required fields.\nTrack record (Q5): editions run: 2 | first edition: no | returning-sponsor rate: \"6 of 9 eligible returned (67%)\" | post-event sponsor report: yes | testimonials on hand: 0 | program-content ratio: \"32 technical to 0 sponsor-delivered\"\n  track record must: [track_record names the editions run, 2]\nAudience for the story - usable rows only, in this order - 5:\n- audience 1: metric: \"Attendees\" | value: \"540\" | source: \"ticketing export\" | edition or date: \"2025 edition\"\n  must: [metric \"Attendees\" exactly; value \"540\" exactly; source \"ticketing export\" exactly]\n- audience 2: metric: \"Attendees\" | value: \"610\" | source: \"ticketing export\" | edition or date: \"2026 edition\"\n  must: [metric \"Attendees\" exactly; value \"610\" exactly; source \"ticketing export\" exactly]\n- audience 3: metric: \"Senior engineers or above\" | value: \"58%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n  must: [metric \"Senior engineers or above\" exactly; value \"58%\" exactly; source \"registration form\" exactly]\n- audience 4: metric: \"From companies of 200+ staff\" | value: \"41%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n  must: [metric \"From companies of 200+ staff\" exactly; value \"41%\" exactly; source \"registration form\" exactly]\n- audience 5: metric: \"Travelled from outside the region\" | value: \"22%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n  must: [metric \"Travelled from outside the region\" exactly; value \"22%\" exactly; source \"registration form\" exactly]\nEvidence rows left out of the story (no number, no source, no date, or history at a first edition): [none]\nValue equation (step 8, after drafting): result: \"passes\" | levers: [Dream Outcome: raised; Perceived Likelihood: raised; Time Delay: handled; Effort & Sacrifice: handled]\n  value must: [result \"passes\" exactly; note says why each lever holds]\nBuying influence (Q10): target: \"Nordlake Bank early-talent team, Gold tier\" | tier: \"another tier\" | diligence asks about it: no | deep attendee survey promoted: no | handling: no buying-influence question in the diligence: registration-form demographics carry the composition claims\nTo collect before the next edition - one per claim not yet evidenced, in this order - 0: none - an empty list\nStory - what you get, one row per claim the story can offer (a carried category and a proof), in this order - 3:\n- offer 1: category: \"Recruiting\" | claim: \"Staffed hiring-corner conversations with backend engineers\" | proof: \"Registration-form demographics\" | label: \"evidenced\"\n  must: [category \"Recruiting\" exactly; proof names \"Registration-form demographics\" and the word \"evidenced\"; benefit uses the word \"conversation\"]\n- offer 2: category: \"Brand exposure\" | claim: \"Logo on the stage screen and the event site\" | proof: \"Returning-sponsor rate\" | label: \"evidenced\"\n  must: [category \"Brand exposure\" exactly; proof names \"Returning-sponsor rate\" and the word \"evidenced\"]\n- offer 3: category: \"Brand exposure\" | claim: \"Employer-brand lift with senior engineers\" | proof: \"Registration-form demographics\" | label: \"evidenced\"\n  must: [category \"Brand exposure\" exactly; proof names \"Registration-form demographics\" and the word \"evidenced\"]\nDiscovery questions for the next call - the Q3 probes for this segment, in this order - 5:\n- probe 1: what this partner actually needs from the event, in its own words (Q3)\n  must: [one question ending \"?\" that uses the word \"need\"]\n- probe 2: the hiring it is doing now, or the employer brand it wants (Q3)\n  must: [one question ending \"?\" that uses the word \"hiring\"]\n- probe 3: what it does today without the event (Q6)\n  must: [one question ending \"?\" that uses the word \"today\"]\n- probe 4: its hiring pressure now - recruiting, holding or cutting (Q11)\n  must: [one question ending \"?\" that uses the word \"pressure\"]\n- probe 5: whether its own diligence checklist asks about buying influence or seniority mix (Q10)\n  must: [one question ending \"?\" that uses the word \"diligence\"]\nCase must: [summary at most 40 words; verdict \"ready for the prospectus\" exactly; caveats carry the fix findings first, at most 5]\nStory must: [opener names the segment's job (the word \"hiring\"); next_step asks for a call or a reply (the word \"call\")] | story note must: [use the word \"prospectus\" and say what happens next]\nHand-off: the statement and the proof-point inventory go to event-sponsor-prospectus (the deck) and event-sponsor-pricing (the rate card); packaging, tiers and prices are not done here.\nCarried from the case: summary: \"Ready for the prospectus: every claim is carried by an activity and proven, the honesty gate comes first, and recruiting is the co-lead the prospect named - hand the story to the prospectus.\" | parts matching the page: 3 of 3\nFindings (9):\n[info] pole_rules (pole): Q1: community-run - no attendee contact list is ever given or sold, no speaking slot is purchasable, lead capture happens only when an attendee volunteers it, aggregate demographics are the honest substitute for lead data and pipeline is deleted, not demoted. The honest mix is brand exposure, recruiting via real conversations, product feedback from a technical opinionated audience, and community goodwill.\n[info] segment_titles (segment): Q2: Recruiting buyer - title signals: Hiring / Recruiting / Talent Acquisition / HR titles.\n[info] notes (discovery): The pasted notes are context: a request in the notes is never a commitment.\n[info] ratio_guarantee (record): Program-content ratio: 32 technical sessions to 0 sponsor-delivered - at a community-run event the ratio is a structural guarantee; say so in the statement.\n[info] lead (lead): Lead: Brand exposure; co-lead: Recruiting - picked by the need found in discovery.\n[info] recruit_talk (lead): At a community-run event recruiting is conversation-based - office hours, a staffed table, engineers visibly present - never scanned data. Say so explicitly.\n[info] value_lens (value): The value equation is a post-draft scoring lens, never the structure to fill in: Dream Outcome and Perceived Likelihood raised, Time Delay and Effort & Sacrifice honestly handled. It sets no number.\n[info] handoff (scope): Hand the statement and the proof-point inventory to event-sponsor-prospectus (the deck) and event-sponsor-pricing (the rate card) - packaging, tiers and prices are not done here. Validate it with the organizer section by section, never as one block.\n[info] scope (scope): Sponsorship buys placement and access, never a talk slot, a judging result, or influence over the program or roadmap. The page never invents an audience number, a return or conversion rate, a sponsor quote, a sponsor name, a lead count or an outcome."
}

Reply:

{
 "task": "story",
 "headline": "Meet backend engineers who already know event-driven systems",
 "opener": "Your hiring team needs backend engineers with real distributed-systems exposure, and job boards bring volume, not fit. Kestrel DevConf 2027 puts your engineers in the same room as the people you are trying to hire.",
 "what_you_get": [
  {
   "category": "Recruiting",
   "benefit": "Staffed hiring-corner conversations with backend engineers: real conversations with engineers who choose to stop by - never a scanned list, and it lands on-site.",
   "proof": "Registration-form demographics - evidenced"
  },
  {
   "category": "Brand exposure",
   "benefit": "Logo on the stage screen and the event site: visibility that compounds over editions, with no staff needed at a booth.",
   "proof": "Returning-sponsor rate - evidenced"
  },
  {
   "category": "Brand exposure",
   "benefit": "Employer-brand lift with senior engineers: visibility that compounds over editions, with no staff needed at a booth.",
   "proof": "Registration-form demographics - evidenced"
  }
 ],
 "what_we_do_not_offer": [
  "No attendee contact lists, given or sold",
  "No speaking slots for sponsors",
  "No badge scanning"
 ],
 "audience": [
  {
   "metric": "Attendees",
   "value": "540",
   "source": "ticketing export"
  },
  {
   "metric": "Attendees",
   "value": "610",
   "source": "ticketing export"
  },
  {
   "metric": "Senior engineers or above",
   "value": "58%",
   "source": "registration form"
  },
  {
   "metric": "From companies of 200+ staff",
   "value": "41%",
   "source": "registration form"
  },
  {
   "metric": "Travelled from outside the region",
   "value": "22%",
   "source": "registration form"
  }
 ],
 "track_record": "2 editions run; 6 of 9 eligible sponsors returned (67%), and the last edition's post-event sponsor report is available.",
 "next_step": "Reply to book a call with the organizers about the hiring corner.",
 "discovery_questions": [
  "What do you need from this event, in your own words?",
  "Which roles are you hiring for this year, and what should your employer brand say to these engineers?",
  "What do you do today to reach these people without the event?",
  "How is your hiring pressure right now - recruiting, holding or cutting?",
  "Does your diligence checklist ask about buying influence or seniority mix?"
 ],
 "note": "Hand this copy and the proof-point inventory to the prospectus and pricing work next, and validate it with the organizers section by section."
}

The page's check: kept - nothing to flag

A practitioner sponsor, no claims drafted yet - case

Verdict: fix first; ready: no; pole: community-run; segment: Community-member sponsor; lead: Community goodwill; co-lead: Brand exposure; 0 claims, 3 gate items; value check: fails; 2 fix-level findings.

Input:

{
 "task": "case",
 "event": "Event: \"Kestrel DevConf 2027\" | dates: 2027-05-20 to 2027-05-21 | city: \"Kestrel Bay\" | planned attendance: 600 (the organizer's plan - not audience evidence) | format: \"a multi-day conference\" | as of: 2027-01-15\nQ1 pole: \"community-run\" | consented lead retrieval in place: no\nQ2 segment: \"Community-member sponsor\" | JTBD Who: \"The founder of a two-person observability consultancy inside the community\"\nQ3 the prospect's stated need, in its own words: \"We want to support the conference that taught us most of what we know, and stay close to where observability is going.\" | heard through: \"a call or short exchange with the prospect\"\nQ6 and JTBD What Before - what the segment does today without the event: \"Individual attendance without company visibility\"\nQ7 revenue must close by: 2027-03-31 (75 days from the as-of date) | Q8 relationship: \"a compounding multi-edition asset\" | Q9 evidence effort ceiling: \"data already held only\" | Q9 organizer hours: not set\nQ10 target sponsor or tier: \"Tracewell Consulting, Community tier\" | tier: \"another tier\" | its diligence asks about buying influence or seniority mix: no\nQ11 the segment's hiring pressure: \"not checked\"\nJTBD Why: \"Support infrastructure the team depends on and stay close to where the field is going\" | JTBD What After: \"Standing inside the community and early signal on ecosystem direction\" | JTBD Alternatives: \"OSS sponsorships and meetup hosting - often complements rather than substitutes\"\nThe sponsor's fully loaded cost (fee, booth build, travel, staff days): \"A small fee and a founder's day at the event\"",
 "evidence": "Audience evidence (Q4) - 5 rows, one per line:\n- row 1: metric: \"Attendees\" | value: \"540\" | source: \"ticketing export\" | edition or date: \"2025 edition\"\n- row 2: metric: \"Attendees\" | value: \"610\" | source: \"ticketing export\" | edition or date: \"2026 edition\"\n- row 3: metric: \"Senior engineers or above\" | value: \"58%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n- row 4: metric: \"From companies of 200+ staff\" | value: \"41%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n- row 5: metric: \"Travelled from outside the region\" | value: \"22%\" | source: \"registration form\" | edition or date: \"2026 edition\"\nTrack record (Q5): editions run: 2 | sponsors eligible to return: 9 | returned: 6 | post-event sponsor report held: yes | attributable sponsor testimonials on hand: 0\nProgram counts: technical sessions: 32 | sponsor-delivered sessions: 0\nFirst-edition substitutes: organizers' track record: \"none\" | community size and engagement: \"none\" | a named commitment to a post-event report: no",
 "program": "Program activities - 3, one per line:\n- activity 1: \"Hiring corner\" | serves: \"Recruiting\" | when: \"both days, at every break\"\n- activity 2: \"Sponsor loop on the stage screen\" | serves: \"Brand exposure\" | when: \"between talks\"\n- activity 3: \"Community dinner\" | serves: \"Community goodwill\" | when: \"day 1 evening\"\nHow claims: none drafted yet.\nThe honesty gate - what this event will not offer - 3, one per line:\n- will not offer 1: \"No attendee contact lists, given or sold\"\n- will not offer 2: \"No speaking slots for sponsors\"\n- will not offer 3: \"No badge scanning\"",
 "notes": "Short exchange at the March meetup with the Tracewell founder: small budget, no booth, wants to be seen backing the conference.",
 "facts": "Verdict: \"fix first\" | ready: no | fix-level findings: 2\nSelf-set lines: a revenue close date under 60 days from the as-of date is near | a summary cap of 40 words | at most 5 caveats. Never invented: an audience figure, a return or conversion rate, an ROI figure, a sponsor quote, a sponsor name, a lead count, an outcome.\nBoundary: sponsorship buys placement and access, never a talk slot, a judging result, or influence over the program or roadmap.\nPole (Q1): \"community-run\" | rules: [no attendee contact list is ever given or sold; no speaking slot is purchasable; lead capture happens only when an attendee volunteers it; aggregate demographics are the honest substitute for lead data; pipeline is deleted, not demoted] | categories that can honestly be offered: [\"Brand exposure\"; \"Product feedback\"; \"Recruiting\"; \"Community goodwill\"]\nSegment (Q2): \"Community-member sponsor\" | title signals: \"a practitioner, founder or team inside the community itself\" | segments the Who names: [\"Community-member sponsor\"]\n  segment must: [segment \"Community-member sponsor\" exactly]\nDiscovery (Q3): need: \"We want to support the conference that taught us most of what we know, and stay close to where observability is going.\" | heard through: \"a call or short exchange with the prospect\" | from the prospect: yes | maps to: \"Community goodwill\"\nThe honesty gate (step 3) - will not offer, in this order - 3:\n- gate 1: \"No attendee contact lists, given or sold\"\n- gate 2: \"No speaking slots for sponsors\"\n- gate 3: \"No badge scanning\"\n  gate must: [will_not_offer copies every gate item above, in this order, each exactly; what_we_do_not_offer copies every gate item above, in this order, each exactly]\nValue-category lead menu (step 4), re-ranked - pick: \"Community goodwill\"\n- rung 1: \"Community goodwill\" | moved: promoted by Q8: a compounding multi-edition mandate promotes the slow categories; made the pick by Q2: a community-member sponsor, drawn from the community's own membership - then community goodwill leads\n- rung 2: \"Brand exposure\" | moved: promoted by Q8: a compounding multi-edition mandate promotes the slow categories\n- rung 3: \"Product feedback\"\n- rung 4: \"Recruiting\"\n- deleted, not demoted: \"Pipeline\" | reason: Q1: a community-run event - delete pipeline, don't demote it: a demoted pipeline promise parked at the bottom of the menu reappears in the prospectus as scope\nLead: category: \"Community goodwill\" | co-lead: \"Brand exposure\" | co-lead from: \"menu\" | co-lead optional: no\n  lead must: [category \"Community goodwill\" exactly; co_lead \"Brand exposure\" exactly; reason uses the word \"menu\"]\nCoherence (step 5) - one row per claimed category, in this order - 0: none - an empty list\nJTBD (step 6), one segment - parts: [Who: complete; Why: complete; What Before: complete; How: missing; What After: complete; Alternatives: complete]\n  jtbd must: [who contains \"The founder of a two-person observability consultancy inside the community\"; why, before, after and alternatives each say the part above, or the words \"not stated yet\" when it is missing]\nHow claims (step 7) - one per claim, in this order - 0: none - an empty list\nProof-point instruments menu (step 7), re-ranked - pick: \"Returning-sponsor rate\"\n- rung 1: \"Returning-sponsor rate\"\n- rung 2: \"Registration-form demographics\"\n- rung 3: \"Program-content ratio\"\n- rung 4: \"Post-event sponsor report\"\n- rung 5: \"Sponsor testimonials\" | moved: demoted by Q9: the effort ceiling is data already held\n- rung 6: \"Deep attendee survey\" | moved: demoted by Q9: the effort ceiling is data already held\n- notes: Default rung: compute the returning-sponsor rate and the program-content ratio now, and change the registration form this edition to capture role, seniority and company size in aggregate - two or three required fields.\nTrack record (Q5): editions run: 2 | first edition: no | returning-sponsor rate: \"6 of 9 eligible returned (67%)\" | post-event sponsor report: yes | testimonials on hand: 0 | program-content ratio: \"32 technical to 0 sponsor-delivered\"\n  track record must: [track_record names the editions run, 2]\nAudience for the story - usable rows only, in this order - 5:\n- audience 1: metric: \"Attendees\" | value: \"540\" | source: \"ticketing export\" | edition or date: \"2025 edition\"\n  must: [metric \"Attendees\" exactly; value \"540\" exactly; source \"ticketing export\" exactly]\n- audience 2: metric: \"Attendees\" | value: \"610\" | source: \"ticketing export\" | edition or date: \"2026 edition\"\n  must: [metric \"Attendees\" exactly; value \"610\" exactly; source \"ticketing export\" exactly]\n- audience 3: metric: \"Senior engineers or above\" | value: \"58%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n  must: [metric \"Senior engineers or above\" exactly; value \"58%\" exactly; source \"registration form\" exactly]\n- audience 4: metric: \"From companies of 200+ staff\" | value: \"41%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n  must: [metric \"From companies of 200+ staff\" exactly; value \"41%\" exactly; source \"registration form\" exactly]\n- audience 5: metric: \"Travelled from outside the region\" | value: \"22%\" | source: \"registration form\" | edition or date: \"2026 edition\"\n  must: [metric \"Travelled from outside the region\" exactly; value \"22%\" exactly; source \"registration form\" exactly]\nEvidence rows left out of the story (no number, no source, no date, or history at a first edition): [none]\nValue equation (step 8, after drafting): result: \"fails\" | levers: [Dream Outcome: raised; Perceived Likelihood: not raised; Time Delay: not handled; Effort & Sacrifice: handled]\n  value must: [result \"fails\" exactly; note names every lever not raised or handled: \"Perceived Likelihood\" and \"Time Delay\"]\nBuying influence (Q10): target: \"Tracewell Consulting, Community tier\" | tier: \"another tier\" | diligence asks about it: no | deep attendee survey promoted: no | handling: no buying-influence question in the diligence: registration-form demographics carry the composition claims\nTo collect before the next edition - one per claim not yet evidenced, in this order - 0: none - an empty list\nStory - what you get, one row per claim the story can offer (a carried category and a proof), in this order - 0: none - an empty list\nDiscovery questions for the next call - the Q3 probes for this segment, in this order - 4:\n- probe 1: what this partner actually needs from the event, in its own words (Q3)\n  must: [one question ending \"?\" that uses the word \"need\"]\n- probe 2: its standing in the community, and what it depends on there (Q3)\n  must: [one question ending \"?\" that uses the word \"community\"]\n- probe 3: what it does today without the event (Q6)\n  must: [one question ending \"?\" that uses the word \"today\"]\n- probe 4: whether its own diligence checklist asks about buying influence or seniority mix (Q10)\n  must: [one question ending \"?\" that uses the word \"diligence\"]\nCase must: [summary at most 40 words; verdict \"fix first\" exactly; caveats carry the fix findings first, at most 5]\nStory must: [opener names the segment's job (the word \"community\"); next_step asks for a call or a reply (the word \"call\")] | story note must: [begin \"Not ready for the prospectus:\" and say what to fix first]\nHand-off: the statement and the proof-point inventory go to event-sponsor-prospectus (the deck) and event-sponsor-pricing (the rate card); packaging, tiers and prices are not done here.\nFindings (10):\n[fix] how_none (jtbd): JTBD How: no claim yet - write what the event genuinely delivers against the job, bounded by the pole, with a proof point under each.\n[fix] value_fails (value): The value-equation check fails on Perceived Likelihood (no How claim to carry a proof point) and Time Delay (nothing to time yet) - a draft that only lists benefits fails, whatever its length.\n[info] pole_rules (pole): Q1: community-run - no attendee contact list is ever given or sold, no speaking slot is purchasable, lead capture happens only when an attendee volunteers it, aggregate demographics are the honest substitute for lead data and pipeline is deleted, not demoted. The honest mix is brand exposure, recruiting via real conversations, product feedback from a technical opinionated audience, and community goodwill.\n[info] segment_titles (segment): Q2: Community-member sponsor - title signals: a practitioner, founder or team inside the community itself.\n[info] notes (discovery): The pasted notes are context: a request in the notes is never a commitment.\n[info] ratio_guarantee (record): Program-content ratio: 32 technical sessions to 0 sponsor-delivered - at a community-run event the ratio is a structural guarantee; say so in the statement.\n[info] lead (lead): Lead: Community goodwill; co-lead: Brand exposure - the next live rung, since discovery's category is already the lead.\n[info] value_lens (value): The value equation is a post-draft scoring lens, never the structure to fill in: Dream Outcome and Perceived Likelihood raised, Time Delay and Effort & Sacrifice honestly handled. It sets no number.\n[info] handoff (scope): Hand the statement and the proof-point inventory to event-sponsor-prospectus (the deck) and event-sponsor-pricing (the rate card) - packaging, tiers and prices are not done here. Validate it with the organizer section by section, never as one block.\n[info] scope (scope): Sponsorship buys placement and access, never a talk slot, a judging result, or influence over the program or roadmap. The page never invents an audience number, a return or conversion rate, a sponsor quote, a sponsor name, a lead count or an outcome."
}

Reply:

{
 "task": "case",
 "summary": "Fix first: the statement has no How claim yet, so nothing can be proven or offered - draft the claims with a proof point under each, then write the story.",
 "verdict": "fix first",
 "segment": "Community-member sponsor",
 "will_not_offer": [
  "No attendee contact lists, given or sold",
  "No speaking slots for sponsors",
  "No badge scanning"
 ],
 "lead": {
  "category": "Community goodwill",
  "co_lead": "Brand exposure",
  "reason": "The category discovery found is already the lead, so the co-lead is the next live rung on the menu."
 },
 "coherence": [],
 "jtbd": {
  "who": "The founder of a two-person observability consultancy inside the community",
  "why": "Support infrastructure the team depends on and stay close to where the field is going.",
  "before": "Individual attendance without company visibility.",
  "how": [],
  "after": "Standing inside the community and early signal on ecosystem direction.",
  "alternatives": "OSS sponsorships and meetup hosting - often complements rather than substitutes."
 },
 "value_check": {
  "result": "fails",
  "note": "Fails on Perceived Likelihood (no How claim to carry a proof point) and Time Delay (nothing to time yet)."
 },
 "gaps": [],
 "caveats": [
  "JTBD How: no claim yet - write what the event genuinely delivers against the job, bounded by the pole, with a proof point under each.",
  "The value-equation check fails on Perceived Likelihood (no How claim to carry a proof point) and Time Delay (nothing to time yet) - a draft that only lists benefits fails, whatever its length."
 ]
}

The page's check: kept - nothing to flag

A first edition, product-feedback buyer, no honesty gate yet - story

Verdict: write the honesty gate first; ready: no; pole: community-run; segment: Product-feedback buyer; lead: Product feedback; co-lead: Brand exposure; 3 claims, 0 gate items; value check: passes; a first edition; 1 fix-level findings.

Input:

{
 "task": "story",
 "event": "Event: \"Fjord API Days 2027\" | dates: 2027-06-10 | city: \"Fjordholm\" | planned attendance: 250 (the organizer's plan - not audience evidence) | format: \"a one-day conference\" | as of: 2027-03-20\nQ1 pole: \"community-run\" | consented lead retrieval in place: no\nQ2 segment: \"Product-feedback buyer\" | JTBD Who: \"Developer advocates at API and SDK vendors\"\nQ3 the prospect's stated need, in its own words: \"We want real reactions to our new SDK from developers who have not used it yet.\" | heard through: \"a call or short exchange with the prospect\"\nQ6 and JTBD What Before - what the segment does today without the event: \"Feature surveys and a beta program with low-engagement participants\"\nQ7 revenue must close by: 2027-04-30 (41 days from the as-of date) | Q8 relationship: \"a one-off sale\" | Q9 evidence effort ceiling: \"organizer hours available\" | Q9 organizer hours: 30\nQ10 target sponsor or tier: \"Brightline SDK team, Supporter tier\" | tier: \"another tier\" | its diligence asks about buying influence or seniority mix: no\nQ11 the segment's hiring pressure: \"not checked\"\nJTBD Why: \"Validate the new SDK with developers outside the existing user base\" | JTBD What After: \"A validated or invalidated SDK decision, named beta users and direct quotes for the roadmap discussion\" | JTBD Alternatives: \"A bigger vendor conference gives broader, shallower contact, and their own user conference reaches existing users only\"\nThe sponsor's fully loaded cost (fee, booth build, travel, staff days): \"The fee plus two developer advocates staffing the feedback lab for a day\"",
 "evidence": "Audience evidence (Q4) - 3 rows, one per line:\n- row 1: metric: \"Meetup members\" | value: \"1,400\" | source: \"meetup group page\" | edition or date: \"2027-03\"\n- row 2: metric: \"Average meetup attendance\" | value: \"85\" | source: \"meetup sign-in sheets\" | edition or date: \"2026 meetups\"\n- row 3: metric: \"CFP submissions so far\" | value: \"120\" | source: \"CFP tool export\" | edition or date: \"2027-03-15\"\nTrack record (Q5): editions run: 0 | sponsors eligible to return: not set | returned: not set | post-event sponsor report held: no | attributable sponsor testimonials on hand: not set\nProgram counts: technical sessions: 24 | sponsor-delivered sessions: 0\nFirst-edition substitutes: organizers' track record: \"The three organizers have run the Fjord API meetup for four years and co-organized two regional conferences\" | community size and engagement: \"none\" | a named commitment to a post-event report: yes",
 "program": "Program activities - 3, one per line:\n- activity 1: \"API feedback lab\" | serves: \"Product feedback\" | when: \"day 1, 14:00-16:00\"\n- activity 2: \"SDK office-hours table\" | serves: \"Product feedback\" | when: \"both breaks\"\n- activity 3: \"Sponsor loop on the stage screen\" | serves: \"Brand exposure\" | when: \"between talks\"\nHow claims - 3, one per line:\n- claim 1: \"Hands-on feedback lab with developers new to your SDK\" | category: \"Product feedback\" | proof instrument: \"Community size and engagement\" | label: \"evidenced\"\n- claim 2: \"Office hours where attendees bring real use cases\" | category: \"Product feedback\" | proof instrument: \"Organizers' track record\" | label: \"aspirational\"\n- claim 3: \"Logo on the stage screen and the event site\" | category: \"Brand exposure\" | proof instrument: \"Named commitment\" | label: \"aspirational\"\nThe honesty gate: nothing written yet.",
 "notes": "Call with the Brightline SDK team, 2027-03-12: they want unfiltered reactions from developers who have never tried the SDK, not their existing fans.",
 "facts": "Verdict: \"write the honesty gate first\" | ready: no | fix-level findings: 1\nSelf-set lines: a revenue close date under 60 days from the as-of date is near | a summary cap of 40 words | at most 5 caveats. Never invented: an audience figure, a return or conversion rate, an ROI figure, a sponsor quote, a sponsor name, a lead count, an outcome.\nBoundary: sponsorship buys placement and access, never a talk slot, a judging result, or influence over the program or roadmap.\nPole (Q1): \"community-run\" | rules: [no attendee contact list is ever given or sold; no speaking slot is purchasable; lead capture happens only when an attendee volunteers it; aggregate demographics are the honest substitute for lead data; pipeline is deleted, not demoted] | categories that can honestly be offered: [\"Brand exposure\"; \"Product feedback\"; \"Recruiting\"; \"Community goodwill\"]\nSegment (Q2): \"Product-feedback buyer\" | title signals: \"Developer Relations / Developer Advocate titles\" | segments the Who names: [\"Product-feedback buyer\"]\n  segment must: [segment \"Product-feedback buyer\" exactly]\nDiscovery (Q3): need: \"We want real reactions to our new SDK from developers who have not used it yet.\" | heard through: \"a call or short exchange with the prospect\" | from the prospect: yes | maps to: \"Product feedback\"\nThe honesty gate (step 3) - will not offer, in this order - 0: none - an empty list\n  gate must: [will_not_offer is an empty list; what_we_do_not_offer is an empty list]\nValue-category lead menu (step 4), re-ranked - pick: \"Product feedback\"\n- rung 1: \"Product feedback\" | moved: promoted by Q7: revenue closes in 41 days - under the 60-day line (self-set), so categories that pay off on-site rise\n- rung 2: \"Brand exposure\"\n- rung 3: \"Recruiting\" | moved: promoted by Q7: revenue closes in 41 days - under the 60-day line (self-set), so categories that pay off on-site rise\n- rung 4: \"Community goodwill\"\n- deleted, not demoted: \"Pipeline\" | reason: Q1: a community-run event - delete pipeline, don't demote it: a demoted pipeline promise parked at the bottom of the menu reappears in the prospectus as scope\nLead: category: \"Product feedback\" | co-lead: \"Brand exposure\" | co-lead from: \"menu\" | co-lead optional: no\n  lead must: [category \"Product feedback\" exactly; co_lead \"Brand exposure\" exactly; reason uses the word \"menu\"]\nCoherence (step 5) - one row per claimed category, in this order - 2:\n- row 1: \"Product feedback\" | activity: \"API feedback lab\" | status: \"carried\"\n  must: [category \"Product feedback\" exactly; activity \"API feedback lab\" exactly; status \"carried\" exactly]\n- row 2: \"Brand exposure\" | activity: \"Sponsor loop on the stage screen\" | status: \"carried\"\n  must: [category \"Brand exposure\" exactly; activity \"Sponsor loop on the stage screen\" exactly; status \"carried\" exactly]\nJTBD (step 6), one segment - parts: [Who: complete; Why: complete; What Before: complete; How: complete; What After: complete; Alternatives: complete]\n  jtbd must: [who contains \"Developer advocates at API and SDK vendors\"; why, before, after and alternatives each say the part above, or the words \"not stated yet\" when it is missing]\nHow claims (step 7) - one per claim, in this order - 3:\n- claim 1: \"Hands-on feedback lab with developers new to your SDK\" | category: \"Product feedback\" | proof: \"Community size and engagement\" | label: \"evidenced\" | evidence on hand: yes | payoff: \"lands on-site\" | in the story: yes\n  must: [claim \"Hands-on feedback lab with developers new to your SDK\" exactly; proof names \"Community size and engagement\" and the word \"evidenced\"]\n- claim 2: \"Office hours where attendees bring real use cases\" | category: \"Product feedback\" | proof: \"Organizers' track record\" | label: \"aspirational\" | evidence on hand: yes | payoff: \"lands on-site\" | in the story: yes\n  must: [claim \"Office hours where attendees bring real use cases\" exactly; proof names \"Organizers' track record\" and the word \"aspirational\"]\n- claim 3: \"Logo on the stage screen and the event site\" | category: \"Brand exposure\" | proof: \"Named commitment\" | label: \"aspirational\" | evidence on hand: yes | payoff: \"compounds over editions\" | in the story: yes\n  must: [claim \"Logo on the stage screen and the event site\" exactly; proof names \"Named commitment\" and the word \"aspirational\"]\nProof-point instruments menu (step 7), re-ranked - pick: \"Registration-form demographics\"\n- rung 1: \"Registration-form demographics\"\n- rung 2: \"Program-content ratio\"\n- rung 3: \"Sponsor testimonials\"\n- rung 4: \"Deep attendee survey\"\n- deleted, not demoted: \"Returning-sponsor rate\" | reason: Q5: a first edition has no returning-sponsor rate\n- deleted, not demoted: \"Post-event sponsor report\" | reason: Q5: a first edition has no report yet - commit to one instead, a checkable promise\n- notes: First-edition substitutes, flagged as such: Organizers' track record, Community size and engagement and Named commitment. Default rung: compute the returning-sponsor rate and the program-content ratio now, and change the registration form this edition to capture role, seniority and company size in aggregate - two or three required fields.\nTrack record (Q5): editions run: 0 | first edition: yes | returning-sponsor rate: \"not counted\" | post-event sponsor report: no | testimonials on hand: not set | program-content ratio: \"24 technical to 0 sponsor-delivered\"\n  track record must: [track_record uses the words \"first edition\"; track_record names a substitute: the organizers' track record, the community numbers or the named commitment]\nAudience for the story - usable rows only, in this order - 3:\n- audience 1: metric: \"Meetup members\" | value: \"1,400\" | source: \"meetup group page\" | edition or date: \"2027-03\" | first-edition evidence: yes\n  must: [metric \"Meetup members\" exactly; value \"1,400\" exactly; source \"meetup group page\" exactly]\n- audience 2: metric: \"Average meetup attendance\" | value: \"85\" | source: \"meetup sign-in sheets\" | edition or date: \"2026 meetups\" | first-edition evidence: yes\n  must: [metric \"Average meetup attendance\" exactly; value \"85\" exactly; source \"meetup sign-in sheets\" exactly]\n- audience 3: metric: \"CFP submissions so far\" | value: \"120\" | source: \"CFP tool export\" | edition or date: \"2027-03-15\" | first-edition evidence: yes\n  must: [metric \"CFP submissions so far\" exactly; value \"120\" exactly; source \"CFP tool export\" exactly]\nEvidence rows left out of the story (no number, no source, no date, or history at a first edition): [none]\nValue equation (step 8, after drafting): result: \"passes\" | levers: [Dream Outcome: raised; Perceived Likelihood: raised; Time Delay: handled; Effort & Sacrifice: handled]\n  value must: [result \"passes\" exactly; note says why each lever holds]\nBuying influence (Q10): target: \"Brightline SDK team, Supporter tier\" | tier: \"another tier\" | diligence asks about it: no | deep attendee survey promoted: no | handling: no buying-influence question in the diligence: registration-form demographics carry the composition claims\nTo collect before the next edition - one per claim not yet evidenced, in this order - 2:\n- gap 1: instrument: \"Organizers' track record\" | for claim: \"Office hours where attendees bring real use cases\"\n  must: [names \"Organizers' track record\"]\n- gap 2: instrument: \"Named commitment\" | for claim: \"Logo on the stage screen and the event site\"\n  must: [names \"Named commitment\"]\nStory - what you get, one row per claim the story can offer (a carried category and a proof), in this order - 3:\n- offer 1: category: \"Product feedback\" | claim: \"Hands-on feedback lab with developers new to your SDK\" | proof: \"Community size and engagement\" | label: \"evidenced\"\n  must: [category \"Product feedback\" exactly; proof names \"Community size and engagement\" and the word \"evidenced\"]\n- offer 2: category: \"Product feedback\" | claim: \"Office hours where attendees bring real use cases\" | proof: \"Organizers' track record\" | label: \"aspirational\"\n  must: [category \"Product feedback\" exactly; proof names \"Organizers' track record\" and the word \"aspirational\"]\n- offer 3: category: \"Brand exposure\" | claim: \"Logo on the stage screen and the event site\" | proof: \"Named commitment\" | label: \"aspirational\"\n  must: [category \"Brand exposure\" exactly; proof names \"Named commitment\" and the word \"aspirational\"]\nDiscovery questions for the next call - the Q3 probes for this segment, in this order - 4:\n- probe 1: what this partner actually needs from the event, in its own words (Q3)\n  must: [one question ending \"?\" that uses the word \"need\"]\n- probe 2: the product feedback it wants - on which product, from whom, routed to Product or Engineering (Q3)\n  must: [one question ending \"?\" that uses the word \"feedback\"]\n- probe 3: what it does today without the event (Q6)\n  must: [one question ending \"?\" that uses the word \"today\"]\n- probe 4: whether its own diligence checklist asks about buying influence or seniority mix (Q10)\n  must: [one question ending \"?\" that uses the word \"diligence\"]\nCase must: [summary at most 40 words; verdict \"write the honesty gate first\" exactly; caveats carry the fix findings first, at most 5]\nStory must: [opener names the segment's job (the word \"feedback\"); next_step asks for a call or a reply (the word \"call\")] | story note must: [begin \"Not ready for the prospectus:\" and say what to fix first]\nHand-off: the statement and the proof-point inventory go to event-sponsor-prospectus (the deck) and event-sponsor-pricing (the rate card); packaging, tiers and prices are not done here.\nCarried from the case: summary: \"Write the honesty gate first: three claims are drafted with no will-not-offer list - write what the event will not offer, then flag the first-edition evidence in the story.\" | parts matching the page: 3 of 3\nFindings (10):\n[fix] gate_none (gate): Honesty gate first: write down what this event will not offer before drafting what it will - 3 claims are drafted with no will-not-offer list. The published pattern tells sponsors no attendee lists and no purchased slots before describing any package.\n[info] pole_rules (pole): Q1: community-run - no attendee contact list is ever given or sold, no speaking slot is purchasable, lead capture happens only when an attendee volunteers it, aggregate demographics are the honest substitute for lead data and pipeline is deleted, not demoted. The honest mix is brand exposure, recruiting via real conversations, product feedback from a technical opinionated audience, and community goodwill.\n[info] segment_titles (segment): Q2: Product-feedback buyer - title signals: Developer Relations / Developer Advocate titles.\n[info] notes (discovery): The pasted notes are context: a request in the notes is never a commitment.\n[info] first_edition (record): Q5: a first edition - no returning-sponsor rate, no post-event report, no prior demographics. Flag it as first-edition evidence in the statement itself and use the substitutes: the organizers' own track record, community size and engagement, and a named commitment to a post-event report. Never a projection presented as history.\n[info] ratio_guarantee (record): Program-content ratio: 24 technical sessions to 0 sponsor-delivered - at a community-run event the ratio is a structural guarantee; say so in the statement.\n[info] lead (lead): Lead: Product feedback; co-lead: Brand exposure - the next live rung, since discovery's category is already the lead.\n[info] value_lens (value): The value equation is a post-draft scoring lens, never the structure to fill in: Dream Outcome and Perceived Likelihood raised, Time Delay and Effort & Sacrifice honestly handled. It sets no number.\n[info] handoff (scope): Hand the statement and the proof-point inventory to event-sponsor-prospectus (the deck) and event-sponsor-pricing (the rate card) - packaging, tiers and prices are not done here. Validate it with the organizer section by section, never as one block.\n[info] scope (scope): Sponsorship buys placement and access, never a talk slot, a judging result, or influence over the program or roadmap. The page never invents an audience number, a return or conversion rate, a sponsor quote, a sponsor name, a lead count or an outcome."
}

Reply:

{
 "task": "story",
 "headline": "Hear what developers new to your SDK really think",
 "opener": "Your developer relations team wants unfiltered feedback on a new SDK from developers who have never used it. Fjord API Days 2027 gives you a hands-on lab and office hours with exactly that audience.",
 "what_you_get": [
  {
   "category": "Product feedback",
   "benefit": "Hands-on feedback lab with developers new to your SDK: reactions you can route to Product and Engineering, gathered on-site.",
   "proof": "Community size and engagement - evidenced"
  },
  {
   "category": "Product feedback",
   "benefit": "Office hours where attendees bring real use cases: reactions you can route to Product and Engineering, gathered on-site.",
   "proof": "Organizers' track record - aspirational"
  },
  {
   "category": "Brand exposure",
   "benefit": "Logo on the stage screen and the event site: visibility that compounds over editions, with no staff needed at a booth.",
   "proof": "Named commitment - aspirational"
  }
 ],
 "what_we_do_not_offer": [],
 "audience": [
  {
   "metric": "Meetup members",
   "value": "1,400",
   "source": "meetup group page"
  },
  {
   "metric": "Average meetup attendance",
   "value": "85",
   "source": "meetup sign-in sheets"
  },
  {
   "metric": "CFP submissions so far",
   "value": "120",
   "source": "CFP tool export"
  }
 ],
 "track_record": "This is a first edition, so there is no returning-sponsor rate or prior report yet: the organizers' track record and the community numbers stand in, and a post-event report is a named commitment.",
 "next_step": "Reply to book a call about the feedback lab.",
 "discovery_questions": [
  "What do you need from this event, in your own words?",
  "Which product do you want feedback on, and from which developers?",
  "What do you do today to reach these people without the event?",
  "Does your diligence checklist ask about buying influence or seniority mix?"
 ],
 "note": "Not ready for the prospectus: write the honesty gate - what this event will not offer - before any of these claims go out."
}

The page's check: kept - nothing to flag

The free six-part statement for the cleaned sample

# Kestrel DevConf 2027 - value proposition for one segment (draft from the page)

_Verdict: ready for the prospectus. Segment: Recruiting buyer. Pole: community-run._

## What this event will not offer

- No attendee contact lists, given or sold
- No speaking slots for sponsors
- No badge scanning

## Who

Talent-acquisition leads hiring backend engineers

## Why

Fill backend roles with candidates who have real distributed-systems exposure

## What Before

Job-board ads, agency fees and cold LinkedIn outreach with low response

## How - every claim with its proof point

- Staffed hiring-corner conversations with backend engineers (Recruiting) - proof: Registration-form demographics, evidenced
- Logo on the stage screen and the event site (Brand exposure) - proof: Returning-sponsor rate, evidenced
- Employer-brand lift with senior engineers (Brand exposure) - proof: Registration-form demographics, evidenced

## What After

A warm, self-selected shortlist of candidates who already met the team

## Alternatives

Career fairs give volume without self-selection, and job-board placement gives no conversation

## Lead

Lead: Brand exposure. Co-lead: Recruiting (from discovery).

## Value-equation check (after drafting)

Result: passes.

- Dream Outcome: raised - the After names the segment's job done
- Perceived Likelihood: raised - every How claim carries a labelled proof point
- Time Delay: handled - each claim's payoff is placed: on-site or over editions
- Effort & Sacrifice: handled - the sponsor's fully loaded cost is named

Made with Sponsor Why - https://sponsor-why.skillsafe.ai/

Build the input yourself

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

const K = WhyKit, R = WhyReply;
const f = K.form({ name: "My Conf 2027", pole: "community", segment: "feedback", who: "Developer advocates at API vendors",
  need: "Real reactions to our SDK", needSource: "call", gate: "No attendee contact lists\nNo speaking slots for sponsors",
  program: "Feedback lab | product feedback | day 1", claims: "Hands-on feedback lab | product feedback | registration-form demographics | aspirational" });
// f.rules, f.gate, f.lead / f.leadKey / f.coLead, f.coherence, f.jtbd, f.claims, f.proof, f.usable, f.value, f.toCollect, f.verdict, f.findings
K.jtbdMd(f); K.proofCsv(f); K.coherenceCsv(f); K.board(f)   // the free exports
const b = K.buildInput(f, "case");                           // or "story"
const wire = K.toWire(b.input);                              // POST this to /estimate and /run
// then: const reply = R.normalize(R.parseReply(job.output.output), "case");
// R.check(reply, b)                                         // {status: kept or flagged, notes}
// R.carryText(reply)                                        // the lines the story lane carries - set them as the carry field

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="YOUR_TOKEN"   # from https://sponsor-why.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"}
}

import json, urllib.request

BASE = "https://api.skillsafe.ai/v1/app-api"
TOKEN = "YOUR_TOKEN"  # from https://sponsor-why.skillsafe.ai/tokens.html

def api(method, path, body=None, headers=None):
    req = urllib.request.Request(BASE + path, method=method,
        data=None if body is None else json.dumps(body).encode(),
        headers={"Content-Type": "application/json", **({"Authorization": "Bearer " + TOKEN} if TOKEN else {}), **(headers or {})})
    with urllib.request.urlopen(req) as r:
        env = json.load(r)
    if env.get("error"):
        raise RuntimeError(env["error"])
    return env["data"]

// sponsor-why.mjs -- Node 18+ (global fetch)
const BASE = "https://api.skillsafe.ai/v1/app-api";
let TOKEN = "YOUR_TOKEN"; // from https://sponsor-why.skillsafe.ai/tokens.html
async function api(method, path, body, headers = {}) {
  const r = await fetch(BASE + path, { method, headers: { "Content-Type": "application/json",
    ...(TOKEN ? { Authorization: "Bearer " + TOKEN } : {}), ...headers },
    body: body === undefined ? undefined : JSON.stringify(body) });
  const env = await r.json();
  if (env.error) throw new Error(env.error.code + ": " + env.error.message);
  return env.data;
}

package main

import ("bytes"; "encoding/json"; "fmt"; "net/http")

const base = "https://api.skillsafe.ai/v1/app-api"
var token = "YOUR_TOKEN" // from https://sponsor-why.skillsafe.ai/tokens.html

func api(method, path string, body any, headers map[string]string) (map[string]any, error) {
	var buf bytes.Buffer
	if body != nil { json.NewEncoder(&buf).Encode(body) }
	req, _ := http.NewRequest(method, base+path, &buf)
	req.Header.Set("Content-Type", "application/json")
	if token != "" { req.Header.Set("Authorization", "Bearer "+token) }
	for k, v := range headers { req.Header.Set(k, v) }
	res, err := http.DefaultClient.Do(req)
	if err != nil { return nil, err }
	defer res.Body.Close()
	var env struct { Data map[string]any; Error map[string]any }
	json.NewDecoder(res.Body).Decode(&env)
	if env.Error != nil { return nil, fmt.Errorf("%v", env.Error) }
	return env.Data, nil
}

// SponsorWhy.java -- Java 17+, with com.fasterxml.jackson.core:jackson-databind
import com.fasterxml.jackson.databind.*;
import java.net.URI; import java.net.http.*; import java.util.*;

public class SponsorWhy {
  static final String BASE = "https://api.skillsafe.ai/v1/app-api";
  static String token = "YOUR_TOKEN"; // from https://sponsor-why.skillsafe.ai/tokens.html
  static final ObjectMapper M = new ObjectMapper();
  static final HttpClient C = HttpClient.newHttpClient();
  static JsonNode api(String method, String path, Object body, Map<String, String> headers) throws Exception {
    var b = HttpRequest.newBuilder(URI.create(BASE + path)).header("Content-Type", "application/json");
    if (!token.isEmpty()) b.header("Authorization", "Bearer " + token);
    if (headers != null) headers.forEach(b::header);
    b.method(method, body == null ? HttpRequest.BodyPublishers.noBody() : HttpRequest.BodyPublishers.ofString(M.writeValueAsString(body)));
    JsonNode env = M.readTree(C.send(b.build(), HttpResponse.BodyHandlers.ofString()).body());
    if (env.hasNonNull("error")) throw new RuntimeException(env.get("error").toString());
    return env.get("data");
  }
}

require "json"
require "net/http"

BASE = "https://api.skillsafe.ai/v1/app-api"
TOKEN = "YOUR_TOKEN" # from https://sponsor-why.skillsafe.ai/tokens.html

def api(method, path, body = nil, headers = {})
  uri = URI(BASE + path)
  req = Net::HTTPGenericRequest.new(method, !body.nil?, true, uri.request_uri,
    { "Content-Type" => "application/json" }.merge(TOKEN.empty? ? {} : { "Authorization" => "Bearer #{TOKEN}" }).merge(headers))
  req.body = JSON.generate(body) unless body.nil?
  env = JSON.parse(Net::HTTP.start(uri.host, uri.port, use_ssl: true) { |h| h.request(req) }.body)
  raise env["error"].to_s if env["error"]
  env["data"]
end

<?php
const BASE = "https://api.skillsafe.ai/v1/app-api";
$TOKEN = "YOUR_TOKEN"; // from https://sponsor-why.skillsafe.ai/tokens.html

function api(string $method, string $path, $body = null, array $headers = []) {
    global $TOKEN;
    $h = ["Content-Type: application/json"];
    if ($TOKEN) $h[] = "Authorization: Bearer $TOKEN";
    foreach ($headers as $k => $v) $h[] = "$k: $v";
    $ch = curl_init(BASE . $path);
    curl_setopt_array($ch, [CURLOPT_CUSTOMREQUEST => $method, CURLOPT_HTTPHEADER => $h, CURLOPT_RETURNTRANSFER => true]);
    if ($body !== null) curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($body));
    $env = json_decode(curl_exec($ch), true);
    if (!empty($env["error"])) throw new Exception(json_encode($env["error"]));
    return $env["data"];
}

// Program.cs -- .NET 6+ console app
using System.Net.Http.Json; using System.Text.Json; using System.Text.Json.Nodes;

static class Api {
  public const string Base = "https://api.skillsafe.ai/v1/app-api";
  public static string Token = "YOUR_TOKEN"; // from https://sponsor-why.skillsafe.ai/tokens.html
  static readonly HttpClient C = new();
  public static async Task<JsonNode?> Call(string method, string path, object? body = null, Dictionary<string, string>? headers = null) {
    var req = new HttpRequestMessage(new HttpMethod(method), Base + path);
    if (Token != "") req.Headers.Add("Authorization", "Bearer " + Token);
    if (headers != null) foreach (var h in headers) req.Headers.Add(h.Key, h.Value);
    if (body != null) req.Content = JsonContent.Create(body);
    var env = JsonNode.Parse(await (await C.SendAsync(req)).Content.ReadAsStringAsync())!;
    if (env["error"] is JsonNode e && e.GetValueKind() != JsonValueKind.Null) throw new Exception(e.ToJsonString());
    return env["data"];
  }
}

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":"sponsor-why"}' | jq -r '.data.token')

# a guest token (enough for /me and /estimate); a run needs your personal token from /tokens.html
TOKEN = ""
TOKEN = api("POST", "/guest", {"slug": "sponsor-why"})["token"]

// a guest token (enough for /me and /estimate); a run needs your personal token from /tokens.html
TOKEN = "";
TOKEN = (await api("POST", "/guest", { slug: "sponsor-why" })).token;

// inside main: a guest token (enough for /me and /estimate); a run needs your personal token
token = ""
g, err := api("POST", "/guest", map[string]string{"slug": "sponsor-why"}, nil)
if err != nil { panic(err) }
token = g["token"].(string)

// inside main: a guest token (enough for /me and /estimate); a run needs your personal token
token = "";
token = api("POST", "/guest", Map.of("slug", "sponsor-why"), null).get("token").asText();

# a guest token (enough for /me and /estimate); a run needs your personal token from /tokens.html
TOKEN.replace("")
TOKEN.replace(api("POST", "/guest", { slug: "sponsor-why" })["token"])

// a guest token (enough for /me and /estimate); a run needs your personal token from /tokens.html
$TOKEN = "";
$TOKEN = api("POST", "/guest", ["slug" => "sponsor-why"])["token"];

// a guest token (enough for /me and /estimate); a run needs your personal token from /tokens.html
Api.Token = "";
Api.Token = (await Api.Call("POST", "/guest", new { slug = "sponsor-why" }))!["token"]!.GetValue<string>();

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}'

me = api("GET", "/me")
print(me["subject_type"], me.get("credits"))

const me = await api("GET", "/me");
console.log(me.subject_type, me.credits);

me, _ := api("GET", "/me", nil, nil)
fmt.Println(me["subject_type"], me["credits"])

JsonNode me = api("GET", "/me", null, null);
System.out.println(me.get("subject_type") + " " + me.get("credits"));

me = api("GET", "/me")
puts [me["subject_type"], me["credits"]].inspect

$me = api("GET", "/me");
echo $me["subject_type"], " ", $me["credits"] ?? "", "\n";

var me = await Api.Call("GET", "/me");
Console.WriteLine($"{me!["subject_type"]} {me["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": "case", "event": "Event: ... | dates: ... | as of: ...", "evidence": "Audience evidence (Q4) - 5 rows ...", "program": "Program activities - 3 ...", "notes": "", "facts": "Verdict: ..."}
# - see the input table
api POST /estimate "$(cat input.json)" | jq '.data | {hold_credits, min_credits, model, model_alias, markup_bps, warnings}'

inp = json.load(open("input.json"))   # {"task": "case", "event": "Event: ... | dates: ... | as of: ...", "evidence": "Audience evidence (Q4) - 5 rows ...", "program": "Program activities - 3 ...", "notes": "", "facts": "Verdict: ..."}
# - see the input table
est = api("POST", "/estimate", inp)
print(est["hold_credits"], est["min_credits"], est["model"], est.get("warnings"))

import { readFileSync } from "node:fs";
const input = JSON.parse(readFileSync("input.json", "utf8")); // {task: "case" or "story", event, evidence, program, notes, facts} (see the input table)
const est = await api("POST", "/estimate", input);
console.log(est.hold_credits, est.min_credits, est.model, est.warnings);

raw, _ := os.ReadFile("input.json") // add "os" to the imports
var input map[string]any
json.Unmarshal(raw, &input)
est, _ := api("POST", "/estimate", input, nil)
fmt.Println(est["hold_credits"], est["min_credits"], est["model"])

Map<String, Object> input = M.readValue(new java.io.File("input.json"), Map.class);
JsonNode est = api("POST", "/estimate", input, null);
System.out.println(est.get("hold_credits") + " " + est.get("min_credits") + " " + est.get("model"));

input = JSON.parse(File.read("input.json"))
est = api("POST", "/estimate", input)
puts [est["hold_credits"], est["min_credits"], est["model"]].inspect

$input = json_decode(file_get_contents("input.json"), true);
$est = api("POST", "/estimate", $input);
echo $est["hold_credits"], " ", $est["min_credits"], " ", $est["model"], "\n";

var input = JsonNode.Parse(File.ReadAllText("input.json"))!;
var est = await Api.Call("POST", "/estimate", input);
Console.WriteLine($"{est!["hold_credits"]} {est["min_credits"]} {est["model"]}");

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 sponsor-why:<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 case carries summary, verdict, segment, will_not_offer, lead, coherence, jtbd, value_check, gaps and caveats; a story carries headline, opener, what_you_get, what_we_do_not_offer, audience, track_record, next_step, discovery_questions and note. The code below prints the headline of either.

KEY="sponsor-why:case:$(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 '.verdict // .note, .summary // .headline' reply.json
jq -r '.coherence[]? | "\(.category): \(.status)"' reply.json   # a case; a story has .what_you_get

import hashlib, time
key = "sponsor-why:" + inp["task"] + ":" + hashlib.sha256(json.dumps(inp).encode()).hexdigest()[:16] + ":a1"
job = api("POST", "/run", inp, {"Idempotency-Key": key})
while True:
    j = api("GET", "/jobs/" + job["job_id"])
    if j["status"] in ("succeeded", "failed", "cancelled"):
        break
    time.sleep(2)
reply = json.loads(j["output"]["output"])  # the reply as one JSON object
print(j["charged_credits"], j.get("truncated"), reply.get("verdict") or reply.get("note"))
for row in reply.get("coherence") or reply.get("what_you_get") or []:
    print("-", row["category"], row.get("status") or row.get("proof"))

import { createHash } from "node:crypto";
const key = `sponsor-why:${input.task}:${createHash("sha256").update(JSON.stringify(input)).digest("hex").slice(0, 16)}:a1`;
const job = await api("POST", "/run", input, { "Idempotency-Key": key });
let j;
do { await new Promise((r) => setTimeout(r, 2000)); j = await api("GET", "/jobs/" + job.job_id); }
while (!["succeeded", "failed", "cancelled"].includes(j.status));
const reply = JSON.parse(j.output.output);
console.log(j.charged_credits, j.truncated, reply.verdict ?? reply.note);
for (const row of reply.coherence || reply.what_you_get || []) console.log("-", row.category, row.status || row.proof);

sum := sha256.Sum256(raw) // add "crypto/sha256", "encoding/hex", "time" to the imports
key := "sponsor-why:" + input["task"].(string) + ":" + hex.EncodeToString(sum[:8]) + ":a1"
job, _ := api("POST", "/run", input, map[string]string{"Idempotency-Key": key})
var j map[string]any
for {
	time.Sleep(2 * time.Second)
	j, _ = api("GET", "/jobs/"+job["job_id"].(string), nil, nil)
	if s := j["status"]; s == "succeeded" || s == "failed" || s == "cancelled" { break }
}
var reply map[string]any
json.Unmarshal([]byte(j["output"].(map[string]any)["output"].(string)), &reply)
fmt.Println(j["charged_credits"], j["truncated"], reply["verdict"], reply["note"])
rows, _ := reply["coherence"].([]any) // a case's coherence; a story has what_you_get
for _, row := range rows {
	fmt.Println("-", row.(map[string]any)["category"], row.(map[string]any)["status"])
}

var digest = java.security.MessageDigest.getInstance("SHA-256").digest(M.writeValueAsBytes(input));
String key = "sponsor-why:" + input.get("task") + ":" + HexFormat.of().formatHex(digest, 0, 8) + ":a1";
JsonNode job = api("POST", "/run", input, Map.of("Idempotency-Key", key)), j;
do { Thread.sleep(2000); j = api("GET", "/jobs/" + job.get("job_id").asText(), null, null); }
while (!Set.of("succeeded", "failed", "cancelled").contains(j.get("status").asText()));
JsonNode reply = M.readTree(j.get("output").get("output").asText());
System.out.println(j.get("charged_credits") + " " + reply.path("verdict").asText(reply.path("note").asText()));
for (JsonNode row : reply.path("coherence")) System.out.println("- " + row.path("category").asText() + " " + row.path("status").asText());

require "digest"
key = "sponsor-why:#{input["task"]}:#{Digest::SHA256.hexdigest(JSON.generate(input))[0, 16]}:a1"
job = api("POST", "/run", input, { "Idempotency-Key" => key })
j = nil
loop do
  sleep 2
  j = api("GET", "/jobs/#{job["job_id"]}")
  break if %w[succeeded failed cancelled].include?(j["status"])
end
reply = JSON.parse(j["output"]["output"])
puts [j["charged_credits"], j["truncated"], reply["verdict"] || reply["note"]].inspect
(reply["coherence"] || []).each { |row| puts "- #{row["category"]} #{row["status"]}" }

$key = "sponsor-why:" . $input["task"] . ":" . substr(hash("sha256", json_encode($input)), 0, 16) . ":a1";
$job = api("POST", "/run", $input, ["Idempotency-Key" => $key]);
do { sleep(2); $j = api("GET", "/jobs/" . $job["job_id"]); }
while (!in_array($j["status"], ["succeeded", "failed", "cancelled"]));
$reply = json_decode($j["output"]["output"], true);
echo $j["charged_credits"], " ", ($reply["verdict"] ?? $reply["note"] ?? ""), "\n";
foreach ($reply["coherence"] ?? [] as $row) echo "- ", $row["category"], " ", $row["status"], "\n";

var digest = System.Security.Cryptography.SHA256.HashData(System.Text.Encoding.UTF8.GetBytes(input.ToJsonString()));
var key = $"sponsor-why:{input["task"]}:{Convert.ToHexString(digest, 0, 8).ToLowerInvariant()}:a1";
var job = await Api.Call("POST", "/run", input, new() { ["Idempotency-Key"] = key });
JsonNode j;
do { await Task.Delay(2000); j = (await Api.Call("GET", "/jobs/" + job!["job_id"]))!; }
while (!new[] { "succeeded", "failed", "cancelled" }.Contains(j["status"]!.GetValue<string>()));
var reply = JsonNode.Parse(j["output"]!["output"]!.GetValue<string>());
Console.WriteLine($"{j["charged_credits"]} {reply!["verdict"] ?? reply["note"]}");
foreach (var row in reply["coherence"] as JsonArray ?? new JsonArray()) Console.WriteLine("- " + row!["category"] + " " + row["status"]);

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: sponsor-why:case:$(shasum -a 256 input.json | cut -c1-16):a1" --data @input.json

rev = json.load(open("input.json"))  # the same run input as input.json: {"task": "case", "event": "Event: ... | dates: ... | as of: ...", "evidence": "Audience evidence (Q4) - 5 rows ...", "program": "Program activities - 3 ...", "notes": "", "facts": "Verdict: ..."}
# - see the input table
req = urllib.request.Request(BASE + "/run-stream", method="POST", data=json.dumps(rev).encode(),
    headers={"Content-Type": "application/json", "Authorization": "Bearer " + TOKEN,
             "Idempotency-Key": "sponsor-why:case:" + hashlib.sha256(json.dumps(rev).encode()).hexdigest()[:16] + ":a1"})
with urllib.request.urlopen(req) as r:
    for line in r:
        line = line.decode().strip()
        if line.startswith("data:"):
            print(line[5:].strip()[:200])

const rev = JSON.parse(readFileSync("input.json", "utf8"));
const r = await fetch(BASE + "/run-stream", { method: "POST", body: JSON.stringify(rev), headers: {
  "Content-Type": "application/json", Authorization: "Bearer " + TOKEN,
  "Idempotency-Key": `sponsor-why:case:${createHash("sha256").update(JSON.stringify(rev)).digest("hex").slice(0, 16)}:a1` } });
const dec = new TextDecoder();
for await (const chunk of r.body) for (const line of dec.decode(chunk).split("\n"))
  if (line.startsWith("data:")) console.log(line.slice(5).trim().slice(0, 200));

rraw, _ := os.ReadFile("input.json") // add "bufio", "strings" to the imports
rs := sha256.Sum256(rraw)
req, _ := http.NewRequest("POST", base+"/run-stream", bytes.NewReader(rraw))
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Authorization", "Bearer "+token)
req.Header.Set("Idempotency-Key", "sponsor-why:case:"+hex.EncodeToString(rs[:8])+":a1")
res, _ := http.DefaultClient.Do(req)
sc := bufio.NewScanner(res.Body)
for sc.Scan() { if l := sc.Text(); strings.HasPrefix(l, "data:") { fmt.Println(l[5:]) } }

String rev = java.nio.file.Files.readString(java.nio.file.Path.of("input.json"));
var rd = java.security.MessageDigest.getInstance("SHA-256").digest(rev.getBytes());
var sreq = HttpRequest.newBuilder(URI.create(BASE + "/run-stream")).header("Content-Type", "application/json")
  .header("Authorization", "Bearer " + token).header("Idempotency-Key", "sponsor-why:case:" + HexFormat.of().formatHex(rd, 0, 8) + ":a1")
  .POST(HttpRequest.BodyPublishers.ofString(rev)).build();
C.send(sreq, HttpResponse.BodyHandlers.ofLines()).body().filter(l -> l.startsWith("data:")).forEach(System.out::println);

rev = File.read("input.json")
uri = URI(BASE + "/run-stream")
req = Net::HTTP::Post.new(uri, "Content-Type" => "application/json", "Authorization" => "Bearer #{TOKEN}",
  "Idempotency-Key" => "sponsor-why:case:#{Digest::SHA256.hexdigest(rev)[0, 16]}:a1")
req.body = rev
Net::HTTP.start(uri.host, uri.port, use_ssl: true) do |h|
  h.request(req) { |res| res.read_body { |chunk| chunk.each_line { |l| puts l if l.start_with?("data:") } } }
end

$rev = file_get_contents("input.json");
$ch = curl_init(BASE . "/run-stream");
curl_setopt_array($ch, [CURLOPT_POST => true, CURLOPT_POSTFIELDS => $rev, CURLOPT_HTTPHEADER => [
    "Content-Type: application/json", "Authorization: Bearer $TOKEN",
    "Idempotency-Key: sponsor-why:case:" . substr(hash("sha256", $rev), 0, 16) . ":a1"],
    CURLOPT_WRITEFUNCTION => function ($ch, $chunk) { foreach (explode("\n", $chunk) as $l) if (str_starts_with($l, "data:")) echo $l, "\n"; return strlen($chunk); }]);
curl_exec($ch);

var rev = File.ReadAllText("input.json");
var rd = System.Security.Cryptography.SHA256.HashData(System.Text.Encoding.UTF8.GetBytes(rev));
var sreq = new HttpRequestMessage(HttpMethod.Post, Api.Base + "/run-stream") { Content = new StringContent(rev, System.Text.Encoding.UTF8, "application/json") };
sreq.Headers.Add("Authorization", "Bearer " + Api.Token);
sreq.Headers.Add("Idempotency-Key", $"sponsor-why:case:{Convert.ToHexString(rd, 0, 8).ToLowerInvariant()}:a1");
using var http = new HttpClient();
using var res = await http.SendAsync(sreq, HttpCompletionOption.ResponseHeadersRead);
using var rdr = new StreamReader(await res.Content.ReadAsStreamAsync());
for (string? l; (l = await rdr.ReadLineAsync()) != null;) if (l.StartsWith("data:")) Console.WriteLine(l);

Run Sponsor Why from your own code

Base URL and the response shape

The task field comes first

The input

The rules the model applies

House rules

The replies

case

story

Worked examples - both lanes

A 600-person community conference, recruiting buyer, a lead-gen claim slipped in - case

The same, cleaned - every claim proven - story

A practitioner sponsor, no claims drafted yet - case

A first edition, product-feedback buyer, no honesty gate yet - story

The free six-part statement for the cleaned sample

Build the input yourself

Step 1 — a tiny client helper

Step 2 — a token

Step 3 — GET /me

Step 4 — POST /estimate

Step 5 — POST /run, then poll the job

Step 6 — POST /run-stream

Step 3 — `GET /me`

Step 4 — `POST /estimate`

Step 5 — `POST /run`, then poll the job

Step 6 — `POST /run-stream`