Deepresearch

Deep Research Skill

Conduct rigorous, multi-part research on a complex topic producing a report grounded entirely in confirmed sources. No design assumptions before research is complete. All claims backed by source links.

Skill Files

This skill is split across files — read the relevant ones before proceeding:

---

Step 1: Detect Mode

Determine research mode from the query before reading any template:

---

Step 2: Read the Template

After detecting mode, read the appropriate template file in full before writing the research plan or launching agents. The template files contain:

• The 5-part structure for that mode
• Per-part research questions and source guidance
• Agent prompt scaffolding
• Lessons learned specific to that mode

---

Step 3: Execute

Follow the execution steps in the template. The core workflow is the same for all modes:

1. Write RESEARCH_PLAN.md in a new {topic}_{YYYYMM}/ folder 2. Launch 5 parallel background agents (one per part) 3. Acknowledge each agent as it completes with a key findings summary 4. After all 5 complete: read all raw files, compile RESEARCH_REPORT.md 5. If HTML output requested: use report-template.html as the base

---

Universal Rules (apply to all modes)

Source quality

• Specs/products: Official vendor docs, press releases, spec sheets
• CVEs/security: NVD, MITRE, vendor advisories, Black Hat/DEF CON/USENIX papers
• Academic: arXiv, NeurIPS/ICLR/CVPR/ACL proceedings, OpenReview
• Market data: Gartner, IDC, Forrester, MarketsandMarkets, Crunchbase
• Regulatory: EUR-Lex, NIST, CISA, Federal Register, national AI laws
• Law/policy: official gazettes, government legal portals, regulator websites, ministry publications, court/tribunal decisions, official consultation papers
• Benchmarks: MLCommons/MLPerf, HuggingFace leaderboards, official vendor disclosures
• Do NOT cite: Wikipedia, unattributed blogs, secondary summaries

Agent instructions (every agent must)

1. Fetch and READ actual URLs — do not rely on training data alone 2. Note publication dates — distinguish confirmed vs. announced vs. speculative 3. Save raw output to {folder}/raw_research/XX_topic.md 4. Target 2,000+ words with real data, tables, and source URLs

File structure

{topic}_{YYYYMM}/
├── RESEARCH_PLAN.md
├── RESEARCH_REPORT.md
├── report.html            # optional, if HTML requested
└── raw_research/
    ├── 01_*.md
    ├── 02_*.md
    ├── 03_*.md
    ├── 04_*.md
    └── 05_*.md

Common errors to avoid

1. Wrong platform ID: Fetch the actual product website before writing the plan 2. Shallow agents: Anchor every agent with 3–5 specific URLs to fetch first 3. Premature design (security mode): Do not write Part 4 before Parts 1–3 are reviewed 4. Fixed dimensions (techtrend mode): Parts 2–4 are defined per-topic in the plan, not preset 5. Legal status confusion (law-policy mode): never mix binding law, proposed rules, regulator guidance, unofficial translations, and vendor summaries without labeling them 6. Blocked sources: Chinese sources behind auth walls — search for equivalent open-web sources 7. Context length: Raw research files can be 5,000–7,000 words each — read them carefully

---

Example Invocations

# Security (auto-detected)
/deepresearch security for personal AI endpoint agents including OpenClaw and Claude Code
/deepresearch supply chain attacks on npm packages
/deepresearch quantum-safe cryptography for financial services

# Tech trend (auto-detected)
/deepresearch endpoint LLM ecosystem — hardware, models, runtimes, applications
/deepresearch autonomous vehicle software stack trends and 2030 forecast
/deepresearch edge AI chip market landscape

# Law/policy (auto-detected)
/deepresearch data residency laws for financial SaaS in Singapore, Indonesia, and Malaysia
/deepresearch firewall log retention compliance requirements in Thailand and Turkiye
/deepresearch EU AI Act obligations for enterprise AI coding assistants

# With HTML output
/deepresearch endpoint LLM ecosystem output: html

Law & Policy Research Mode

Used when the topic involves laws, regulations, compliance obligations, regulator guidance, statutory requirements, retention periods, legal applicability, country comparisons, audit/recordkeeping rules, or vendor/product fit against policy requirements.

This mode is for rigorous policy research, not legal advice. Every legal conclusion must distinguish binding law from proposed rules, regulator guidance, standards, secondary interpretation, and implementation best practice.

---

5-Part Structure

