Mode B Patent Plain Reading Outputs: Complete Guide to Generated Files and Structure

Mode B (Patent Plain Reading) produces a human-readable markdown patent note alongside structured JSON artifacts that drive claim analysis, public search clues, and optional Obsidian vault integration.

Mode B — the Patent Plain Reading workflow implemented in handsomestWei/patent-disclosure-skill — transforms patent documents into actionable intelligence through a deterministic pipeline. Unlike automated classification systems, this mode generates both final deliverables for researchers and intermediate data structures that enable reproducible analysis. Understanding these outputs is essential for debugging workflows, customizing templates, or integrating with external knowledge management systems.


Core JSON Artifacts Generated by Mode B

The workflow serializes structured data at multiple checkpoints. Each JSON file serves a distinct purpose in the analysis chain.

claim_tree.json — Hierarchical Claim Representation

This file captures the full claim dependency structure including independent claims, dependent chains, and parent-child relationships.

  • Contains root nodes, intermediate nodes, and terminal leaves
  • Flags independent vs. dependent claims
  • Enables automated generation of claim-tree diagrams and "本项新增" (new additions) tables

Generated by the validation logic in tools/patent_reader/analyze/validate_claim_tree.py (referenced at lines 71-76 of the main prompt).

claim_deltas.json — Plain-Language Claim Differences

Transforms technical claim language into readable delta statements that isolate what each claim adds to its parent.

Example structure (inferred from prompt lines 81-87):

  • "基膜+至少一面涂覆层..." — describing the incremental technical contribution
  • Powers the "本项新增" section in final notes

public_clues.json — Structured Public Search Intelligence

A machine-parseable record of prior art discoveries with relevance scoring:

Field Purpose
title Source document name
url Direct link to reference
confidence Algorithmic relevance score
summary Condensed description
anchor_fits Key claim mapping points

Defined in prompt lines 2-26, this bridges automated search tools with human review.

note_plan.json — Master Orchestration Object

The central coordination file that binds together:

  • Parsed claim tree
  • Delta statements
  • Public search clues
  • Additional context metadata

Referenced at prompt line 66, this enables the final note generation step to operate deterministically.

lint.json — Quality Assurance Report

Enforces style guide compliance by flagging:

  • Missing mandatory sections
  • Broken figure references
  • Structural inconsistencies

Validation occurs at prompt lines 88-99, ensuring output consistency before human review.


Optional and Conditional Mode B Outputs

synthesis_bundle.json — Aggregated Data Package

When configured for single-step vault operations, this file bundles all intermediate artifacts into one transportable JSON. Implied in the "写入 Obsidian" (write to Obsidian) step at lines 4-5.

write_status.json — Operation Completion Report

Documents the outcome of vault write operations:

  • Success/failure status
  • Warning messages
  • Actual file paths created

Referenced at prompt lines 13-15.

figures/ Directory — Extracted Visual Assets

Contains:

  • Image files extracted from patent PDFs
  • manifest.json describing each figure's role:
    • insert — include directly in note
    • placeholder — reference only, manual insertion required

Defined at prompt lines 101-108.

source/ Directory — Original Document Archive

Preserves the input provenance:

  • Downloaded PDF (if URL was provided)
  • User-supplied full-text files

Ensures reproducibility and audit trails (prompt lines 66-70).


Final Deliverable: The Markdown Patent Note

The primary human-readable output is <run>/note.md — a complete patent disclosure note following the L0-L5 call-out template structure:

  1. L0: Document metadata and classification
  2. L1: Core technical problem and solution
  3. L2: Independent claim analysis
  4. L3: Dependent claim breakdown with "本项新增" tables
  5. L4: Figure descriptions and technical mappings
  6. L5: Public search clues and competitive landscape

This file serves as the definitive research artifact — suitable for direct reading, team sharing, or archival. Generated at prompt lines 70-73 through the "写解读笔记" (write analysis note) step.


Output Location: Obsidian Vault vs. Fallback Directory

Mode B supports two destination patterns controlled by configuration:

Scenario Output Path Trigger Condition
Standard Configured Obsidian vault path VAULT_PATH environment variable set
Degraded Fallback outputs/patent_reader/<run>/ No vault configured ("降级" at prompt line 16)

The fallback mechanism ensures the workflow completes successfully even without external tool integration. Both paths receive identical file structures.


File Path Reference for Pipeline Debugging

All outputs are organized under a run-specific directory (<run>/) with this structure:


<run>/
├── note.md                    # Final human-readable note

├── claim_tree.json            # Claim hierarchy

├── claim_deltas.json          # Plain-language deltas

├── public_clues.json          # Search intelligence

├── note_plan.json             # Orchestration object

├── lint.json                  # Quality report

├── synthesis_bundle.json      # Optional aggregate

├── write_status.json          # Vault write report

├── figures/                   # Visual assets

│   ├── manifest.json
│   └── *.png, *.jpg, etc.
└── source/                    # Original documents

    └── patent.pdf

Source: prompts/reader/patent_plain_reader.md (main workflow definition)【/cache/repos/github.com/handsomestWei/patent-disclosure-skill/main/prompts/reader/patent_plain_reader.md】.


Summary

Mode B Patent Plain Reading produces five categories of outputs:

All outputs are generated through the deterministic pipeline defined in patent_plain_reader.md, with flexible destination handling for Obsidian-integrated or standalone deployments.


Frequently Asked Questions

What is the difference between claim_tree.json and claim_deltas.json?

**claim_tree.json** captures the structural relationships between claims — which claims depend on which, forming a hierarchical tree. **claim_deltas.json** captures the semantic differences — what technical content each claim adds compared to its parent. The tree enables visualization; the deltas enable the "本项新增" analysis that explains incremental innovation.

Can I run Mode B without an Obsidian vault?

Yes. When no vault is configured, the workflow automatically uses the fallback path at outputs/patent_reader/<run>/. The same markdown note and all JSON artifacts are written there. This "degraded" mode (as labeled in the source at prompt line 16) ensures the analysis pipeline completes regardless of external tool availability.

How does lint.json enforce quality standards?

lint.json is produced by automated checks at prompt lines 88-99 that validate the structural completeness of generated content before finalization. It flags missing sections, incorrect figure references, and template violations — acting as a gate that prevents malformed notes from reaching researchers.

Which output file should I check first for debugging failed runs?

Start with **write_status.json** (vault operations) or verify the presence of **note_plan.json** and **lint.json** (pre-generation validation). These files indicate how far the pipeline progressed and where errors occurred. The note.md file will only exist if all prior validation and generation steps succeeded.

Have a question about this repo?

These articles cover the highlights, but your codebase questions are specific. Give your agent direct access to the source. Share this with your agent to get started:

Share the following with your agent to get started:
curl -s "https://instagit.com/install.md"

Works with
Claude Codex Cursor VS Code OpenClaw Any MCP Client

Maintain an open-source project? Get it listed too →