← Market Seed
API
Tokens

Run Market Seed from your own code

Both metered lanes are available over HTTP and each returns one JSON object. The division of labour: the page runs the build gate on four evidenced triggers, ranks curation, take-rate and seeding with the moves the interview causes, and checks the governance rules, the economics and the seeding plan, then hands it all to the run as facts. The run writes the marketplace decision or the rulebook; the page then holds it to its own facts (msreply.js).

Base URL and the response shape

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

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

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

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

The task field comes first

Two lanes, chosen by task, in the order the work runs - whether and which way, then the rules once the gate says build:

A missing or unknown task is answered as decision. Both lanes send the same five fields. The facts are the page's checks, one row per line, and a line starting "must:" is a rule the reply has to hold. The page's handoff carries the decision into carry for the rulebook lane.

The input

FieldRequiredWhat
taskyesdecision or rulebook. If it is missing or neither, do decision and set "task": "decision".
platformyesthe product and why a marketplace now, the ecosystem today, demand and supply evidence, staffing, purpose, data sensitivity, intent, curation, billing, the planned rate and notice, partner concentration, placement, the hard side, the atomic network and the re-ranking answers; "not given" means not given.
rulesyesevery governance rule drafted so far with the question it answers, its owner, its removal path and the market failure it addresses.
carrysend it (empty for decision)rulebook task only: the decision's choices, when the decision task ran first; may be empty.
factsyesthe page's checks, one line each as area | id | status | evidence, the verdict and the ranked menus. A line starting "must:" applies to your reply.
retry_notenooptional; if present, your previous reply was unusable - follow it.

The rules the model applies

From the source skill, @samber/connector-marketplace-strategy - the only standard the run applies:

House rules

The replies

decision

