{"id":53807,"plugin_id":"plugins_6ac5e934d1f88191b73fe472c16744ae","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T13:55:10.001Z","digest":"8da21f5757a40fb9b1c8e4f43ea102bd041ae8001991d5b8e1b3e60df5da1f4f","against":null,"payload":{"description":"Evaluate an offer or business-model hypothesis against delivery constraints, sourced cost and pricing assumptions, and ethical low-risk experiments before making downstream promises.","included_files":[],"name":"business-feasibility-validation","skill_md_contents":"---\nname: business-feasibility-validation\ndescription: Evaluate an offer or business-model hypothesis against delivery constraints, sourced cost and pricing assumptions, and ethical low-risk experiments before making downstream promises.\n---\n# Business Feasibility Validation\n\nUse this universal workflow when a user wants to test whether a proposed offer or business model can be delivered and supported by plausible economics. It applies to services, products, subscriptions, marketplaces, and other business models. It is a planning and evidence workflow; it cannot certify that a business is viable, safe, lawful, or ready to launch.\n\n## Boundaries and routing\n\n- Separate **customer desirability** (does a defined customer have this problem and want a solution?), **delivery feasibility** (can this operator provide it to the proposed scope and standard?), and **economic viability** (do sourced costs, prices, capacity, and other constraints leave a plausible model?). Evidence for one does not prove the others.\n- Route market, category, and competitor questions to `market-research`; route primary customer discovery or synthesis of real evidence to `customer-discovery`. Use their outputs with provenance intact.\n- A spreadsheet calculation demonstrates what follows from its inputs; it does not validate those inputs, customer demand, willingness to pay, or business viability.\n- Identify the minimum missing input and ask one focused question at a time. Reuse existing context, challenge material assumptions, and state when a decision cannot yet be assessed.\n- Do not invent cost, price, demand, conversion, capacity, or financial figures. If the user requests an illustration without inputs, use variables or a clearly labeled fictional example and never present it as a forecast or finding.\n\n## Workflow\n\n### 1. Frame the hypothesis and decision\n\nCapture the proposed customer and problem, offer scope, delivery method, business model, geography or operating context when relevant, and the decision the user needs to make. Record each material statement as CONFIRMED (within its evidence scope), USER-REPORTED, HYPOTHESIS, ASSUMPTION, EXAMPLE / SYNTHETIC, or UNKNOWN. Identify what would change the decision and what evidence would weaken the preferred model.\n\nDo not turn a broad business idea into a detailed operating model without the user's input. Make provisional choices explicit and easy to revise.\n\n### 2. Map delivery constraints\n\nDescribe the actual work required from first customer contact through delivery, support, exception handling, and completion. For each step, record:\n\n- Required skills, people, time, equipment, facilities, inventory, suppliers, software, capital, and dependencies.\n- Who owns the task, what capacity is available, when and where it can happen, and what limits volume or quality.\n- Customer eligibility, access, fulfillment boundaries, cancellations, defects, complaints, refunds, maintenance, and escalation or referral needs.\n- Which requirements are known, sourced, user-reported, assumed, or unresolved.\n\nFlag delivery dependencies that require licensed professionals, current jurisdiction-specific research, inspection, engineering, clinical judgment, safety review, or other qualified advice. Research official requirements when tools are available, cite the relevant jurisdiction and date, and do not make legal or specialist determinations. A plan on paper is not proof of staffing, capacity, competence, safety, or readiness.\n\n### 3. Build a transparent cost and capacity worksheet\n\nUse only inputs supplied by the user, documented first-party records, or appropriately sourced research. Record source/provenance, date, geography, unit, period, and confidence for each input. Keep unknown inputs blank or symbolic; never silently fill them with averages or plausible-sounding estimates.\n\nSeparate, where relevant:\n\n- One-time startup and setup costs.\n- Fixed costs per clearly named period.\n- Variable delivery costs per order, customer, hour, or other defined unit.\n- Labor and owner time, with the basis stated; do not treat unpaid founder labor as costless without flagging that assumption.\n- Capacity and utilization constraints, including the denominator and time period.\n- Exclusions and unresolved costs, such as taxes, financing, returns, payment fees, rework, support, or compliance expenses.\n\nShow formulas and units. For example, if supported inputs exist: contribution per unit = selling price per unit − variable cost per unit; simple break-even units per period = fixed costs per same period ÷ positive contribution per unit. State assumptions and exclusions. If contribution is zero or negative, the simple break-even formula does not yield a meaningful positive sales target. These calculations are scenarios, not forecasts; do not imply that all demand can be fulfilled or that accounting, tax, or financing treatment has been determined.\n\nWhen uncertainty is material, show a small sensitivity table using user-provided or sourced low/base/high inputs, label every scenario and avoid false precision. If inputs are missing, show the variables needed instead of manufacturing scenarios.\n\n### 4. Review pricing evidence\n\nDistinguish price observations from price evidence:\n\n- Competitor list prices are scoped market observations, not proof of equivalent scope, customer value, profitability, or willingness to pay.\n- Survey answers, stated interest, and hypothetical purchase intent are weaker than observed behavior and are not purchases.\n- Actual purchases or paid pilots are stronger behavioral evidence only for the tested offer, sample, price, time, and conditions; they do not automatically generalize.\n- A proposed price is an ASSUMPTION until supported. Keep customer price evidence separate from the provider's cost floor and commercial judgment.\n\nResearch current competitor prices only when relevant and available; cite source, date, geography, inclusions, and limitations. Do not infer a recommended price from a competitor average or a thin sample. For consequential pricing, financing, tax, or regulated offers, flag qualified professional review as needed.\n\n### 5. Design a low-risk experiment\n\nChoose the smallest ethical test that resolves the highest-impact uncertainty. Write down before running it:\n\n1. The specific hypothesis and the evidence that would support or weaken it.\n2. The participant/customer segment and recruitment source; do not imply a sample is representative without evidence.\n3. The method, exact offer or concept shown, and what will remain unavailable or hypothetical.\n4. A time, cost, and operational cap; owner; privacy/consent approach; and stop conditions.\n5. A measurable success threshold and failure/ambiguous-result rule set before collecting results.\n6. The metric, denominator, observation period, evidence storage/provenance, and interpretation limits.\n\nUse an experiment ladder appropriate to risk: secondary research; neutral discovery conversations; concept comprehension or prototype feedback; transparent interest/opt-in measurement; then a bounded manual pilot only if real delivery capability is in place. A real paid test is appropriate only when the offer can actually be fulfilled and disclosures, permissions, and applicable professional requirements have been addressed. Do not use fake availability, fake bookings, deceptive scarcity, fabricated testimonials, undisclosed pre-sales, or collect personal data without a clear purpose and permission. Do not let an experiment expose customers or staff to unreviewed safety, legal, or financial risks.\n\nWhen using discovery interviews, test the problem and current alternatives before pitching a solution. Treat courtesy, stated enthusiasm, email sign-ups, and clicks as signals with specific limits, not proof of demand or willingness to pay.\n\n### 6. Read results and make a bounded decision\n\nCompare observed results with the pre-set criteria. Preserve raw counts and denominators supplied or calculated from records; do not extrapolate beyond the sample. Report contrary cases, missing data, deviations from the protocol, and alternative explanations. Keep a planned experiment distinct from one actually run; never claim the AIOS performed it.\n\nUse a bounded recommendation such as **READY FOR THIS LIMITED TEST**, **REVISE BEFORE TESTING**, **NOT READY / KEY INPUTS UNKNOWN**, or **STOP OR RECONSIDER THIS MODEL**. Explain the evidence and conditions behind the recommendation. A passed experiment advances only the tested assumption; it does not alone prove market-wide demand, repeat purchase, profit, product-market fit, legal compliance, or launch readiness. Leave final business choices to the user without presenting unsupported claims as facts.\n\n## Standard output\n\nProvide a concise feasibility brief containing the decision and scope; offer/model hypothesis and evidence ledger; delivery map and constraints; cost/capacity worksheet with sources, formulas, exclusions, and unresolved inputs; pricing evidence and limits; one prioritized experiment card; result/readout if an experiment was actually run; and a bounded recommendation with the next evidence needed.\n\n## Candid partnership and research standard\n\nBe a candid strategic partner, not an echo chamber or cheerleader. Do not agree or praise merely to please. Challenge material assumptions, weak reasoning, gaps, contradictions, and meaningful risks; explain why they matter and offer a better-supported alternative when possible. Agree when the reasoning and evidence support it; do not invent objections or debate subjective preferences as facts.\n\nFor material business, customer, market, competitor, demand, pricing, performance, platform, regulatory, or feasibility claims, make relevant research and evidence the primary basis. Prefer direct/first-party evidence and current authoritative sources appropriate to the question; cite and scope sources, look for counterevidence, and state limitations. User or project preferences guide choices but do not prove factual claims. If evidence is missing or mixed, say so and keep the conclusion HYPOTHESIS or UNKNOWN. Purely creative work needs no unrelated research; factual claims in creative assets still need support.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}