English | 简体中文

Askovo

Bring a product or market question, get back a business plan — built on collected data, not invented judgments.

Askovo is built for product managers, user researchers, and business analysts. The default run: ① frame the question as a seven-node hypothesis canvas, ② design the data-collection plan (platforms, queries, quotas), ③ collect a large corpus through permitted routes, ④ turn the data into scene/user/pain/need/feature/product/GTM judgments, ⑤ render the Business Plan (askovo deliver --kind plan) — every judgment showing its data basis (sources, corpus size, time window) and user voices from the corpus, in business language. MRD/PRD/BRD and the Decision Package remain projections of the same chain for analyst and decision-side readers.

CLI, Skill, and MCP surfaces are live today. The host agent can author the action list, or askovo loop derives rounds from audit gaps inside an authorized envelope; the executor runs only what was authorized. Source gaps and human semantic review are kept explicit, never hidden. See capability status and trade-offs (Chinese).

scene → user → pain → need → feature → product → business

Data collection, descriptive analysis, interviews, experiments, evidence grading, and platform connectors are supporting steps only: they validate a node or an inference edge — they never substitute for the product and business reasoning itself.

Quality is enforced under the hood: every conclusion carries an internal evidence grade, and when a conclusion outruns its evidence, askovo audit says so outright (exit code 1 can gate CI). In business-facing deliverables those grades stay in the method archive — the narrative is the business logic itself, with "no collected data yet" flags where a judgment still waits for data.

Website · Quickstart · Product & business reasoning chain · Role methodology · Platforms & connectors

Proof it works in 30 seconds

pipx install askovo
askovo do "home security camera false alerts at night, want to validate the prototype" --domain hardware --dry-run
askovo demo
askovo decision --help   # versioned decisions, safe-hold adversarial revisions and replay

No pipx? Use a virtualenv and the same published PyPI package:

python3 -m venv .venv && .venv/bin/pip install askovo
.venv/bin/askovo demo

You can also route directly: askovo "SaaS subscription churn is dropping, want to know why users don't renew" --dry-run. --dry-run only routes and writes nothing; demo runs the built-in synthetic sample. Router keyword tables are Chinese-first — English queries work, and --domain pins the product type whenever English keywords don't match.

Language note: CLI output is Chinese today; docs/ are Chinese too. The command surface, JSON output and audit exit codes are language-independent, so it is usable from an English workflow, but the rendered text will not be English. English localisation is not scheduled yet.

Expected key results: status: pass, supported: 1, overclaims: 0. This only proves that the synthetic sample is self-consistent in structure, chain, and evidence references. It proves nothing about real demand, product quality, market size, or release readiness.

From research question to decision result: what a full delivery looks like

Feed in a product question, get back a Business Plan — target scenes, personas, pains, demands, a feature map, a product form, and a GTM path, each judgment with its evidence-strength marker (● 已观察到 / ◐ 有线索 / ○ 假设， computed from cited records), data basis and user voices from the corpus. Using the built-in synthetic sample (examples/sample-study):

askovo chain examples/sample-study
askovo deliver examples/sample-study --kind plan   # → 06-report/plan.md (business language)

The plan reads like a business document: "## 2. 目标场景：哪些场景值得做", "## 4. 痛点：现在怎么办、痛在哪", "## 8. 商业与 GTM：怎么走向市场" — with evidence-strength markers ● 已观察到 / ◐ 有线索 / ○ 假设, 数据基础（sources · corpus size · time window）and 来自语料的声音（verbatim user quotes）under each judgment, and "暂无采集数据" flagged honestly where a judgment has no data yet. Evidence codes and raw statuses live in the method archive at the end, not in the narrative.

When the reader is the decision maker rather than a business reader, the Decision Package renders the same chain decision-side — every judgment traceable to its evidence and counter-evidence:

Research question: for remote pet owners, is it worth running a two-week phone-based check-in pilot for "pet watch while away from home"?

Once the chain is complete (all seven nodes validated, 2 counter-evidence items on record), one command produces the decision package:

