tech-route-comparison

Evidence-backed comparison of two or more technical routes, architectures, or solution paths. Use when the user asks for technical pre-research, technical route comparison, route selection, TRL assessment, maturity assessment, readiness evaluation, opportunity mapping, or any management-grade technical report deliverable — even if they only ask for initiation analysis, committee-ready materials, feasibility, or "which route is better".

yuanzhian-patsnap@yuanzhian-patsnap

Install

openclaw skills install @yuanzhian-patsnap/tech-route-comparison

Tech Route Comparison

Provided by Patsnap Eureka.

Use this skill when the decision object is a route set rather than a company, a market arena, or a concrete proposal package. The goal is to compare routes on evidence, normalize the comparison basis, and end with a recommendation the user can act on.

Use When

The user asks which technical route is better, more mature, or lower risk
Route comparison across two or more technical approaches
Maturity, readiness, feasibility, or TRL evaluation
Scenario-specific route recommendation (e.g., "which route for EV use?")
Opportunity map or white-space scan across routes
Management-ready technical pre-research report

Do Not Use

The real question is one company in one topic → route to company-tech-profile
The real question is a multi-player arena or player map → route to competitive-landscape
The real question is a concrete proposal or initiation package → route to rd-initiation-review
The task is pure market sizing or commercial comparison with no technical core
Legal patent opinion, FTO, or infringement analysis

Modes

Mode	When To Use	Focus
`overview`	Broad technical landscape for a topic	Route inventory, frontier scan, ecosystem structure
`compare`	Direct comparison of named routes	Head-to-head comparison matrix, ranking, recommendation
`maturity`	Readiness or TRL assessment	Maturity rubric, stage gates, deployment evidence
`opportunity`	White-space or opportunity scan	Gap analysis, emerging routes, entry paths

Default mode: compare when routes are named, overview when only a topic is given.

Core Principles

Scope Freeze Before Retrieval

Freeze these parameters before wide retrieval to prevent evidence drift:

topic: the technology domain
decision_question: what the user needs to decide
decision_use: directional route scan / go-no-go / diligence-grade
application_scenario: the specific use case or context (e.g., EV battery, data center cooling, edge inference)
comparison_level: material-level / component-level / system-level
known_routes: user-provided or discovered route set
time_window: default last 3-5 years

Comparison Basis Must Be Explicit

Before ranking routes, write down:

What routes are being compared (frozen definitions)
What dimensions are used for comparison (performance, cost, maturity, risk, scalability, etc.)
What normalization rules apply (same application scenario, same comparison level, same time window)

Do not compare shifting route buckets. Do not mix material-level evidence with system-level evidence as if they were the same layer.

TRL And Maturity Require Explicit Rubric

Do not write TRL labels, readiness levels, or maturity claims without an explicit rubric that defines what each level means in the current context. A route with many weak signals is still weak — do not confuse volume with confidence.

Counterevidence Is Required

For every route recommendation, actively search for and document:

Evidence that contradicts the recommendation
Conditions under which the recommendation would change
Update triggers that should prompt re-evaluation

Tool Routing And Fallback

This skill works across multiple tool environments. Before retrieval, detect which capabilities are available and select the highest tier that is reachable.

Tier 1 (Recommended): Structured Patent/Paper Retrieval

Use the host's best structured patent and paper retrieval stack.
This usually means fielded patent/paper search plus record-level deep fetch.
Evidence grade: S/A
Required capabilities: per-route search, keyword or semantic route discovery, and deep-read of shortlisted records.

Tier 2 (Fallback): Web Research + Scholarly Companion Lane

Use the host's best broad web research tool plus a scholarly companion lane when available.
Exa, Tavily, Brave, and domain-specific scholarly databases are good examples, not hard requirements.
Evidence grade: A/B
Coverage loss vs Tier 1: route breadth and patent-structure claims are less precise.

Tier 3 (Fallback): Generic Web Search And Page Reading

Use generic web search and page/PDF reading tools available in the host.
Evidence grade: B/C

Tier 4 (Minimum): User Materials + Reasoned Synthesis

No external tools required
Evidence grade: C/U

Routing Rules

Detect available capabilities at the start of the workflow.
Select the highest available tier as the primary retrieval channel.
When a tier is unavailable, explicitly state the downgrade.
If the tool stack is degraded, lower confidence on route breadth and frontier claims.

Minimum Working Files

Create or update these files in a writable run folder:

request.md
workplan.md
method_decisions.md
comparison_basis.md
query_log.csv
source_index.csv
claim_ledger.csv
report.md

Recommended subfolders are described in references/workflow.md.

Default Workflow

Step 0: Freeze Scope

Confirm or infer the following before any retrieval:

topic, decision_question, decision_use
mode (overview / compare / maturity / opportunity)
application_scenario, comparison_level
known_routes (user-provided or to be discovered)
time_window, audience, deliverable

If the user did not specify routes, proceed with route discovery in Step 1. If the user named routes, freeze them and proceed to Step 2.