Part 1: Legal Source Mapping

• Identify authoritative statutes, regulations, official gazettes, regulator guidance, ministry publications, consultation papers, and official standards.
• Establish legal status: binding law, implementing regulation, regulator guidance, draft/proposed rule, consultation paper, industry standard, or secondary summary.
• Note publication dates, effective dates, amendment history, current status, and whether translations are official.
• Prefer official sources; use law-firm or vendor summaries only as secondary support.

Part 2: Applicability & Covered Entities

• Determine who is regulated: ordinary enterprises, service providers, ISPs, hosting providers, cloud providers, public Wi-Fi operators, critical infrastructure, financial institutions, data controllers/processors, licensees, or electronic system operators.
• Identify trigger conditions: business role, sector, service type, user location, data type, incident, regulator notice, company size, or public availability.
• Separate clearly covered, conditionally covered, likely not covered, and unresolved/local-counsel-needed cases.
• Do not assume a company is covered just because it owns relevant technology.

Part 3: Obligation Extraction

• Extract concrete duties: record, retain, disclose, protect, delete, audit, report, notify, localize, encrypt, sign, timestamp, or preserve.
• Capture retention periods, required fields/content, formats, integrity controls, access controls, production deadlines, penalties, and exceptions.
• Distinguish continuous obligations from event-triggered, notice-triggered, incident-triggered, or sector-triggered obligations.
• For log/compliance topics, normalize requirements into retention period, required content, integrity, availability, privacy limits, and security controls.

Part 4: Comparative Analysis & Practical Interpretation

• Compare jurisdictions, sectors, or regimes in tables.
• Translate legal language into operational requirements while labeling certainty levels.
• Distinguish explicit legal obligations from practical evidence-chain requirements and best practices.
• Identify conflicts, especially retention vs. privacy/data minimization, local storage vs. cloud processing, and regulator access vs. confidentiality.
• Include capacity, cost, implementation, or process modeling when the user asks for operational planning.

Part 5: Vendor / Product / Operational Fit

• Evaluate whether relevant products, services, or architectures can satisfy the requirements.
• Use official product documentation first.
• Compare retention, export, archive, compression, integrity, timestamping, signing, audit trails, local/cloud storage, data residency, and country-specific support.
• Classify fit as native support, partial support, requires external system, unsupported, or unclear.
• Do not treat vendor "compliance" marketing as legal compliance unless mapped to specific requirements.

---

Research Plan Guidelines

Before writing RESEARCH_PLAN.md:

• Confirm the jurisdiction scope, subject matter, regulated activities, and entity types to test.
• Identify known regulators, ministries, legal portals, official gazettes, and standards bodies.
• Gather search terms in English and local languages.
• Confirm whether vendor/product fit, storage/cost modeling, implementation architecture, or legal-only analysis is in scope.
• If the user asks for a country comparison, define the comparison dimensions before launching agents.

RESEARCH_PLAN.md must include:

• Problem statement and jurisdiction scope.
• Regulated activities and entity types to test.
• Research questions per part.
• Known starting points: legal portals, regulator URLs, statute names, consultation papers, standards, vendor docs.
• Source-quality hierarchy and how unofficial translations will be labeled.
• Expected output tables: source table, applicability matrix, obligation table, retention table, required-fields table, vendor/solution matrix if relevant.
• "What NOT to assume before research" section.

---

Agent Prompt Scaffolding

Agent 1 — Legal Source Mapping

Research authoritative legal and policy sources for this topic.
Fetch and read official statutes, regulations, official gazettes, regulator pages, consultation papers, and official guidance.
Distinguish binding law, draft/proposed rules, regulator guidance, standards, and secondary summaries.
Starting URLs: [official legal portals/regulators from the plan]
Searches to perform: [local-language and English searches]
Save to: {folder}/raw_research/01_legal_source_mapping.md
Target: 2000+ words with source tables, dates, legal status, and URLs.

Agent 2 — Applicability & Covered Entities

Research who is covered and when the obligations apply.
Analyze entity types, sector scope, territorial scope, trigger conditions, exemptions, and edge cases.
Classify ordinary enterprises, service providers, public access providers, data controllers/processors, critical infrastructure, licensees, and other relevant entities.
Starting URLs: [statutes/regulator guidance from the plan]
Save to: {folder}/raw_research/02_applicability.md
Target: 2000+ words with applicability matrix and source URLs.