askovo deliver examples/sample-study --kind decision   # → 06-report/decision-package.md

The decision package gives the decision maker five views:

Sample decision memo (excerpt, from the synthetic sample): prioritization method — "test privacy, acceptance and retained use before any scale decision"; rationale — "the smallest test that can reverse the concept; no market-size ranking is claimed"; confidence bounds — counter-evidence R05/R07, gaps include "Privacy controls are not tested in real homes"; three states — delivery unplanned / outcome observing / causality not-claimed. decided is only a record of choice, not release or commercial proof — the three states are independent and must not be inferred from one another.

The Business Plan, MRD/PRD/BRD, and the Decision Package are not separate sets of conclusions — they are business-user, market/requirements/business, and decision-side projections of the same chain.

The three recurring tasks all run the same chain and differ only in what they deliver: discover (product question → Business Plan, with the Decision Package as the decision-side deep-dive), validate (review a hypothesis → Validation Backlog), decide (compare candidates → Decision Memo).

Versioned and adversarial DecisionRecords

askovo decision records and replays decisions inside the canonical 04-findings/product-reasoning.json — not a second decision-truth file:

askovo decision record ./study --chain PR01 --by "product-owner" \
  --decision "Support the current bounded opportunity"
# Prerequisite: R08 is registered, same-context, has provenance, and already has
# a contradicts/counter-evidence mapping. No replacement recommendation is required.
askovo decision record ./study --chain PR01 --by "product-owner" --contradiction R08
askovo decision replay ./study --chain PR01

The second record deterministically applies hold, reopens the chain/product/business for validation, lowers confidence one ordinal step, and preserves before/after recommendations, evidence relations and snapshots. --recommendation "..." is an optional human override; the system does not invent a replacement product. An ID without a recorded contradiction relation is rejected. Newly mapped evidence is not promoted into a validated judgment or causal proof.

One chain, 80 role families, 10 industry contexts, five base research packs

Askovo now includes an executable product-innovation role operating system, not just a job-title list. It covers 80 role families across opportunity research, user/needs research, product strategy, concept/service design, digital experience, physical engineering, consumer-product development, validation, lifecycle delivery, and ResearchOps/DesignOps. Every role defines its mission, responsibilities, KPI formulas and guardrails, input→action→output→gate SOPs, core deliverables, working templates, handoffs, and human accountabilities. Ten industry overlays adapt the work from consumer software and SaaS to AI, smart/traditional hardware, CPG, apparel/home, industrial robotics, automotive, and medical/health products.

askovo roles list --json
askovo roles show R52 --industry ai_native
askovo roles recommend "AI photography app concept" --stage concept --task design
askovo roles recommend "warehouse robot process and ROI" --task decide --scale lean
askovo roles scaffold ./study --role R29 --role R52 --role R72
askovo roles template R52 --output agent-interaction-spec.md
askovo deliver ./study --kind role --role R52  # canonical read-only role projection
askovo deliver ./study --kind lifecycle        # 10-module role/workflow board

do and route recommend a task-sized team, not all 80 roles. Askovo classifies the work as decide/discover/define/design/validate/launch/operate/review, selects the minimum sufficient roles, lists deferred roles and reasons, and builds an output contract that sets the primary deliverable, format, length, audience, section structure, evidence display and industry-specific expression. A software decision may need 1–3 roles; hardware validation or regulated work can expand to cross-functional review. After the canonical chain is confirmed, roles scaffold atomically creates 01-sources/role-workbench/ with the task/output contract, RACI, bound chain/node targets, SOP quality gates, null KPI targets and only this task's primary/supporting templates (multi-chain studies require --chain; --all-templates explicitly expands). These are orchestration artifacts only: they never create a second product/market/requirements/business truth or turn SOP completion into demand validation, engineering approval, clinical/safety/compliance sign-off, production readiness, or causal proof. See Role operating system (Chinese) and the Agent role protocol.

The five SURE base-domain packs still own method routing. The ten industry overlays change professional context without forking the seven-node schema. The following chain projections remain available for their specific readers:

A small team can wear several hats, but the workflows and outputs must not be conflated:

