naive-framework 0.0.0-stage → 0.1.0

package/purpose/frameworks/product-anatomy/anatomy.mjs

@@ -0,0 +1,195 @@
+// Product Anatomy Matrix runner, version 0.3.0 (unevaluated).
+//
+//   node anatomy.mjs request <venture>                      print the Jev request; sends nothing
+//   node anatomy.mjs score   <venture> <answers.json> --send ask Jev, write the answers file
+//   node anatomy.mjs matrix  <venture> <answers.json> [--json] deduce portfolio roles for every phase (Markdown, or JSON)
+//
+// <venture> is a venture folder (venture.json plus products/*.json, EE-011) or a
+// single input file with `venture`, `core`, `products` and `flows`.
+//
+// Order matters: the venture's core product (promise, who it is made to, what it must
+// not deliver, the competence behind it) is fixed first, and every product is
+// judged against it. Jev answers the typed questions in questions.json, one per
+// product. Spillover comes from each product's `flows_to` (or the input's `flows`). A wedge flows into the
+// flagship or is a standalone part of it (`part_of`); a revenue engine needs a revenue score of at least
+// must_hold.revenue_engine. Must-holds are checked in
+// code, never by Jev. Weights live in phases.json, so re-weighting a phase never
+// needs re-scoring. Without TYPESAFE_API_KEY, a reasoning model fills the same
+// answers file by hand and says so in its `scorer` field.
+
+import { existsSync, readdirSync, readFileSync, statSync, writeFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+
+const here = dirname(fileURLToPath(import.meta.url));
+const ENDPOINT = "https://api.typesafe.ai/v1/systemone";
+const MODEL = "jev-latest";
+const load = (p) => JSON.parse(readFileSync(p, "utf8"));
+const { questions } = load(join(here, "questions.json"));
+const { phases: allPhases, must_hold, tie } = load(join(here, "phases.json"));
+// Discovery has no weights: no product is ranked before the core product exists.
+const phases = allPhases.filter((p) => p.weights);
+
+// A venture folder is read as one input: venture.json, products/*.json, flows from flows_to.
+function readVenture(path) {
+  if (!statSync(path).isDirectory()) {
+    const input = load(path);
+    input.venture ??= input.company;
+    return input;
+  }
+  const venture = load(join(path, "venture.json"));
+  const dir = join(path, "products");
+  const cards = existsSync(dir) ? readdirSync(dir).filter((f) => f.endsWith(".json")).map((f) => load(join(dir, f))) : [];
+  const products = Object.fromEntries(cards.map((c) => [c.id, c]));
+  const flows = cards.flatMap((c) => (c.flows_to ?? []).map((to) => ({ from: c.id, to })));
+  return { venture, core: venture.core, products, flows };
+}
+
+function request(input) {
+  const qs = {};
+  for (const pid of Object.keys(input.products)) {
+    for (const [qid, q] of Object.entries(questions)) {
+      qs[`${qid}:${pid}`] = { ...q, instructions: `About the product in \`products.${pid}\`: ${q.instructions}` };
+    }
+  }
+  return { state: { venture: { ...input.venture, core: input.core }, products: input.products }, model: MODEL, questions: qs };
+}
+
+async function score(input, outPath) {
+  if (!process.env.TYPESAFE_API_KEY) {
+    console.error("No TYPESAFE_API_KEY set: fill the answers file with a reasoning model instead, and name it in `scorer`.");
+    process.exit(3);
+  }
+  const res = await fetch(ENDPOINT, {
+    method: "POST",
+    headers: { Authorization: `Bearer ${process.env.TYPESAFE_API_KEY}`, "Content-Type": "application/json" },
+    body: JSON.stringify(request(input)),
+  });
+  if (!res.ok) throw new Error(`TypeSafe returned ${res.status}: ${await res.text()}`);
+  const { answers } = await res.json();
+  const out = { scorer: MODEL, scored: new Date().toISOString(), answers: {} };
+  for (const [key, a] of Object.entries(answers)) {
+    const [qid, pid] = key.split(":");
+    out.answers[pid] ??= {};
+    out.answers[pid][qid] = a.type === "noul" ? a.noul : a.score;
+    out.answers[pid][`${qid}_confidence`] = a.confidence ?? null;
+  }
+  writeFileSync(outPath, JSON.stringify(out, null, 2) + "\n");
+  console.log(`wrote ${outPath} (${Object.keys(answers).length} answers from ${MODEL})`);
+}
+
+function norm(qid, v) {
+  const q = questions[qid];
+  return q.type === "score" ? v / (q.criteria.length - 1) : v;
+}
+
+function deduce(input, answersFile) {
+  const A = answersFile.answers;
+  const pids = Object.keys(input.products);
+  const out = Object.fromEntries(pids.map((p) => [p, 0]));
+  for (const f of input.flows ?? []) out[f.from] += 1;
+  const maxOut = Math.max(1, ...Object.values(out));
+  const phaseIndex = Object.fromEntries(phases.map((p, i) => [p.id, i]));
+  const now = phaseIndex[input.venture.phase] ?? -1; // -1: still in discovery, every phase is a projection
+
+  // Substrate: the product that is the core competence itself, phase-independent.
+  const substrate = pids.filter((p) => A[p].competence_draw >= 2.5)
+    .sort((a, b) => A[b].competence_draw - A[a].competence_draw || out[b] - out[a])[0] ?? null;
+
+  const byPhase = phases.map((ph, i) => {
+    const allowed = (p) => i >= phaseIndex[input.products[p].allowed_from ?? phases[0].id];
+    const rows = pids.map((p) => {
+      const w = ph.weights;
+      let sum = 0, total = 0;
+      for (const [c, wt] of Object.entries(w)) {
+        sum += wt * (c === "spillover" ? out[p] / maxOut : norm(c, A[p][c]));
+        total += wt;
+      }
+      const fails = [];
+      if (!allowed(p)) fails.push(`not allowed until ${input.products[p].allowed_from}`);
+      if (A[p].promise_delivery < must_hold.flagship.promise_delivery_at_least) fails.push("does not deliver the promise directly");
+      if (A[p].promise_breach >= must_hold.flagship.promise_breach_below) fails.push("could breach the promise");
+      return { p, score: sum / total, fails };
+    }).sort((a, b) => b.score - a.score);
+
+    const eligible = rows.filter((r) => !r.fails.length);
+    const flagship = eligible[0]?.p ?? null;
+    const tied = eligible.filter((r) => r.p !== flagship && eligible[0].score - r.score < tie).map((r) => r.p);
+    // A revenue engine needs real revenue, not merely the most of very little.
+    const topRevenue = Math.max(...pids.filter(allowed).map((p) => A[p].revenue));
+    const revenue = topRevenue < must_hold.revenue_engine.revenue_at_least ? []
+      : pids.filter((p) => allowed(p) && A[p].revenue === topRevenue);
+    // A wedge leads users into the flagship: it flows into it, or it is a part of the
+    // flagship kit that also stands alone (part_of, EE-015).
+    const leadsIn = (p) => (input.flows ?? []).some((f) => f.from === p && f.to === flagship)
+      || (input.products[p].part_of ?? []).includes(flagship);
+    // Each role is kept as an id (for data) and as the words the Markdown shows.
+    const role = {}, roleIds = {};
+    for (const p of pids) {
+      const r = [], ids = [];
+      const add = (id, text) => { ids.push(id); r.push(text); };
+      if (p === flagship) add("flagship", "flagship");
+      if (p === substrate) add("substrate", "substrate");
+      if (revenue.includes(p)) add("revenue-engine", revenue.length > 1 ? "revenue engine (tied)" : "revenue engine");
+      if (!r.length) {
+        if (!allowed(p)) add("option", `option (allowed from ${input.products[p].allowed_from})`);
+        else if (leadsIn(p) && A[p].ready >= 2) add("wedge", "wedge");
+        else if (A[p].promise_delivery <= 1 && A[p].competence_draw <= 1) add("unassigned", "unassigned: weak tie to the core");
+        else add("end-product", "end product");
+      }
+      role[p] = r.join(" + ");
+      roleIds[p] = { roles: ids, ...(revenue.includes(p) && revenue.length > 1 ? { revenue_engine_tied: true } : {}), ...(!allowed(p) ? { allowed_from: input.products[p].allowed_from } : {}) };
+    }
+    return { phase: ph, rows, flagship, tied, role, roleIds, projection: i > now };
+  });
+
+  byPhase.forEach((b, i) => {
+    const next = byPhase[i + 1];
+    if (next && next.flagship && next.flagship !== b.flagship) b.successor = next.flagship;
+  });
+  return { substrate, byPhase, out };
+}
+
+// The matrix as data (A-001): what the Markdown report shows, for tests and agents to read.
+function toJson(input, answersFile, d) {
+  return {
+    venture: input.venture.id ?? input.venture.name, phase: input.venture.phase, scorer: answersFile.scorer,
+    substrate: d.substrate,
+    phases: d.byPhase.map((b) => ({
+      id: b.phase.id, name: b.phase.name, projection: b.projection, flagship: b.flagship, tied: b.tied, successor: b.successor ?? null,
+      roles: b.roleIds,
+      role_text: b.role,
+      scores: Object.fromEntries(b.rows.map((r) => [r.p, { score: +r.score.toFixed(2), flagship_fails: r.fails }])),
+    })),
+  };
+}
+
+function report(input, answersFile, d) {
+  const name = (p) => input.products[p].name;
+  const lines = [`# Product Anatomy Matrix: ${input.venture.name}`, "",
+    `Scored by: ${answersFile.scorer.replace(/\.$/, "")}. Current phase: ${input.venture.phase}. Later phases are projections from today's answers; re-answer at each gate.`, "",
+    `Core promise: ${input.core.promise}`, ""];
+  lines.push("Portfolio role by phase:", "", `| Product | ${phases.map((p) => p.name).join(" | ")} |`, `| --- |${phases.map(() => " --- |").join("")}`);
+  for (const p of Object.keys(input.products)) lines.push(`| ${name(p)} | ${d.byPhase.map((b) => b.role[p]).join(" | ")} |`);
+  for (const b of d.byPhase) {
+    lines.push("", `## ${b.phase.name}${b.projection ? " (projection)" : ""}: ${b.phase.binding_constraint}. Gate: ${b.phase.gate}.`, "",
+      "| Product | Phase score | Flagship must-holds |", "| --- | ---: | --- |");
+    for (const r of b.rows) lines.push(`| ${name(r.p)} | ${r.score.toFixed(2)} | ${r.fails.length ? r.fails.join("; ") : "pass"} |`);
+    lines.push("", `Flagship: ${b.flagship ? name(b.flagship) : "none passes the must-holds"}${b.tied.length ? ` (tie within ${tie} with ${b.tied.map(name).join(", ")})` : ""}.${b.successor ? ` Successor: ${name(b.successor)}.` : ""}`);
+  }
+  return lines.join("\n");
+}
+
+const [cmd, inputPath, answersPath] = process.argv.slice(2).filter((a) => a !== "--send" && a !== "--json");
+if (!inputPath) { console.error("usage: node anatomy.mjs request|score|matrix <input.json> [answers.json] [--send]"); process.exit(2); }
+const input = readVenture(inputPath);
+if (!input.core) { console.error("This venture has no core product yet. State it before ranking products (it is required once the venture leaves discovery)."); process.exit(2); }
+if (cmd === "request") console.log(JSON.stringify(request(input), null, 2));
+else if (cmd === "score") {
+  if (!process.argv.includes("--send")) { console.log(JSON.stringify(request(input), null, 2)); console.error("Printed only. Add --send to call TypeSafe."); }
+  else await score(input, answersPath);
+} else if (cmd === "matrix") {
+  const answers = load(answersPath);
+  const d = deduce(input, answers);
+  console.log(process.argv.includes("--json") ? JSON.stringify(toJson(input, answers, d), null, 2) : report(input, answers, d));
+} else { console.error(`unknown command ${cmd}`); process.exit(2); }

package/purpose/frameworks/product-anatomy/examples/polity.answers.reasoned.json

@@ -0,0 +1,11 @@
+{
+  "scorer": "reasoning model (Claude), not Jev: no TYPESAFE_API_KEY in the session that wrote this. Draft for Torian to correct; replace by running `score --send`.",
+  "scored": "2026-10-26T22:50:00Z",
+  "answers": {
+    "social":    { "promise_delivery": 3, "competence_draw": 2, "promise_breach": 0.3,  "job_intensity": 2, "ready": 3, "revenue": 1, "reversibility": 2 },
+    "docket":    { "promise_delivery": 1, "competence_draw": 1, "promise_breach": 0.4,  "job_intensity": 2, "ready": 2, "revenue": 1, "reversibility": 3 },
+    "polity-os": { "promise_delivery": 2, "competence_draw": 2, "promise_breach": 0.1,  "job_intensity": 3, "ready": 1, "revenue": 3, "reversibility": 0 },
+    "data":      { "promise_delivery": 1, "competence_draw": 3, "promise_breach": 0.05, "job_intensity": 2, "ready": 2, "revenue": 3, "reversibility": 2 },
+    "nico":      { "promise_delivery": 0, "competence_draw": 0, "promise_breach": 0.3,  "job_intensity": 1, "ready": 0, "revenue": 1, "reversibility": 3 }
+  }
+}

package/purpose/frameworks/product-anatomy/examples/polity.json

@@ -0,0 +1,89 @@
+{
+  "venture": {
+    "name": "Polity",
+    "phase": "validation",
+    "team": "One founder working with AI agents; no employees.",
+    "current_state": "Polity Social (the polity-app web app, with Polity Search on its home page) is in build and use. Polity OS has an observer-mode prototype that reads public records only. The other products are defined but not built.",
+    "standing_decisions": [
+      "D-038: no services sold to governments before Stage 2; before Stage 2, everything about government serves the public."
+    ]
+  },
+  "core": {
+    "source": "Vision, Mission, Promise working lock, 2026-07-27 (applied to VISION_SPEC as a Class 2 patch)",
+    "promise": "When you trust Polity, you can find the institutional geometry that governs you, rendered with primary-source evidence or an explicit incomplete grade.",
+    "promised_to": "Members of the public: the people governed by the institutions Polity indexes.",
+    "must_not": "Spin or unlabeled persuasion delivered under Polity's name.",
+    "competence": "Indexing institutional geometry (jurisdictions, institutions, offices, seats, occupants, instruments, events, primary records) and rendering it with retrieval, quotation, grading and citation, including honest incompleteness."
+  },
+  "products": {
+    "social": {
+      "name": "Polity Social",
+      "faces": "the public",
+      "description": "The civic social network and Polity's public home: Polity Search over the index, representatives and places by address, notebooks, news, quantitative views, and pages for organisations (absorbs Notebook, Quant, News and the website builder)."
+    },
+    "docket": {
+      "name": "Docket",
+      "faces": "the public",
+      "description": "A friend-group conversation docket: friends form a group, add topics and media sources, and vote on what to discuss. Format first (works on paper), could be a plugin for Telegram, Discord or Slack, and absorbs the classroom and education use. Debate is one mode; good conversation is the goal."
+    },
+    "polity-os": {
+      "name": "Polity OS",
+      "faces": "governments and organisations as tenants, citizens as members",
+      "allowed_from": "beachhead",
+      "allowed_from_reason": "D-038 makes it the Stage 2 product. Mapping Polity's Stage 2 to the Beachhead phase is a draft assumption.",
+      "description": "One national multi-tenant operating system for governing bodies: governments and organisations run their procedures, agendas, votes and records on it; citizens are members. Merges the Citizens and Government editions and Justice. Today only an observer that turns public records into advisory validity reports."
+    },
+    "data": {
+      "name": "Polity Data",
+      "faces": "institutions, developers and researchers (no direct public face)",
+      "description": "The cited, structured index of institutional records, offered headless: API, datasets and reports for institutions, media, researchers and developers. Most justice-record work lives here."
+    },
+    "nico": {
+      "name": "Nico",
+      "faces": "the public",
+      "description": "A personal knowledge system that models a person's own values and ideas (Idionaut is one mode). No stated link yet to civic records."
+    }
+  },
+  "flows": [
+    {
+      "from": "data",
+      "to": "social",
+      "carries": "cited records"
+    },
+    {
+      "from": "data",
+      "to": "docket",
+      "carries": "cited sources for topics"
+    },
+    {
+      "from": "data",
+      "to": "polity-os",
+      "carries": "jurisdiction and procedure records"
+    },
+    {
+      "from": "data",
+      "to": "nico",
+      "carries": "positions and votes"
+    },
+    {
+      "from": "social",
+      "to": "docket",
+      "carries": "users and topics"
+    },
+    {
+      "from": "social",
+      "to": "nico",
+      "carries": "users"
+    },
+    {
+      "from": "docket",
+      "to": "social",
+      "carries": "groups who arrive through friends"
+    },
+    {
+      "from": "polity-os",
+      "to": "data",
+      "carries": "primary records created by tenants"
+    }
+  ]
+}

package/purpose/frameworks/product-anatomy/phases.json

@@ -0,0 +1,107 @@
+{
+  "version": "0.3.0",
+  "note": "Succession Matrix phases, gates and weights, version 0.x (unevaluated). The five phases are the venture phases of EE-012. Discovery has no weights: no product is ranked before the core product exists. Weights: 1 low, 2 medium, 3 high. Spillover is computed from flows_to, not asked. Changing a weight never needs re-scoring. Sources: purpose/references/references.json.",
+  "phases": [
+    {
+      "id": "discovery",
+      "name": "Discovery",
+      "question": "Does a real problem exist, and who has it?",
+      "gate": "Problem-solution fit",
+      "references": [
+        "blank-2005-four-steps"
+      ]
+    },
+    {
+      "id": "validation",
+      "name": "Validation",
+      "question": "Will people adopt this solution and keep using it?",
+      "binding_constraint": "proof that a niche wants the thing badly, and keeps using it",
+      "gate": "Product-market fit: retention holds",
+      "references": [
+        "blank-2005-four-steps",
+        "moore-1991-crossing-the-chasm",
+        "andreessen-2007-only-thing-that-matters",
+        "dixon-2010-thin-edge-of-the-wedge"
+      ],
+      "weights": {
+        "promise_delivery": 3,
+        "competence_draw": 2,
+        "job_intensity": 3,
+        "ready": 3,
+        "spillover": 1,
+        "revenue": 1,
+        "reversibility": 2
+      }
+    },
+    {
+      "id": "beachhead",
+      "name": "Beachhead",
+      "question": "Can we win one segment repeatably, at a profitable cost?",
+      "binding_constraint": "winning one mainstream segment outright",
+      "gate": "Repeatability",
+      "references": [
+        "moore-1991-crossing-the-chasm",
+        "zook-allen-2012-repeatability"
+      ],
+      "weights": {
+        "promise_delivery": 3,
+        "competence_draw": 2,
+        "job_intensity": 3,
+        "ready": 2,
+        "spillover": 2,
+        "revenue": 2,
+        "reversibility": 2
+      }
+    },
+    {
+      "id": "scale",
+      "name": "Scale",
+      "question": "How fast can we take the mass market?",
+      "binding_constraint": "scale, revenue and margin",
+      "gate": "Market leadership with healthy margins",
+      "references": [
+        "moore-1995-inside-the-tornado"
+      ],
+      "weights": {
+        "promise_delivery": 3,
+        "competence_draw": 3,
+        "job_intensity": 2,
+        "ready": 1,
+        "spillover": 3,
+        "revenue": 3,
+        "reversibility": 1
+      }
+    },
+    {
+      "id": "platform",
+      "name": "Platform",
+      "question": "What will others build on, so the venture can't be displaced?",
+      "binding_constraint": "becoming what others build on before the core goes stale",
+      "gate": "Others build on it",
+      "references": [
+        "baghai-coley-white-1999-alchemy-of-growth",
+        "google-2026-six-phase-model"
+      ],
+      "weights": {
+        "promise_delivery": 3,
+        "competence_draw": 3,
+        "job_intensity": 1,
+        "ready": 1,
+        "spillover": 3,
+        "revenue": 2,
+        "reversibility": 3
+      }
+    }
+  ],
+  "must_hold": {
+    "flagship": {
+      "promise_delivery_at_least": 2,
+      "promise_breach_below": 0.5,
+      "allowed_in_phase": true
+    },
+    "revenue_engine": {
+      "revenue_at_least": 2
+    }
+  },
+  "tie": 0.1
+}

package/purpose/frameworks/product-anatomy/questions.json

@@ -0,0 +1,74 @@
+{
+  "version": "0.2.0",
+  "note": "Product Anatomy Matrix questions, version 0.x (unevaluated). Each is one typed judgment per product, asked against the venture's core product in `venture.core`. Weights live in phases.json, apart from the answers.",
+  "questions": {
+    "promise_delivery": {
+      "type": "score",
+      "instructions": "When the people the core promise is made to use this product, how directly do they get what `venture.core.promise` promises?",
+      "criteria": [
+        "They do not get it from this product at all",
+        "They get it only indirectly, through another product or an intermediary",
+        "They get part of it directly from this product",
+        "They get the whole promise directly from this product"
+      ]
+    },
+    "competence_draw": {
+      "type": "score",
+      "instructions": "How much does this product depend on the core competence described in `venture.core.competence`?",
+      "criteria": [
+        "It does not use the core competence",
+        "It uses the core competence's outputs now and then",
+        "It is built on the core competence and would not work without it",
+        "It is the core competence itself, offered as a product"
+      ]
+    },
+    "promise_breach": {
+      "type": "noul",
+      "instructions": "As described, could this product lead people to receive what `venture.core.must_not` rules out, under the venture's name?",
+      "criteria": {
+        "true": "Yes: the product's normal use could deliver what the promise rules out",
+        "false": "No: its normal use stays within the promise"
+      }
+    },
+    "job_intensity": {
+      "type": "score",
+      "instructions": "How strongly do this product's first users feel the problem it solves?",
+      "criteria": [
+        "A mild preference: they would not change their habits for it",
+        "A noticeable annoyance they would fix if it were easy",
+        "A real pain they already spend time or money working around",
+        "An urgent pain they would adopt an unfinished product to fix"
+      ]
+    },
+    "ready": {
+      "type": "score",
+      "instructions": "Given `venture.members` (people and agents, each with a role), `venture.phase` and this product's `status`, how close is this product to being usable by real users? Agents count as team for work they can do under the venture's decision rights.",
+      "criteria": [
+        "It is an idea; most of it would need building with people the venture does not have",
+        "Parts exist, but it needs major work or people the venture does not have",
+        "Most of it exists, or it could be built by the current team within a few months",
+        "Real users can use it now"
+      ]
+    },
+    "revenue": {
+      "type": "score",
+      "instructions": "How strong is this product's own path to revenue, without counting what it does for the other products?",
+      "criteria": [
+        "No credible revenue path",
+        "A weak or distant revenue path",
+        "A clear revenue path that others in its market already prove",
+        "Buyers who would pay now, with a clear price"
+      ]
+    },
+    "reversibility": {
+      "type": "score",
+      "instructions": "If the venture led with this product and it proved the wrong choice, how easily could it back off?",
+      "criteria": [
+        "Very hard: commitments to customers, contracts or regulators would be broken",
+        "Hard: it would cost significant money, trust or time",
+        "Moderate: some sunk work and some disappointed users",
+        "Easy: little would be lost"
+      ]
+    }
+  }
+}

package/purpose/kits/validation/README.md

@@ -0,0 +1,14 @@
+# Validation kit
+
+Purpose layer, second kit (EE-026). How probable it is that a venture is validated, from cited evidence rather than a declared phase.
+
+| Part | Where |
+| --- | --- |
+| Record types | One per sub-score: `schema/validation-<sub-score>.schema.json` at `<venture>/purpose/validation/<sub-score>.json`; all share `schema/validation-evidence.schema.json` |
+| Weights | `weights.json`: weights and floors by go-to-market path and venture kind (version 0.x, unevaluated) |
+| Grading and score | `node schema/check-validation.mjs <dir> [--json] [--score]`: GRADE levels per evidence item and record, data facts (Ellis share, retention levelling off, team gaps), and the validation score |
+| Skills | `skills/problem-validation/`, `skills/validation-score/` |
+| Templates | `templates/<sub-score>.md` for each record, plus `templates/problem-interview.md` |
+| References | `references/references.json` |
+
+Sub-scores: problem, solution, product-market fit, pricing, go-to-market, team, operations readiness per MAD tier.

package/purpose/kits/validation/references/references.json

@@ -0,0 +1,122 @@
+{
+  "layer": "purpose",
+  "references": [
+    {
+      "id": "grade-handbook",
+      "title": "GRADE Handbook",
+      "authors": [
+        "GRADE Working Group"
+      ],
+      "year": 2013,
+      "kind": "standard",
+      "summary": "Certainty of evidence rated high, moderate, low or very low. Randomized trials start high and observational studies low; certainty drops for risk of bias, inconsistency, indirectness, imprecision and publication bias, and rises for a large effect or a dose-response gradient.",
+      "url": "https://gdt.gradepro.org/app/handbook/handbook.html",
+      "checked": "2026-10-27",
+      "informs": [
+        "rule:evidence-grade",
+        "field:validation-evidence.kind",
+        "field:validation-evidence.audience",
+        "field:validation-evidence.sample"
+      ],
+      "stance": {
+        "is": "adapted",
+        "why": "The four levels and the start-then-downgrade method are kept; study design becomes the kind of signal (behavior starts high, stated intent low), indirectness becomes audience fit and imprecision becomes sample size."
+      }
+    },
+    {
+      "id": "fitzpatrick-2013-mom-test",
+      "title": "The Mom Test",
+      "authors": [
+        "Rob Fitzpatrick"
+      ],
+      "year": 2013,
+      "kind": "book",
+      "summary": "Ask about people's lives and past behavior, not about your idea; compliments, generalities and hypotheticals are not data, and commitment is the real signal.",
+      "url": "https://www.momtestbook.com/",
+      "checked": "2026-10-27",
+      "informs": [
+        "field:validation-evidence.specificity",
+        "field:validation-evidence.kind",
+        "rule:evidence-grade"
+      ],
+      "stance": {
+        "is": "adopted",
+        "why": "Its ranking of signals (commitment over compliments, past facts over hypotheticals) sets the starting grades and the specificity downgrade; its method is the problem-interview template."
+      }
+    },
+    {
+      "id": "cb-insights-2026-startup-failure",
+      "title": "The top 9 reasons startups fail",
+      "authors": [
+        "CB Insights"
+      ],
+      "year": 2026,
+      "kind": "article",
+      "summary": "Analysis of startup post-mortems; poor product-market fit was cited in 43% of failures (causes overlap).",
+      "url": "https://www.cbinsights.com/research/report/startup-failure-reasons-top/",
+      "checked": "2026-10-27",
+      "informs": [
+        "rule:validation-fails-closed"
+      ],
+      "stance": {
+        "is": "adopted",
+        "why": "The most common cause of failure is building what the market does not need, so a validation claim with no evidence grades very low instead of passing."
+      }
+    },
+    {
+      "id": "vohra-2018-superhuman-pmf-engine",
+      "title": "How Superhuman Built an Engine to Find Product Market Fit",
+      "authors": [
+        "Rahul Vohra"
+      ],
+      "year": 2018,
+      "kind": "article",
+      "summary": "Applies Sean Ellis's leading indicator: ask active users how they would feel if they could no longer use the product; 40% or more answering 'very disappointed' marks product-market fit. Segment the answers and work on the users who almost said very disappointed.",
+      "url": "https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit/",
+      "checked": "2026-10-27",
+      "informs": [
+        "field:validation-product-market-fit.ellis",
+        "rule:ellis-share"
+      ],
+      "stance": {
+        "is": "adopted",
+        "why": "The Ellis share is recorded as data and reported beside the grade; 40% is the usual bar."
+      }
+    },
+    {
+      "id": "van-westendorp-1976-price-sensitivity",
+      "title": "NSS Price Sensitivity Meter: a new approach to study consumer perception of prices",
+      "authors": [
+        "Peter H. van Westendorp"
+      ],
+      "year": 1976,
+      "kind": "paper",
+      "summary": "Four questions (too cheap, cheap, expensive, too expensive) give an acceptable price range from stated responses.",
+      "informs": [
+        "field:validation-pricing.points"
+      ],
+      "stance": {
+        "is": "adopted",
+        "why": "The pricing template uses its four questions; the answers are stated evidence and grade below real payments."
+      }
+    },
+    {
+      "id": "wasserman-2012-founders-dilemmas",
+      "title": "The Founder's Dilemmas",
+      "authors": [
+        "Noam Wasserman"
+      ],
+      "year": 2012,
+      "kind": "book",
+      "summary": "Evidence on founding teams: when to add cofounders, the costs of founding with friends and family, splitting roles and equity.",
+      "informs": [
+        "field:validation-team.cofounder_sought",
+        "field:validation-team.needed"
+      ],
+      "stance": {
+        "is": "adopted",
+        "why": "The team template asks which skills the coming phases need and which a cofounder should bring, before choosing people."
+      }
+    }
+  ]
+}

package/purpose/kits/validation/skills/problem-validation/SKILL.md

@@ -0,0 +1,43 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, purpose, validation, problem, evidence]
+ai-model: claude-opus-5.5
+created: 2026-10-27T20:21:00Z
+source: hybrid
+name: problem-validation
+description: >
+  Help a builder show that the problem their venture solves is real, with cited
+  evidence instead of a statement: who has it, how they cope today, what it
+  costs them, and what the evidence is strong enough for (explore, prototype,
+  charge, raise), with no single score and never a "not viable" verdict.
+  Writes purpose/validation/problem.json; schema/assess-problem.mjs assesses it
+  after asking the person to fill in what is missing or run as is (EE-026, EE-050).
+  MANDATORY TRIGGERS: problem validation, validate the problem, is this a real
+  problem, customer discovery, problem interview, Mom Test, pain point,
+  evidence for the problem, market research for the problem, problem-solution fit.
+---
+
+# Problem validation
+
+Purpose layer, validation kit (EE-026, EE-050). Writes `purpose/validation/problem.json`; `node schema/assess-problem.mjs <venture dir>` (route `purpose/validation/assess`) says what its evidence is strong enough for. The behaviors it keeps are in `features/problem-assessment.feature`.
+
+## The rule: no verdict from missing evidence
+
+There is no score and no "not viable". The problem splits into four assumptions (it exists, our segment has it, it hurts enough that people already spend on it, why now), and each gets a label from its evidence: demonstrated, inferred, assumed, unknown or contradicted. The labels say which commitment the evidence supports: explore, prototype, charge or raise. Missing evidence is unknown, never a verdict against the idea. Competitors with paying customers count for the problem. Only first-hand behavior or commitment from five or more people in the segment demonstrates; anything reported (a vendor's customer count, a report) infers. Contradicted needs evidence against from the segment at least as strong as the evidence for.
+
+## Steps
+
+1. **Run the assessment first.** When the record is missing or incomplete it does not assess; it lists what is missing and what running as is would mean. **Show the person that list and ask whether to fill it in or run as is.** Never choose for them: pass `as_is` (CLI `--as-is`, MCP and API `as_is: true`) only after they chose it.
+2. **Fill in** what they chose to fill: `statement`, `segment`, `cost` or `workarounds`, `why_now`, and for each evidence item the `assumption` it bears on. Use `templates/problem.md`.
+3. **Find the cheapest evidence for the blocking assumption.** The result names it and a test. Competitors and desk research are quick and infer; interviews with five or more people in the segment (`templates/problem-interview.md`) and workarounds they already pay for can demonstrate. Save notes in the venture folder, so items are first-hand.
+4. **Record evidence against as well** (`supports: false`).
+5. **Run again** and tell the person what the evidence now supports and the next test, in those words.
+
+## When to stop
+
+When the evidence supports the commitment the founder is about to make. Prototyping needs the problem and its cost inferred; charging needs the segment and the cost demonstrated. Don't research past the next commitment.
+
+## Guardrails
+
+- Never invent evidence or fill a source with a plausible URL. A missing source is an open question.
+- Interview notes may hold personal data. Keep names out of the notes, or keep the notes out of any public repository.