Agent 3 — Obligation Extraction

Extract concrete obligations from the applicable laws and policies.
Capture retention periods, required records/data fields, audit trail requirements, disclosure duties, security controls, integrity requirements, deletion limits, reporting deadlines, and penalties.
Quote or paraphrase article/section numbers and label legal certainty.
Starting URLs: [primary legal texts from the plan]
Save to: {folder}/raw_research/03_obligation_extraction.md
Target: 2000+ words with obligation tables and source URLs.

Agent 4 — Comparative & Practical Analysis

Build jurisdiction-by-jurisdiction or regime-by-regime comparison tables.
Interpret what the obligations mean in practice, separating mandatory requirements from recommended controls and operational evidence-chain needs.
Identify conflicts, ambiguities, privacy/minimization constraints, and implementation implications.
If relevant, include sizing/capacity/cost formulas and assumptions.
Save to: {folder}/raw_research/04_comparative_analysis.md
Target: 2000+ words with tables, assumptions, formulas if applicable, and source URLs.

Agent 5 — Vendor / Product / Operational Fit

Research whether relevant vendors, products, services, or architectures can satisfy the obligations.
Use official product documentation first.
Compare retention, export, archive, compression, integrity, timestamping, signing, audit, local/cloud storage, data residency, and country-specific support.
Classify fit as native support, partial support, requires external system, unsupported, or unclear.
Save to: {folder}/raw_research/05_vendor_operational_fit.md
Target: 2000+ words with vendor/solution matrix and source URLs.

---

Output Requirements

Use this file structure:

{topic}_{YYYYMM}/
├── RESEARCH_PLAN.md
├── RESEARCH_REPORT.md
├── report.html            # optional, if HTML requested
└── raw_research/
    ├── 01_legal_source_mapping.md
    ├── 02_applicability.md
    ├── 03_obligation_extraction.md
    ├── 04_comparative_analysis.md
    └── 05_vendor_operational_fit.md

The final report should include:

• Executive conclusion.
• Source table with legal status.
• Applicability matrix.
• Obligation comparison table.
• Retention-period table.
• Required-fields/content table.
• Practical implementation interpretation.
• Vendor/product fit matrix if relevant.
• Capacity/cost model if relevant.
• Caveats and unresolved legal questions.
• Source list with official URLs.

---

Common Pitfalls

1. Assuming every enterprise is covered. Many laws apply only to service providers, licensees, public access providers, data controllers, critical infrastructure, or electronic system operators. 2. Treating proposed rules as current law. Consultation papers and draft rules must be labeled as proposed or pending. 3. Confusing metadata with content. Traffic data, communications data, access records, and content may have different legal treatment. 4. Equating logs with compliance. A firewall log alone may not prove user identity without DHCP, NAT, VPN, directory, Wi-Fi, or authentication logs. 5. Ignoring privacy/minimization duties. Long retention can conflict with data protection principles unless purpose, access control, deletion, and security are defined. 6. Over-reading vendor claims. Vendor reports or compliance templates are not legal compliance unless mapped to specific statutory requirements. 7. Missing local-language sources. For non-English jurisdictions, search in local language and verify against official gazette/regulator pages. 8. Not separating legal certainty levels. Label findings as confirmed binding, regulator guidance, proposed, secondary interpretation, implementation best practice, or unresolved.

---

Lessons Learned

1. Applicability first. In policy research, subject status often matters more than technology. Determine whether the user is a provider, operator, controller, licensee, public access provider, or ordinary enterprise before extracting duties. 2. Legal status must be explicit. Draft rules, consultation papers, unofficial translations, vendor summaries, and regulator guidance must never be mixed with binding statutory obligations. 3. Operational evidence chains matter. A regulation may say "traffic data" or "audit trail" but implementation may require identity, DHCP, NAT, VPN, time sync, admin audit, and integrity logs together. 4. Retention is not always maximization. Data protection laws may require minimization, purpose limitation, and deletion even when cybersecurity teams prefer longer logging. 5. Vendor fit is usually architectural. Product features often satisfy parts of a requirement, but local timestamping, WORM, legal hold, data residency, or official export formats may require external systems.

Security Research Mode

Used when the topic involves security threats, CVEs, attack surfaces, defenses, or vulnerability analysis.

---

5-Part Structure

Part 1: Platform / Technology Landscape