All five domains share one chain schema — no per-domain forking. Domain packs only change methods, evidence forms, risk gates, and acceptance focus. Current first focus: AI software, developer tools, and smart hardware (the five-domain methodology stays compatible):

How it works

1. Build the product and business reasoning first; decide what to research second

askovo do "SaaS subscription churn is dropping, want to know why users don't renew"
askovo chain ./askovo-software-postlaunch

do detects domain, lifecycle stage, intent, and risks, then creates the chain canvas. chain renders the same machine truth:

04-findings/product-reasoning.json   seven nodes, inferences, assumptions, counter-evidence, decision states
06-report/product-reasoning.md       human-readable projection

Every node must carry:

• statement: the current judgment;
• rationale: why the previous node licenses this one;
• assumptions: what must also hold for the inference to stand;
• evidence_ids: which registered evidence supports it;
• status: hypothesis / needs-validation / validated / rejected / deprioritized.

Feature nodes also record alternatives and acceptance criteria; the product node records form factor, scope, non-goals, and acceptance; the business node records market boundaries, segments, payers, competitive positioning, channels, pricing, cost, market-sizing conventions, unit economics, success metrics, and business gates. A chain's decided only means the current product/business choice was recorded — it is not semantic review, engineering verification, release approval, commercial validity, or causal effect.

2. Find the weakest node; backfill it with research

askovo check ./study --stage design
askovo platforms "home security camera night-alert complaints" --domain hardware --bulk
askovo instruments ./study
askovo collect ./study --platform reddit --query "night alert" --limit 100
askovo analyze ./study --question "night false alerts"

source-plan.csv marks which chain node each route serves via reasoning_nodes, so you never collect just to pump volume. Real collection still requires the Design gate, source authorization, and adapter checks.

analyze only normalizes, deduplicates, computes distributions, frequent candidate terms, and question-matched snippets; it never auto-generates scene, need, feature, or product conclusions.

When the weakest node is not obvious, askovo loop derives the gap from the audit, plans one query per gap and eligible source, runs rounds inside an authorized envelope, and re-audits after each round. Collected records stay review candidates — the loop never assigns an evidence level or edits a judgment.

askovo loop plan ./study
askovo loop authorize ./study --by "researcher"
askovo loop run ./study
askovo loop report ./study

For writing/decision gaps with existing local JSONL, analyze is an executable offline candidate: it reuses the descriptive analyzer and writes an execution record and follow-up review state without promoting candidates. Collection retains its authorization and Design gate; experiments and external-evidence requests are not auto-run. stop is separate from positive action scoring: an explicit three-condition StopDecision can rank it first only when more research cannot change the decision and is not worth its cost/risk; otherwise stopping for its own sake is not allowed.

3. Audit both "is the evidence enough" and "is the reasoning broken"

askovo check ./study --stage full --write-report
askovo audit ./study --json
askovo review ./study                 # decision review: readiness, falsifiability, bias, deliverable freshness

Two files, two owners:

• product-reasoning.json: owns the seven-node product semantics and inference rationales;
• demand-judgments.json: owns the evidence-eligibility judgments for demand, solutions, commercial behavior, and counter-evidence.

They join on demand_judgment_id + context_key. Evidence cited by a node must already be registered in the linked demand judgment — you cannot bypass the E1/E2, E3, E4+/E5, counter-evidence, and context gates by editing the chain file. The pain → need edge has a hard floor: a need node can only reach validated with at least one piece of E2 evidence (observed substitution, workaround, or failure behavior); E1 verbal statements alone cap it at needs-validation — saying is not doing.

A complete chain still does not prove product/business success; complete evidence cannot compensate for a missing inference rationale. Automated checks validate structure and configuration only — key semantics, market sizing, and unit economics stay with human and professional review.

4. Project the same chain into role-specific deliverables