If the topic is broad and not route-frozen yet, write a provisional route taxonomy into comparison_basis.md before retrieval starts.

Step 1: Build Route Taxonomy (When Routes Not Given)

Run 2-3 broad topic searches to discover candidate routes.
- Tier 1: structured patent/paper search around the topic
- Tier 2: targeted web research plus scholarly companion search
- Tier 3/4: generic web or user-provided materials
Extract candidate routes from patent IPC clusters, paper themes, and review articles.
Freeze the route set in comparison_basis.md before proceeding.
If the route set is still too fuzzy, stop and narrow it with the user instead of writing a superficial ranking.

Step 2: Freeze Comparison Basis

Write to comparison_basis.md:

Route definitions (what each route means, technically)
Comparison dimensions (performance, cost, maturity, risk, scalability, deployment readiness, etc.)
Normalization rules:
- Same application scenario for all routes
- Same comparison level (do not mix material-level with system-level)
- Same time window
Scoring approach (if maturity or TRL mode):
- Explicit rubric with level definitions
- Evidence requirements per level

Step 3: Retrieve Evidence Per Route

For each route independently:

Run 2-3 searches focused on the route's technical specifics.
- Tier 1: structured patent/paper search for the route
- Tier 2: targeted web research plus scholarly companion search
- Tier 3/4: generic web or user-provided materials
Collect evidence across dimensions:
- Patent activity and key technical approaches
- Paper frontier and recent breakthroughs
- Standards, specifications, and regulatory status
- Product deployments, benchmarks, and commercial signals
Deep-read 2-3 representative patents/papers per route for technical detail.
Record all searches in query_log.csv with per-route tagging.

Do not mix evidence across routes during collection. Keep per-route evidence buckets separate until the normalization step.

Step 4: Normalize And Compare

Build the comparison matrix: routes (rows) × dimensions (columns). Fill each cell with evidence-backed assessments.

Example format:

Dimension	Route A	Route B	Route C
Performance	High — [Patent: X] demonstrates Y	Moderate — lab-scale only	High — [Paper: Z] benchmark
Cost	High — mature supply chain	Unknown — no production data	Low — expensive precursors
Maturity (TRL)	TRL 7 — pilot production	TRL 4 — lab validation	TRL 5 — prototype
Risk	Low — well-understood failure modes	High — scaling unknowns	Moderate — IP concentration

Apply the scoring rubric (if maturity or TRL mode):
- Score each route per dimension using the explicit rubric
- Show the rubric alongside the scores
- Do not assign TRL or maturity labels without evidence
Run the counterevidence pass:
- For each route recommendation, search for contradicting evidence
- Document weakening conditions and update triggers
- If counterevidence is strong, adjust the recommendation
Separate every claim into:
- Verified fact: directly supported by patent, paper, or official source
- Evidence-backed inference: reasonable conclusion from multiple signals
- Open gap: insufficient evidence, state what is missing

Step 5: Synthesize And Draft

Write the report following the mode-appropriate output skeleton.

Output Skeletons

Overview Mode

Executive summary: topic landscape and main route families
Route taxonomy and definitions
Per-route profile cards (2-3 paragraphs each)
Frontier signals and emerging directions
Key evidence references

Compare Mode

Executive summary: which route is recommended and why
Scope and comparison basis (explicit)
Route-by-route profile cards
Comparison matrix (routes × dimensions)
Recommendation with conditions, tradeoffs, and update triggers
Counterevidence and weakening conditions
Key evidence references

Maturity Mode

Executive summary: maturity landscape and readiness gaps
Scope and maturity rubric (explicit)
Per-route maturity assessment with evidence
Maturity comparison matrix
Stage-gate or readiness roadmap
Risks and deployment blockers
Key evidence references

Opportunity Mode

Executive summary: where the opportunities are
Route landscape and current coverage
Gap analysis (sparse coverage + technical value + entry path)
Emerging routes and early signals
Recommended investigation priorities
Key evidence references

Every claim must cite its source type and identifier, e.g., [Patent: CN1234567B], [Paper: DOI or title], [Web: source name].

Completion Gates

All must pass before delivering the final answer:

Guardrails

Do not confuse volume with confidence. A route with many weak signals is still weak.
Do not let vendor or company marketing outrank patents, papers, standards, or directly inspectable technical evidence.
Do not turn raw patent or paper counts into maturity claims without dedup and scope caveats.
Do not write TRL, readiness, or maturity labels without an explicit rubric.
Do not compare material-level, component-level, and system-level evidence as if they were the same layer.
Do not force a strong conclusion when the user only gave a broad topic and the evidence base is thin.
Do not skip the counterevidence pass — every recommendation needs at least one documented weakening condition.
If paper or patent coverage is inadequate for a route, say so explicitly before making strength claims.
Do not present a route ranking as definitive when the comparison basis is incomplete or the scoring rubric is missing.
Keep the recommendation tied to the stated scenario — a route that is best for one application may not be best for another.