• Architecture and technical internals of the subject platform/system
• Deployment models (consumer, enterprise, cloud, on-prem)
• Ecosystem: marketplace, plugins, integrations, community
• Comparison tables across variants and competitors
• Include Chinese-origin variants when relevant

Part 2: Threat Modeling

• Confirmed CVEs with CVSS scores and fixed versions
• Sources: NVD, MITRE CVE, vendor security advisories
• Attack taxonomy: categorize every threat surface (label A–J)
• Case studies: reconstruct confirmed attack chains step by step
• Delta analysis: what is genuinely new vs. pre-existing categories
• Map threats to OWASP Top 10 (relevant list) and MITRE ATLAS
• Gap analysis: threats with NO current defense or CVE tracking

Part 3: Vendor Solutions

• Traditional security vendors (endpoint, network, identity)
• AI-native security startups
• Platform / internet company native defenses
• Financial sector and regulated industry requirements
• Gap analysis matrix: threat categories × vendor coverage rating
• Emerging approaches not yet commercial

Part 4: Proposed Architecture (only after Parts 1–3 are complete)

• List confirmed gaps from Part 3 before designing anything
• Design principles — each grounded in a specific research finding
• Reference architecture with ASCII diagram
• Novel innovations — one per confirmed gap:
• What gap it addresses
• What research it builds on
• The mechanism
• Why it's novel
• Limitations
• Personal vs. enterprise deployment variants
• Threat-to-defense coverage matrix
• Implementation roadmap

Part 5: Future Forecast

• Technology evolution trajectory (near / mid / long-term)
• Security evolution forecast table
• Market sizing and predictions (Gartner, IDC, vendor data)
• Regulatory and standards evolution (OWASP, MITRE, NIST, relevant law)
• Academic research: what works, what doesn't, open problems

---

Research Plan Guidelines

Before writing RESEARCH_PLAN.md:

• Fetch the actual product/platform website to verify names
• Confirm whether the focus is enterprise, consumer, or both
• Identify Chinese-origin variants worth including
• Clarify: coding agents vs. general-purpose agents vs. consumer apps (different threat models)
• List known CVE IDs, researcher names, or conference talks as starting points

RESEARCH_PLAN.md must include:

• Correct identification of all subjects (verified against primary sources)
• Research questions per part
• Known starting points: URLs, CVE IDs, vendor names, researcher handles
• Explicit "What NOT to assume before research" section

---

Agent Prompt Scaffolding

Agent 1 — Platform Landscape

Research the platform architecture, deployment model, ecosystem, and competitive landscape.
Fetch official documentation, GitHub repos, product pages.
Starting URLs: [list specific URLs from the plan]
Searches to perform: "[platform] architecture internals", "[platform] ecosystem plugins", ...
Save to: {folder}/raw_research/01_platform_architecture.md
Target: 2000+ words with comparison tables and source URLs.

Agent 2 — Threat Modeling

Research all confirmed CVEs, attack techniques, and threat surfaces.
Primary sources: NVD (nvd.nist.gov), MITRE CVE, vendor advisories, Black Hat/DEF CON papers.
Starting URLs: [NVD search URL, specific CVE links, researcher blog posts]
Searches to perform: "CVE [platform] RCE", "[platform] security vulnerability", "[attack type] [platform]", ...
Save to: {folder}/raw_research/02_threat_landscape.md
Target: 2000+ words. Include CVSS scores, affected versions, and confirmed-in-wild indicators.

Agent 3 — Vendor Solutions

Research commercial and emerging security products covering this threat surface.
Cover: endpoint/EDR vendors, AI-native startups, platform-native defenses, enterprise solutions.
Starting URLs: [vendor product pages, analyst reports, startup funding announcements]
Searches to perform: "[threat type] security vendor", "AI agent security startup 2025", ...
Save to: {folder}/raw_research/03_vendor_solutions.md
Target: 2000+ words. Include gap matrix: which vendors cover which attack categories.

Agent 4 — Domain-Specific Research

Research [domain-specific aspect relevant to this topic].
[Customize per topic: e.g., regulatory requirements, Chinese variants, supply chain specifics]
Starting URLs: [specific to domain]
Save to: {folder}/raw_research/04_[domain].md
Target: 2000+ words.

Agent 5 — Frameworks & Forecast