Write the decision document: build, buy, catalog or join, and how.

  1. summary - one sentence, at most 40 words: the path, and the evidence it rests on.
  2. path - choice (build, buy, catalog or join, exactly as the facts settle it), why (one sentence in this platform's terms).
  3. triggers - exactly four objects in this order - customer pull, supply signal, procurement friction, staffed lifecycle: trigger (its name), holds (true or false, as the facts read it), evidence (one sentence citing this platform's evidence, or what is missing).
  4. business_case - one sentence naming which case carries a build - distribution and ecosystem value, or retention and expansion value - for this platform; empty when the path is not build.
  5. revisit - short strings: each failing trigger, as the measurable condition in this platform's terms that would reopen build; empty when the path is build.
  6. candidates - two or three objects: name, archetype (the platform archetype it resembles, by type, not a company the input does not name), curation (hybrid, open, review or partnership), take_rate (zero, tiered or flat), seeding (firstparty, sequential, subsidies or social), optimizes, costs, failure (one sentence each). When the path is build, every candidate bundles the three rungs, the bundles differ, and one carries the page's ranked rungs. When it is not build, the candidates are ways to carry out that path and the three rung ids are empty strings.
  7. recommendation - candidate (one candidate's name, exactly), why (one sentence tied to this platform's answers).
  8. caveats - at most 4 short strings; [] when there is nothing to say.
{
  "task": "decision",
  "summary": "one sentence",
  "path": { "choice": "build", "why": "one sentence" },
  "triggers": [ { "trigger": "customer pull", "holds": true, "evidence": "one sentence" } ],
  "business_case": "one sentence",
  "revisit": [ ],
  "candidates": [ { "name": "a short name", "archetype": "a platform type", "curation": "hybrid", "take_rate": "zero", "seeding": "firstparty", "optimizes": "one sentence", "costs": "one sentence", "failure": "one sentence" } ],
  "recommendation": { "candidate": "a candidate's name", "why": "one sentence" },
  "caveats": [ ]
}

The page holds it to its own facts (check() in msreply.js; any warning makes the reply flagged): the reply answers the task it was sent; no web link; no backticks; a summary of at most 40 words; the gate's path; all four triggers in order, holding or failing as the page reads them, each with evidence; the business case for a build, or each failing trigger as a condition to reopen build; two or three candidates with what each optimizes, costs and courts - for a build each bundling the page's rung ids, the bundles differing and one carrying the ranked rungs; a recommendation naming one candidate; at most four caveats.

rulebook

Write the operating rules for the chosen model (the page offers this task only when the gate says build).

  1. summary - one sentence, at most 40 words.
  2. governance - admission, value, conflict, each an object: rule (one or two sentences for this platform), owner (the role that owns it, as the input names it, else a role to appoint, said to be appointed), removal (the removal or delisting path; required for conflict).
  3. causes - four objects, one per market-failure cause: cause (information asymmetry, externalities, monopoly power or risk), rule (the rule that addresses it on this platform).
  4. economics - take_rate (zero, tiered or flat, exactly as the facts rank first), level (the percentage or threshold, as the input gives it or labelled as proposed), notice (the notice period for rate changes - at least six months), circumvention (the anti-circumvention rule with its delisting path), disclosure (the label rule for paid placement - written whenever paid placement is planned, even if no rule exists yet; empty only when none is planned).
  5. seeding - hard_side (who it is on this platform), atomic_network (the one dense use case), rung (firstparty, sequential, subsidies or social, exactly as the facts rank first), promote_when (one sentence: the measurable condition that moves to the next rung).
  6. metrics - supply, demand, flywheel (short strings each; supply first).
  7. review - one sentence: by whom the governance rules are reviewed, and when - a cadence labelled proposed, or the events that trigger a review.
  8. caveats - at most 4 short strings; [] when there is nothing to say.
{
  "task": "rulebook",
  "summary": "one sentence",
  "governance": { "admission": { "rule": "", "owner": "", "removal": "" }, "value": { "rule": "", "owner": "", "removal": "" }, "conflict": { "rule": "", "owner": "", "removal": "" } },
  "causes": [ { "cause": "information asymmetry", "rule": "one sentence" } ],
  "economics": { "take_rate": "zero", "level": "", "notice": "six months", "circumvention": "one sentence", "disclosure": "" },
  "seeding": { "hard_side": "", "atomic_network": "", "rung": "firstparty", "promote_when": "one sentence" },
  "metrics": { "supply": [ "a metric" ], "demand": [ "a metric" ], "flywheel": [ "a metric" ] },
  "review": "one sentence",
  "caveats": [ ]
}

The page requires: the reply answers the task it was sent; the same text rules; admission, value and conflict rules each with an owner, and conflict with a removal path; all four market-failure causes, each with its rule; the ranked take-rate, at least six months' notice and an anti-circumvention rule with delisting (and a label rule when paid placement is planned); the hard side, the atomic network, the ranked seeding rung and what promotes it; supply metrics; a governance review.

Worked examples

Three runs from the page's free samples (invented companies): the decision for a contract platform with real pull and partners, the rulebook for the same platform carrying that decision, and the decision for an HR SaaS whose board wants an app store. Each input is exactly what the page sends; each reply is the saved reply the sample replays, shipped unedited - but the facts and long strings are shortened in this display only, and every cut is listed under the example. The last line is the page's own check of the full reply.

decision - A contract platform with real pull and partners

The page read it as: a marketplace you can build and run; gate path build (4 of 4 triggers); curation hybrid, open, review, partnership; take-rate zero; seeding firstparty, social, sequential; 5 of 5 gates; failing checks: none.

Input (facts is 2271 characters; the first 1399 are shown):

{
 "task": "decision",
 "platform": "Platform: Clausewren\nThe product and why a marketplace now: A contract-management platform; enterprise deals stall over missing CRM and e-signature integrations, and three vendors already ship unofficial connectors.\nEcosystem today: A partner directory or catalog; integrations live: 14; partners asking to build: 9; demand: Deals lost or stalled over missing integrations; procurement friction: yes; supply: Third parties already shipped unofficial integrations; partner lifecycle staffed: yes; many integrations needed fast: no\nPurpose: Retention and stickiness; data sensitivity: medium; team intent: build; planned curation: Hybrid: open admission plus a certified tier; resellers or co-selling expected: no\nBilling through the platform: no; partners visibly winning: no; marketplace is the procurement gate: no; planned take-rate: 0%; notice for rate changes: 6 months; top partner's share of partner revenue: 45%; paid featured placement: yes (disclosed: yes)\nHard side: developers; it has a reason to show up today: yes; atomic network: contract approval flows that start in a CRM and end in e-signature; subsidy budget: no; developer community: yes; hard date: no; a compounding asset; effort ceiling: medium; as-of: 2026-11-01",
 "rules": "Governance rules (rule | answers | owner | removal path | market failure):\n- Open listing behind automated checks; certified badge for apps passing the security questionnaire and a 99% API success floor | answers: admission (who gets in, and who decides) | owner: Partner program manager | removal path: yes | against: information asymmetry, risk\n- Zero revenue share while seeding, with six months' notice before any change | answers: value (how value divides between platform, partner and customer) | owner: Head of partnerships | removal path: NO | against: information asymmetry\n- Apps routing contract billing around the platform are delisted after 30 days' notice | answers: conflict (disputes, enforcement and removal) | owner: Partner program manager | removal path: yes | against: externalities\n- Paid featured slots are labelled as sponsored | answers: value (how value divides between platform, partner and customer) | owner: Marketing lead | removal path: NO | against: information asymmetry\n- Shared analytics and co-marketing pool for partners under 10 installs | answers: value (how value divides between platform, partner and customer) | owner: Head of partnerships | removal path: NO | against: monopoly power",
 "carry": "",
 "facts": "The page's checks (0 fail, 0 warn, 6 pass, 1 n/a); verdict: a marketplace you can build and run:\n- The gate and the model | triggers | na | customer pull: holds - Deals lost or stalled over missing integrations; a supply signal: holds - Third parties already shipped unofficial integrations; repeated procurement friction: holds - one-off integration requests keep stalling procurement; a staffed partner lifecycle: holds - public API, docs, sandbox, review and partner support as a standing commitment - build our own marketplace\n- The gate and the model | evidence | pass | the intent (build) fits the gate (build)\n- Governance | governance | pass | all three questions answered, owned, with a delisting path\n- Governance | concentration | pass | the top partner holds 45% of partner revenue - pool scale (shared analytics and marketing) for the rest\n- Economics and seeding | curation | pass | planned Hybrid: open admission plus a certified tier; ranked: Hybrid: open admission plus a certified tier > Open admission > A single hard review gate > Partnership-gated listing\n- Economics and seeding | economics | pass | zero take, 6 months' notice committed; ranked: Zero take while seeding - billing does not flow through the platform - no share can be collected\n- Economics and seeding | seeding | pass | hard side: the developers who build the apps; atomic network: contract approval flows that\n\n[... 872 more characters cut from this display ...]"
}

Reply (long strings shortened for display - see the cuts below):

{
 "task": "decision",
 "summary": "Clausewren should build its own marketplace: stalled enterprise deals, nine partners asking to build, three unofficial connectors, repeated procurement friction and a staffed partner lifecycle clear all four triggers.",
 "path": {
  "choice": "build",
  "why": "Every trigger holds for Clausewren, and the CRM and e-signature connectors that keep stalling enterprise contracts are already being built by outsiders without a home on the platform."
 },
 "triggers": [
  {
   "trigger": "customer pull",
   "holds": true,
   "evidence": "Enterprise deals are lost or stalled over missing CRM and e-signature integrations."
  },
  {
   "trigger": "supply signal",
   "holds": true,
   "evidence": "Three vendors already ship unofficial Clausewren connectors and nine partners are asking to build."
  },
  {
   "trigger": "procurement friction",
   "holds": true,
   "evidence": "One-off integration requests keep stalling enterprise procurement of Clausewren."
  },
  {
   "trigger": "staffed lifecycle",
   "holds": true,
   "evidence": "A public API, docs, sandbox, review and partner support are staffed as a standing commitment."
  }
 ],
 "business_case": "Retention and expansion value carries the build: Clausewren's purpose is stickiness, and connectors that keep contract approvals flowing from the CRM to e-signature make accounts harder to leave rather than opening a new revenue line.",
 "revisit": [],
 "candidates": [
  {
   "name": "Certified contract-flow marketplace",
   "archetype": "a large CRM's curated app directory with a certified tier",
   "curation": "hybrid",
   "take_rate": "zero",
   "seeding": "firstparty",
   "optimizes": "It lets the nine interested partners and the three unofficial connectors list quickly behind automated checks while the certified badge signals which apps meet the security questionnaire and the 99% API success floor.",
   "costs": "Clausewren must keep its own CRM-to-e-signature connectors best in class and run the certification checks continuously.",
   "failure": "If the badge tier grows lax, buyers stop trusting it and the certified apps lose their edge in enterprise procurement."
  },
  {
   "name": "Open connector hub",
   "archetype": "an open developer platform's self-serve app listing",
   "curation": "open",
   "take_rate": "zero",
   "seeding": "sequential",
   "optimizes": "It maximizes listings by admitting any app that passes automated checks and drawing builders in with the sandbox and tooling first.",
   "costs": "It gives up the certified signal enterprise buyers rely on and pushes quality policing onto support and delisting.",
   "failure": "With medium-sensitivity contract data, a weak listing can damage trust in the whole catalog before enforcement catches it."
  },
  {
   "name": "Community-built certified catalog",
   "archetype": "a developer-tools platform's community-driven extension gallery with a verified tier",
   "curation": "hybrid",
   "take_rate": "zero",
   "seeding": "social",
   "optimizes": "It leans on Clausewren's existing developer community and hackathons to fill the catalog behind the same open-plus-certified bar.",
   "costs": "It needs steady community programming and event effort against a medium effort ceiling.",
   "failure": "Leading with community events instead of first-party complements risks a broad, thin catalog that never makes the CRM-to-e-signature flow dense."
  }
 ],
 "recommendation": {
  "candidate": "Certified contract-flow marketplace",
  "why": "It carries the page's ranked rungs, matches the hybrid curation and zero take Clausewren already planned, and seeds the one dense use case, contract approvals from CRM to e-signature, with Clausewren's own connectors before layering community [... 13 more characters cut from this display]"
 },
 "caveats": [
  "The top partner holds 45% of partner revenue, so the shared analytics and co-marketing pool for smaller partners needs to stay funded.",
  "Paid featured slots must keep their sponsored label as the catalog grows.",
  "The value-division rules have no removal path written; only the conflict rule names delisting."
 ]
}

Cut from this display only (the saved reply and the check use the full text): recommendation.why (251 characters, 238 shown).

What step 5 prints for it: build: Clausewren should build its own marketplace: stalled enterprise deals, nine partners asking to build, three unofficial connectors, repeated procurement friction and a staffed partner lifecycle clear all four triggers.

The page's check: kept - nothing to flag

rulebook - A contract platform with real pull and partners

The input carries the saved decision (R.laneForm fills carry from the decision reply), as the page's handoff does. Take-rate ranked: zero; seeding ranked: firstparty, social, sequential.

Input (facts is 2371 characters; the first 1399 are shown):

{
 "task": "rulebook",
 "platform": "Platform: Clausewren\nThe product and why a marketplace now: A contract-management platform; enterprise deals stall over missing CRM and e-signature integrations, and three vendors already ship unofficial connectors.\nEcosystem today: A partner directory or catalog; integrations live: 14; partners asking to build: 9; demand: Deals lost or stalled over missing integrations; procurement friction: yes; supply: Third parties already shipped unofficial integrations; partner lifecycle staffed: yes; many integrations needed fast: no\nPurpose: Retention and stickiness; data sensitivity: medium; team intent: build; planned curation: Hybrid: open admission plus a certified tier; resellers or co-selling expected: no\nBilling through the platform: no; partners visibly winning: no; marketplace is the procurement gate: no; planned take-rate: 0%; notice for rate changes: 6 months; top partner's share of partner revenue: 45%; paid featured placement: yes (disclosed: yes)\nHard side: developers; it has a reason to show up today: yes; atomic network: contract approval flows that start in a CRM and end in e-signature; subsidy budget: no; developer community: yes; hard date: no; a compounding asset; effort ceiling: medium; as-of: 2026-11-01",
 "rules": "Governance rules (rule | answers | owner | removal path | market failure):\n- Open listing behind automated checks; certified badge for apps passing the security questionnaire and a 99% API success floor | answers: admission (who gets in, and who decides) | owner: Partner program manager | removal path: yes | against: information asymmetry, risk\n- Zero revenue share while seeding, with six months' notice before any change | answers: value (how value divides between platform, partner and customer) | owner: Head of partnerships | removal path: NO | against: information asymmetry\n- Apps routing contract billing around the platform are delisted after 30 days' notice | answers: conflict (disputes, enforcement and removal) | owner: Partner program manager | removal path: yes | against: externalities\n- Paid featured slots are labelled as sponsored | answers: value (how value divides between platform, partner and customer) | owner: Marketing lead | removal path: NO | against: information asymmetry\n- Shared analytics and co-marketing pool for partners under 10 installs | answers: value (how value divides between platform, partner and customer) | owner: Head of partnerships | removal path: NO | against: monopoly power",
 "carry": "Path: Build our own marketplace - Every trigger holds for Clausewren, and the CRM and e-signature connectors that keep stalling enterprise contracts are already being built by outsiders without a home on the platform.\nBusiness case: Retention and expansion value carries the build: Clausewren's purpose is stickiness, and connectors that keep contract approvals flowing from the CRM to e-signature make accounts harder to leave rather than opening a new revenue line.\nChosen model: Certified contract-flow marketplace (curation hybrid, take-rate zero, seeding firstparty)\nWhy: It carries the page's ranked rungs, matches the hybrid curation and zero take Clausewren already planned, and seeds the one dense use case, contract approvals from CRM to e-signature, with Clausewren's own connectors before layering community work on top.",
 "facts": "The page's checks (0 fail, 0 warn, 6 pass, 1 n/a); verdict: a marketplace you can build and run:\n- The gate and the model | triggers | na | customer pull: holds - Deals lost or stalled over missing integrations; a supply signal: holds - Third parties already shipped unofficial integrations; repeated procurement friction: holds - one-off integration requests keep stalling procurement; a staffed partner lifecycle: holds - public API, docs, sandbox, review and partner support as a standing commitment - build our own marketplace\n- The gate and the model | evidence | pass | the intent (build) fits the gate (build)\n- Governance | governance | pass | all three questions answered, owned, with a delisting path\n- Governance | concentration | pass | the top partner holds 45% of partner revenue - pool scale (shared analytics and marketing) for the rest\n- Economics and seeding | curation | pass | planned Hybrid: open admission plus a certified tier; ranked: Hybrid: open admission plus a certified tier > Open admission > A single hard review gate > Partnership-gated listing\n- Economics and seeding | economics | pass | zero take, 6 months' notice committed; ranked: Zero take while seeding - billing does not flow through the platform - no share can be collected\n- Economics and seeding | seeding | pass | hard side: the developers who build the apps; atomic network: contract approval flows that\n\n[... 972 more characters cut from this display ...]"
}

Reply (long strings shortened for display - see the cuts below):

{
 "task": "rulebook",
 "summary": "Clausewren runs a hybrid, zero-take marketplace seeded with its own CRM-to-e-signature connectors, where delisting enforces billing rules, sponsored slots carry a label and smaller partners share a scale pool.",
 "governance": {
  "admission": {
   "rule": "Any developer can list a Clausewren app once it clears the automated checks; the certified badge goes only to apps that pass the security questionnaire and hold a 99% API success floor, and losing the badge never drops the listing.",
   "owner": "Partner program manager",
   "removal": "An app that falls below the 99% API success floor or fails a repeat security questionnaire loses its certified badge but stays listed; an app that fails the automated checks is unlisted until it passes again."
  },
  "value": {
   "rule": "Clausewren takes no revenue share while seeding and gives six months' notice before any change, paid featured slots on the Clausewren marketplace are labelled as sponsored, and partners under 10 installs draw on a shared analytics and [... 19 more characters cut from this display]",
   "owner": "Head of partnerships",
   "removal": "Proposed: a paid featured slot shown without its sponsored label is pulled until the label is restored, and a partner leaves the shared pool once it passes 10 installs."
  },
  "conflict": {
   "rule": "A Clausewren app that routes contract billing around the platform is in breach, and disputes over that breach are decided by the partner program manager.",
   "owner": "Partner program manager",
   "removal": "The app is delisted after 30 days' notice if the billing route is not brought back through Clausewren."
  }
 },
 "causes": [
  {
   "cause": "information asymmetry",
   "rule": "The certified badge, earned through the security questionnaire and the 99% API success floor, and the sponsored label on paid slots tell Clausewren buyers which connectors are vetted and which are paid placement."
  },
  {
   "cause": "externalities",
   "rule": "Apps that route contract billing around Clausewren are delisted after 30 days' notice, so one partner's workaround does not erode the marketplace for everyone else."
  },
  {
   "cause": "monopoly power",
   "rule": "With the top partner holding 45% of partner revenue, the shared analytics and co-marketing pool for partners under 10 installs gives smaller Clausewren partners scale they could not reach alone."
  },
  {
   "cause": "risk",
   "rule": "Because Clausewren connectors touch contract data of medium sensitivity, the certified tier requires the security questionnaire and the 99% API success floor, and an app that fails them loses its badge."
  }
 ],
 "economics": {
  "take_rate": "zero",
  "level": "0%",
  "notice": "6 months, with any unfavourable change deferred until the notice runs out",
  "circumvention": "A Clausewren app that routes contract billing around the platform is delisted after 30 days' notice, owned by the partner program manager.",
  "disclosure": "Every paid featured slot on the Clausewren marketplace carries a sponsored label, owned by the marketing lead."
 },
 "seeding": {
  "hard_side": "The developers who build Clausewren apps, including the three vendors already shipping unofficial connectors and the nine partners asking to build.",
  "atomic_network": "Contract approval flows that start in a CRM and end in e-signature.",
  "rung": "firstparty",
  "promote_when": "Proposed: move to hackathons and community once Clausewren's own CRM and e-signature connectors are live and the unofficial third-party connectors have been listed on the marketplace."
 },
 "metrics": {
  "supply": [
   "active partners listing Clausewren apps",
   "time to first listing for a new partner",
   "catalog freshness of listed connectors",
   "top partner's share of partner revenue, from 45% today"
  ],
  "demand": [
   "share of Clausewren customers with an installed connector",
   "integrations per account"
  ],
  "flywheel": [
   "marketplace-influenced deals, baselined against the first quarter"
  ]
 },
 "review": "Proposed: the head of partnerships and the partner program manager review the Clausewren governance rules each quarter, starting from the first quarter's baseline.",
 "caveats": [
  "The value rules had no removal path in the draft; the ones above are proposed.",
  "The top partner's 45% share of partner revenue makes the shared pool a rule to watch, not a formality.",
  "Billing does not flow through Clausewren, so no share could be collected yet even if the rate changed."
 ]
}

Cut from this display only (the saved reply and the check use the full text): governance.value.rule (249 characters, 230 shown).

What step 5 prints for it: admission: Partner program manager | value: Head of partnerships | conflict: Partner program manager

The page's check: kept - nothing to flag

decision - An HR SaaS whose board wants an app store

The page read it as: not yet - a curated catalog first; gate path catalog (1 of 4 triggers); curation review, hybrid, open; take-rate zero; seeding sequential, firstparty; 0 of 1 gates; failing checks: evidence.

Input (facts is 2404 characters; the first 1398 are shown):

{
 "task": "decision",
 "platform": "Platform: Rotavane\nThe product and why a marketplace now: A shift-scheduling and HR SaaS for restaurants; the board wants an app store like the big HR suites have.\nEcosystem today: Bilateral integrations we built; integrations live: 6; partners asking to build: 0; demand: Recurring support and feature requests; procurement friction: no; supply: Neither; partner lifecycle staffed: no; many integrations needed fast: no\nPurpose: A revenue line; data sensitivity: high; team intent: build; planned curation: A single hard review gate; resellers or co-selling expected: no\nBilling through the platform: no; partners visibly winning: no; marketplace is the procurement gate: no; planned take-rate: 20%; notice for rate changes: not given; top partner's share of partner revenue: not given; paid featured placement: no (disclosed: no)\nHard side: developers; it has a reason to show up today: no; atomic network: not given; subsidy budget: no; developer community: no; hard date: no; a compounding asset; effort ceiling: low; as-of: 2026-11-01",
 "rules": "Governance rules (rule | answers | owner | removal path | market failure):\n- Every app passes a security review before listing | answers: admission (who gets in, and who decides) | owner: Platform security lead | removal path: yes | against: risk",
 "carry": "",
 "facts": "The page's checks (1 fail, 4 warn, 0 pass, 2 n/a); verdict: not yet - a curated catalog first:\n- The gate and the model | triggers | na | customer pull: holds - Recurring support and feature requests; a supply signal: fails - Neither; repeated procurement friction: fails - not reported; a staffed partner lifecycle: fails - not staffed as a standing commitment - a curated partner catalog first\n- The gate and the model | evidence | fail | the team intends to build, but a supply signal, repeated procurement friction, a staffed partner lifecycle fail - an expensive partner directory waiting to happen; a curated partner catalog first now, with the failed triggers as the conditions to revisit build\n- Governance | governance | warn | once you build: no rule answers value (how value divides between platform, partner and customer), conflict (disputes, enforcement and removal)\n- Governance | causes | warn | once you build: no rule against information asymmetry, externalities, monopoly power\n- Economics and seeding | curation | na | once you build: planned A single hard review gate; ranked: A single hard review gate > Hybrid: open admission plus a certified tier > Open admission - every app can read sensitive customer data - a single hard review gate, despite its cost; a low effort ceiling rules out partnership-gated listing\n- Economics and seeding | economics | warn | once you build: a\n\n[... 1006 more characters cut from this display ...]"
}

Reply:

{
 "task": "decision",
 "summary": "Rotavane should run a curated catalog of its six security-reviewed integrations, not an app store: recurring requests show customer pull, but no partner has asked to build, procurement is not stalling and no partner team is staffed.",
 "path": {
  "choice": "catalog",
  "why": "Only customer pull holds for Rotavane, so a reviewed catalog of the integrations it already runs answers the recurring requests without staffing a developer program that no partner has asked for."
 },
 "triggers": [
  {
   "trigger": "customer pull",
   "holds": true,
   "evidence": "Restaurant customers keep sending support tickets and feature requests for integrations."
  },
  {
   "trigger": "supply signal",
   "holds": false,
   "evidence": "No partner has asked to build on Rotavane and no third party has shipped an unofficial integration; all six live integrations were built in-house."
  },
  {
   "trigger": "procurement friction",
   "holds": false,
   "evidence": "Rotavane reports no deals stalling over one-off integration requests."
  },
  {
   "trigger": "staffed lifecycle",
   "holds": false,
   "evidence": "No one is staffed to run partner onboarding, review and support as a standing commitment, and the effort ceiling is low."
  }
 ],
 "business_case": "",
 "revisit": [
  "Supply signal: at least one outside partner asks to build on Rotavane or ships an unofficial integration, up from zero today.",
  "Procurement friction: restaurant deals are recorded as lost or stalled over a missing integration, where none are reported today.",
  "Staffed lifecycle: a named owner and budget for partner onboarding, the security review and partner support are committed as standing work, not borrowed from the security lead."
 ],
 "candidates": [
  {
   "name": "Reviewed integration catalog",
   "archetype": "a vertical SaaS's in-product integrations page",
   "curation": "",
   "take_rate": "",
   "seeding": "",
   "optimizes": "It turns the six integrations Rotavane already runs into one findable, security-reviewed list that answers the recurring requests.",
   "costs": "It costs a catalog page and keeping each entry's description and review current, which fits a low effort ceiling.",
   "failure": "It can go stale if listings are never refreshed, leaving restaurants to read it as a dead directory."
  },
  {
   "name": "Deeper bilateral six",
   "archetype": "a point-solution SaaS's settings-page connectors",
   "curation": "",
   "take_rate": "",
   "seeding": "",
   "optimizes": "It ranks the recurring requests and spends the engineering on making the existing integrations cover them better, with no listing surface at all.",
   "costs": "Every improvement stays on Rotavane's own engineering roadmap, with no outside builder sharing the load.",
   "failure": "Customers never see the integrations in one place, so the board's app-store question returns with nothing to show."
  },
  {
   "name": "Invite-only partner catalog",
   "archetype": "a large HR suite's partner directory",
   "curation": "",
   "take_rate": "",
   "seeding": "",
   "optimizes": "It lists the in-house integrations plus a few invited partner integrations that pass the security review, testing whether supply exists.",
   "costs": "Each invited partner needs the full security review and someone to chase them, which strains a low effort ceiling and an unstaffed partner function.",
   "failure": "With no partners asking to build, invitations go unanswered and the catalog looks half-empty."
  }
 ],
 "recommendation": {
  "candidate": "Reviewed integration catalog",
  "why": "It answers the one trigger that holds, the recurring integration requests, within a low effort ceiling while keeping every listing behind the security review that high-sensitivity HR data needs."
 },
 "caveats": [
  "The planned 20% share cannot be collected while billing does not flow through Rotavane, so the board's revenue-line purpose does not fit a catalog.",
  "Only an admission rule is written; value division and conflict and removal rules are still missing for any later build.",
  "No atomic network is named, so a future build has no dense use case to seed yet."
 ]
}

What step 5 prints for it: catalog: Rotavane should run a curated catalog of its six security-reviewed integrations, not an app store: recurring requests show customer pull, but no partner has asked to build, procurement is not stalling and no partner team is staffed.

The page's check: kept - nothing to flag

Build the input yourself

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

const K = MarketKit, R = MarketReply;
const f = K.form(Object.assign(K.blank(), { name: "Acme", demand: "deals", friction: "yes", supply: "asking", staffed: "no",
  rules: "Open listing behind automated checks | admission | Partner lead | yes | security risk" }));
// f.gatePath (the four triggers, the path, what failed), f.curationRank, f.rateRank, f.seedRank, f.ruleRows, f.gate
// K.gateMd(f), K.rulesCsv(f) - the gate memo and the rules table
const b = K.buildInput(f, "decision");                       // "rulebook" only once the gate says build
const wire = K.toWire(b.input);                              // POST this to /estimate and /run
// then: const reply = R.normalize(R.parseReply(job.output.output), "decision");
// R.check(reply, b)                                         // {status: kept or flagged, notes}

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

Step 1 — a tiny client helper

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

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

Step 2 — a token

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

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

Step 3 — GET /me

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

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

Step 4 — POST /estimate

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

# input.json: the run input object - {"task": "decision", "platform": "Platform: Clausewren
The product and why a marketplace now: ...", "rules": "Governance rules (rule | answers | owner | removal path | market failure):
- Open listing behind automated checks ...", "carry": "", "facts": "The page's checks (...); verdict: a marketplace you can build and run:
- The gate and the model | triggers | na | ..."}
# - see the input table
api POST /estimate "$(cat input.json)" | jq '.data | {hold_credits, min_credits, model, model_alias, markup_bps, warnings}'

Step 5 — POST /run, then poll the job

Send an Idempotency-Key built from the lane and the input: a retry with the same key never bills twice. The page uses market-seed:<task>:<inputHash>:a<attempt> - the lane is part of the key, retry_note is left out of the hash - and its one automatic reformat retry is a new attempt number, named in the page as one extra run. A decision reply carries summary, path, triggers, business_case, revisit, candidates, recommendation and caveats; a rulebook reply carries summary, governance, causes, economics, seeding, metrics, review and caveats. The code below prints the gist of either: the path and the summary, or the owner of each governance question.

KEY="market-seed:$(jq -r .task input.json):$(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 'if .task == "rulebook" then (.governance | to_entries[] | "\(.key): \(.value.owner)") 
       else "\(.path.choice): \(.summary)" end' reply.json

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: market-seed:$(jq -r .task input.json):$(shasum -a 256 input.json | cut -c1-16):a1" --data @input.json