askovo deliver ./study --kind plan    # business plan (business-user default): conclusions + nine sections + data basis + user voices
askovo deliver ./study --kind analysis # corpus analysis: funnel, source/year/role distribution, node coverage, counter-evidence
askovo deliver ./study --kind decision # decision package: opportunity map / evidence graph / options & trade-offs / decision memo / validation backlog
askovo deliver ./study --kind report   # combined product & business reasoning report
askovo deliver ./study --kind mrd      # market research & analysis → MRD
askovo deliver ./study --kind prd      # requirements research & analysis → PRD
askovo deliver ./study --kind brd      # business analysis → BRD
askovo deliver ./study --kind memo     # product decision memo
askovo boundary ./study --requirements req.md --output ai-prd.md  # F2 boundary audit: Added/Missing/Inflated candidates
askovo cost ./study log --task "audit PRD" --minutes 25           # F4 logged human minutes (optional no-tool baseline)
askovo deliver ./study --kind signoff   # F3 stakeholder sign-off page: conclusions + evidence levels + boundaries + signature block
askovo deliver ./study --kind ops      # user-ops projection
askovo deliver ./study --kind tracker  # behavior, acceptance, and business metric tracking
askovo report ./study                  # research status: 06-report/research-status.md

deliver --kind report is the single writer of the combined product/business report; askovo report writes a separate research-status file. The business plan, decision package, MRD, PRD, BRD, and ops views are all projections of one seven-node chain — not parallel sources of truth.

With multiple candidate chains, the plan opens with a cross-chain decision table and one conclusion block per chain, then renders the detailed sections once for the priority chain; --kind report fills its product-decision section with the same chain states instead of leaving placeholders. When a study aggregates several collection waves, 01-sources/collection-summary.json supplies the funnel totals. Business strength (●◐○) is node-aware: the commercial node only counts E4+/E5, so counter-evidence cannot make it look observed.

Askovo and SURE

Askovo is the product; SURE is the research and evidence engine underneath.

• Askovo: the chain workspace, five-domain routing, CLI/Skill/MCP, collection, analysis, and role deliverables.
• SURE (Structured User Research with Evidence): method selection, evidence forms and levels, claim boundaries, anti-survivorship bias, safety gates, and judgment constraints.
• All three surfaces share sure_engine.py and the CLI command functions — behavior never forks.

In one line: Askovo handles "reasoning from users to product and business"; SURE makes sure "every step knows how far its evidence actually reaches".

Post-launch growth is handled by Growovo: it consumes askovo's research judgments for positioning and growth (position → build → run), and first-party growth feedback flows back with the same E0–E5 grading — upstream and downstream exchange evidence instead of duplicating research.

Research support capabilities

Method routing

askovo route "how to validate the takeover experience of automotive cockpit voice" --domain automotive --json
askovo methods --domain automotive --stage validation

Automotive routes to clinics, simulators, closed courses, road, or naturalistic driving; consumer goods route to CLT/HUT/repurchase; software routes to usability, beta, A/B, and cohorts.

Platform radar

askovo platforms "home security camera night-alert complaints" --domain hardware --bulk

Answers "where is the data, can it be obtained compliantly, which reasoning node does it help, and what can it not prove". Platform verdicts come as supported, limited, or blocked; where no compliant bulk channel exists, only authorized exports, research APIs, or compliant historical datasets are accepted.

Collection, queues, and reproducibility

• GitHub goes through the official Search API; Reddit through the official Data API; everything else uses authorized exports, historical datasets, or local fixtures.
• Every collection run stores raw envelopes, normalized records, and a manifest recording access basis, rights, counts, discard reasons, restrictions, and bias.
• A SQLite queue supports multiple workers, lease recovery, failure backoff, rate limits, and resumable runs.
• CDP is limited to authorized visible pages on amazon / instagram / bilibili / weibo; X / YouTube and blocked platforms never use it, and captchas, login walls, and platform controls are never bypassed.

See Platforms & connectors and the CLI reference (Chinese).

Six finding types that must not be conflated

E0–E5 grade demand and commercial evidence strength only — they are not a product/business reasoning score. Usability, engineering performance, safety, feasibility, business gates, and release gates each carry their own verification requirements.

Boundaries