Research the future trajectory: technology evolution, market sizing, regulatory developments, academic research.
Sources: Gartner/IDC reports, standards bodies (OWASP, MITRE, NIST), arXiv, conference proceedings.
Starting URLs: [OWASP page, MITRE ATLAS, Gartner press releases, arXiv search]
Searches to perform: "[topic] market size 2025 2030", "[topic] regulatory framework", "academic research [topic] security", ...
Save to: {folder}/raw_research/05_frameworks_forecast.md
Target: 2000+ words with market tables, regulatory timeline, and academic paper citations.

---

Compilation Rules

• Do NOT write Part 4 (architecture) until Parts 1–3 raw files are read and reviewed
• Part 4 innovations must each close a confirmed gap from Part 3's gap matrix
• Every design principle must cite a specific research finding (file + section)
• Architecture diagram should cover at minimum: agent layer, runtime layer, OS layer, network layer, cloud layer

---

Lessons Learned (Security Mode)

1. Verify platform names first. "OpenClaw" ≠ OpenHands — fetch the actual website before writing a single line of the plan. 2. Wrong agent focus. Coding agents, general-purpose agents, enterprise agents, and consumer agents have fundamentally different threat models. Confirm which. 3. Threat taxonomy before architecture. Labeling attack categories (A through J) before designing defenses ensures each innovation maps to a real threat, not a presumed one. 4. Gap matrix is the design input. Part 4 innovations that don't target a confirmed gap in the matrix are generic and low-value. 5. Parallel agents saved ~70% time vs. sequential in the OpenClaw research (March 2026).

Tech Trend / Ecosystem Research Mode

Used when the topic involves technology trends, ecosystem mapping, market forecasting, hardware/software landscape analysis, or adoption trajectories. No security threat modeling — the goal is to understand what exists, how it works, and where it's going.

---

5-Part Structure

Part 1: Ecosystem Landscape

• What is the subject? Correct identification of all platforms, products, or technologies
• Architecture overview: how the pieces fit together end-to-end
• Major players: Western and Chinese-origin variants where relevant
• Deployment models: consumer, enterprise, embedded, cloud-hybrid
• Adoption signals: GitHub stars, downloads, market share, developer surveys
• Comparison tables across variants and competitors

Parts 2–4: Ecosystem Dimensions (defined per-topic in RESEARCH_PLAN.md)

These parts are NOT fixed. Before launching agents, identify the 3 most important dimensions of the specific ecosystem and define them explicitly in RESEARCH_PLAN.md.

Choosing dimensions: Ask "what are the 3 layers or axes that most determine how this ecosystem works and where it's going?"

Examples by topic:

Each dimension part covers:

• Technical deep dive with real specs, benchmarks, or data
• Major players and competitive positioning
• Gaps, bottlenecks, and unmet needs
• Application-specific relevance

Part 5: Forecast

• Technology trajectory table: year × platform/product × capability milestone × confidence
• Market sizing with analyst citations and CAGRs (Gartner, IDC, MarketsandMarkets, etc.)
• Key inflection points: dated, with confidence levels (Confirmed / Probable / Extrapolation / Speculative)
• Strategic winners and losers: separate tables per axis with explicit reasoning
• OS-native vs. open ecosystem dynamics (where applicable)
• Regulatory landscape: EU AI Act, US policy, China regulations — impact on the ecosystem
• Academic research frontiers: specific papers (arXiv IDs, venue, key result, relevance)
• Risks and uncertainties that could change the trajectory

---

Research Plan Guidelines

Before writing RESEARCH_PLAN.md:

• Fetch actual product/platform websites to confirm what they are
• Identify the 3 ecosystem dimensions for Parts 2–4 — justify the choice
• Confirm scope: consumer, enterprise, or both; Western and/or Chinese market
• List known starting URLs, analyst reports, benchmark sources

RESEARCH_PLAN.md must include:

• Explicit definition of what Parts 2–4 cover for this specific topic
• Research questions per part
• Known starting points: URLs, benchmark leaderboards, analyst report names, key vendor names
• "What NOT to assume before research" section

---

Agent Prompt Scaffolding

Agent 1 — Ecosystem Landscape

Research the full ecosystem landscape: what the subject is, how the pieces fit together,
who the major players are, and current adoption signals.
Fetch official websites, GitHub repos, developer surveys, industry reports.
Starting URLs: [list specific URLs from the plan]
Searches: "[topic] ecosystem overview 2025", "[topic] major players comparison", ...
Save to: {folder}/raw_research/01_landscape.md
Target: 2000+ words with comparison tables and source URLs.

Agent 2 — [Dimension 2 from plan]

Research [dimension name — e.g., hardware, models, sensor technology].
Focus on: technical specs, benchmarks, major products, competitive positioning.
Starting URLs: [specific product pages, benchmark sites, spec sheets]
Searches: "[specific technical terms]", "[dimension] benchmark comparison 2025", ...
Save to: {folder}/raw_research/02_[dimension].md
Target: 2000+ words. Include real specs/numbers, comparison tables, source URLs.
Note publication dates — distinguish confirmed shipped vs. announced vs. rumored.

Agent 3 — [Dimension 3 from plan]

Research [dimension name — e.g., runtimes, software stacks, platform ecosystem].
Focus on: how it works technically, major players, adoption data, performance comparisons.
Starting URLs: [GitHub repos, official docs, developer surveys]
Searches: "[runtime/framework] comparison performance 2025", "[dimension] adoption statistics", ...
Save to: {folder}/raw_research/03_[dimension].md
Target: 2000+ words with technical depth and real data.

Agent 4 — [Dimension 4 from plan — or Applications]

Research [dimension name — e.g., applications, use cases, verticals].
Focus on: real shipped products (not just announced), application categories, gap analysis.
Starting URLs: [product pages, press releases, app store listings, company blogs]
Searches: "[use case] shipped product [topic] 2025", "[vertical] [topic] real-world deployment", ...
Save to: {folder}/raw_research/04_[dimension].md
Target: 2000+ words. Distinguish confirmed shipped vs. demos vs. research prototypes.
Include a gap table: use case × current product coverage × what's missing.

Agent 5 — Forecast 2026–2030

Research the future trajectory: hardware roadmaps, model capability trends, market sizing,
regulatory developments, and academic research frontiers.
Sources: Gartner/IDC/analyst reports, vendor investor presentations, roadmap announcements, arXiv.
Starting URLs: [analyst report pages, vendor roadmap pages, arXiv search URL]
Searches:
  "[topic] market size forecast 2030 IDC Gartner"
  "[topic] hardware roadmap 2026 2027"
  "[technology] research frontier arXiv 2025"
  "[key vendors] strategic outlook investor"
Save to: {folder}/raw_research/05_forecast.md
Target: 2000+ words. Include:
- Hardware/compute trajectory table (year × platform × milestone)
- Market sizing table with source citations and CAGRs
- Inflection points table with confidence levels
- Strategic winners/losers per axis with reasoning
- Academic papers table (paper × venue × key result × relevance)

---

Compilation Rules

• Compile RESEARCH_REPORT.md only after all 5 agents complete
• The executive summary must include: top 5 structural findings + key stats with numbers
• Every table from raw research should appear in the compiled report (summarize, don't omit)
• Forecast confidence levels: Confirmed (official roadmap) / Probable (logical extrapolation) / Extrapolation (trend-based) / Speculative (aspirational)
• Cite specific analyst reports by name (Gartner, IDC, etc.) — do not write "analysts say"

---

Lessons Learned (Tech Trend Mode)

1. Define dimensions before launching agents. The endpoint LLM research (March 2026) used Hardware / Models / Runtimes / Applications — all 5 agents produced focused, non-overlapping research because dimensions were defined upfront. 2. Real numbers matter. Agents must fetch and report actual specs (tokens/sec, TOPS, market CAGRs) — not just describe the landscape qualitatively. "Apple M4 Max: 546 GB/s, ~70 tok/s on 7B Q4" is useful; "Apple has a fast chip" is not. 3. Distinguish confirmed vs. announced vs. speculative. Hardware roadmaps mix confirmed silicon (shipped), announced specs (press release), and rumored specs (leaks). Label each explicitly. 4. Chinese variants are often underresearched. Qwen, DeepSeek, MediaTek, and similar often lack English primary sources. Search for their English-language technical blogs, GitHub READMEs, and international press coverage. 5. Gap analysis is as valuable as coverage analysis. The most actionable finding in the endpoint LLM research was the gap table: privacy AI journaling, consumer ambient AI, on-device personalization — all technically feasible, no shipped product. 6. Market sizing has wide analyst variance. Report the range with sources rather than picking one number. Edge AI 2030: $59B (MarketsandMarkets hardware-only) to $157B (all edge AI including software/services) — both are valid at different scope definitions.