• No unauthorized scraping; blocked connectors, login walls, captchas, and platform challenges are never bypassed.
• Platform availability is never treated as sample-represents-population; record counts are never treated as user counts or audience size.
• Feature-mention frequency is not need; purchase intent is not purchase; adoption rate is not product outcome.
• One-time liking is not repurchase; beta, zero complaints, or zero incidents are not safety or release readiness.
• Demand evidence never substitutes for usability, performance, safety, engineering V&V, regulatory, or certification evidence.
• High-risk research stops at S0: the agent may only propose a plan, never instruct execution.
• All deliverables are drafts by default; a passing CLI run never replaces human semantic review, product sign-off, or risk acceptance.

Installation

Askovo is published on PyPI. Install the released package with pipx:

pipx install askovo
askovo --version
askovo decision --help

Or with venv:

python3 -m venv .venv
.venv/bin/pip install -U pip
.venv/bin/pip install askovo
.venv/bin/askovo demo

For source development inside a checkout, use pip install -e . instead.

The core CLI, Skill, and MCP use only the Python standard library and support Python 3.9–3.12. The optional Workbook XLSX and Amazon HF tools declare openpyxl/datasets separately.

Agent Skill

bash scripts/install-skill.sh
bash scripts/install-skill.sh ~/.codex/skills

MCP

{
  "mcpServers": {
    "askovo": {
      "command": "askovo",
      "args": ["mcp"]
    }
  }
}

MCP exposes askovo_route, askovo_do, askovo_chain, askovo_platforms, askovo_collect, askovo_analyze, askovo_audit, askovo_decision, askovo_deliver, and more, sharing behavior with the CLI; collect defaults to dry-run.

Services & support

The engine is free and open source forever: the CLI, Agent Skill, MCP, and the five base domain packs are all MIT, with no feature-crippled edition. The only paid things may be deep domain assets and human delivery — never the engine itself.

Human delivery has no published price list: email tongroy18@gmail.com describing the task (domain, decision question, dates, existing materials, who owns the decision); if it fits, you get a written quote and work starts after confirmation — see the engagement page. Commercial delivery follows the same discipline as the open-source engine: conclusions never outrun the evidence, and semantic review and product sign-off belong to the decision maker. Free support goes through GitHub Issues; no SLA is promised.

Documentation

Docs under docs/ are Chinese for now; this README and llms.txt are the English entry points.

Agent entry points: llms.txt · AGENTS.md · SKILL.md.

Repository layout

skills/askovo/
  SKILL.md                     single-entry protocol and judgment rules
  assets/domain-packs/         five product research packs (never change the chain)
  assets/study-template/       workspace template including product-reasoning
  references/                  research, chain, data, and connector protocols
  templates/                   MRD/PRD/BRD and interview support templates
  scripts/askovo.py            deterministic CLI (single source of behavior)
  scripts/sure_engine.py       SURE support engine and chain scaffolding
  scripts/askovo_mcp.py        MCP shell
docs/                          Chinese product & methodology docs
examples/sample-study/         offline synthetic sample with a complete chain
tests/                         CLI, chain, routing, platforms, queue, MCP tests

Participating & releasing: Contributing · Security policy · Release process · Code of conduct. If Askovo helps you, a star helps more people find it — entirely voluntary, no strings attached.

License

MIT. Third-party components and data-rights boundaries: see LICENSE and docs/connectors.md.

Local document intake (optional Docling adapter)

Study a PDF or Office file without copying it into the chat. This local, opt-in extraction turns a file into Markdown with a SHA-256 provenance sidecar. It does not claim to validate the document, source permission, or any business conclusion.

# Python 3.10+ for current Docling; Askovo's base installation remains dependency-free
pip install docling
askovo document ./research-report.pdf --out ./report-extracted.md
# Read provenance and check source rights before treating its text as evidence.
askovo import ./my-study ./report-extracted.md --source-family imported
askovo audit ./my-study

Plain UTF-8 .txt / .md work without Docling. The resulting .provenance.json records the original file hash and marks the extraction unreviewed. It does not make unsupported public-platform scraping permissible. See feature status.