# How Schema Validation for StructureSchema and AppearanceSchema Controls Patent Disclosure Drafting

> Learn how schema validation for structure_schema and appearance_schema controls patent disclosure drafting by enforcing YAML contracts and preventing errors before generation.

- Repository: [handsomestWei/patent-disclosure-skill](https://github.com/handsomestWei/patent-disclosure-skill)
- Tags: how-to-guide
- Published: 2026-09-02

---

**Schema validation enforces strict YAML contracts that prevent incomplete or inconsistent patent drafts by validating mandatory fields, cross-referencing identifiers, and routing workflows based on disclosure mode before any natural-language generation occurs.**

The `handsomestWei/patent-disclosure-skill` repository automates patent drafting through structured data contracts that eliminate ambiguity. By implementing rigorous **schema validation for patent disclosure drafting**, the system ensures that every structural claim and appearance description is factually complete and legally sound before document generation begins. Two specialized schemas—**StructureSchema** and **AppearanceSchema**—serve as immutable gatekeepers that control the entire drafting pipeline through automated constraint checking.

## Defining the Factual Contracts: StructureSchema vs. AppearanceSchema

The repository establishes explicit data contracts in the `references/schemas/` directory that encapsulate all factual information required for patent disclosures. 

**StructureSchema** ([`references/schemas/structure.schema.yaml`](https://github.com/handsomestWei/patent-disclosure-skill/blob/main/references/schemas/structure.schema.yaml)) governs technical inventions by specifying parts lists, relational hierarchies, spatial cues, and functional notes. **AppearanceSchema** ([`references/schemas/appearance.schema.yaml`](https://github.com/handsomestWei/patent-disclosure-skill/blob/main/references/schemas/appearance.schema.yaml)) controls design patents by capturing product form classifications, claimed facial surfaces, view selections, and designated design points.

These YAML schemas act as the single source of truth. Downstream tools in [`tools/patent_reader/vault/schema_vault.py`](https://github.com/handsomestWei/patent-disclosure-skill/blob/main/tools/patent_reader/vault/schema_vault.py) load and normalize these definitions through `load_structure_schema()` and `load_appearance_schema()` functions, ensuring every pipeline stage references identically structured data.

## Mandatory Field Enforcement

Validation logic immediately terminates processing if required sections are missing or empty. The system defines mandatory fields such as `parts`, `relations`, `overall_shape`, and `views` that must contain non-empty values before drafting can proceed.

In [`tools/shared/structure_lineart_gate.py`](https://github.com/handsomestWei/patent-disclosure-skill/blob/main/tools/shared/structure_lineart_gate.py), the `validate_brief()` function explicitly checks that `structure_schema.parts` is not empty and raises blocking errors when both `structure_summary` and `parts_legend` are missing from line-art briefs. This enforcement guarantees that inventors cannot generate disclosure documents from incomplete technical specifications.

## Cross-Field Consistency Validation

Beyond field presence, the validation engine enforces referential integrity between auxiliary files and schema definitions. When processing line-art briefs or view plans, the system verifies that every identifier referenced actually exists in the parent schema.

For example, [`tools/shared/structure_lineart_gate.py`](https://github.com/handsomestWei/patent-disclosure-skill/blob/main/tools/shared/structure_lineart_gate.py) validates that `parts_legend` identifiers appear in `structure_schema.parts`, generating specific error messages such as “`parts_legend id=… 不在 structure_schema.parts 中`” when mismatches occur. Similarly, view configurations are checked to confirm that `visible_part_ids` entries exist within the structure parts list, with errors like “`views[…] visible_part_ids 不在 structure.parts`” triggering workflow halts.

## Mode-Driven Pipeline Routing

Both schemas contain a **mode** field that accepts either `disclosure` or `reader` values, functioning as a workflow router that determines downstream processing. Entry points such as [`tools/patent_reader/vault/write_patent_obsidian_note.py`](https://github.com/handsomestWei/patent-disclosure-skill/blob/main/tools/patent_reader/vault/write_patent_obsidian_note.py) read this flag to decide whether to generate a full patent disclosure draft or a reading-only reference note.

This schema-level mode selection ensures that validation rules adapt to context. A `reader` mode might relax certain completeness checks for quick reference materials, while `disclosure` mode triggers the full mandatory field enforcement required for legal filing documents.

## Structured Error Collection and Workflow Enforcement

The validation system aggregates all detected issues into a centralized `errors` list rather than failing on the first anomaly. Functions like `validate_brief()` collect constraint violations, ID mismatches, and missing field errors into this list, which the CLI then prints comprehensively before aborting the run.

This structured error collection prevents partial or legally compromised disclosure documents from reaching generation stages. By enforcing that zero errors exist before natural-language rendering or visual compilation begins, the repository maintains strict quality control over patent outputs.

## Summary

- **StructureSchema** and **AppearanceSchema** in `references/schemas/` define immutable YAML contracts for technical and design patent data.
- **Mandatory field enforcement** in [`tools/shared/structure_lineart_gate.py`](https://github.com/handsomestWei/patent-disclosure-skill/blob/main/tools/shared/structure_lineart_gate.py) blocks processing when required sections like `parts` or `relations` are empty or missing.
- **Cross-field consistency checks** ensure that identifiers in line-art briefs and view plans actually exist within the schema definitions, with specific Chinese-locale error messages for debugging.
- The **mode** field (`disclosure` | `reader`) routes workflows to appropriate generation pipelines based on intended document use.
- **Structured error aggregation** guarantees that no disclosure document is produced from invalid or incomplete schema data, ensuring legal and technical accuracy.

## Frequently Asked Questions

### What specific fields are mandatory in StructureSchema validation?

StructureSchema requires non-empty `parts`, `relations`, and `structure_summary` sections at minimum. The validation logic in [`tools/shared/structure_lineart_gate.py`](https://github.com/handsomestWei/patent-disclosure-skill/blob/main/tools/shared/structure_lineart_gate.py) explicitly checks that the `parts` list contains entries and that either a `structure_summary` or `parts_legend` is provided to ensure complete technical disclosure.

### How does the system validate references between line-art briefs and structure schemas?

The `validate_brief()` function cross-references every identifier in the line-art brief's `parts_legend` against the `structure_schema.parts` list. If a legend ID does not exist in the schema parts collection, the system generates a specific error message ("`parts_legend id=… 不在 structure_schema.parts 中`") and blocks the drafting workflow until the discrepancy is resolved.

### What happens when schema validation fails during the drafting process?

When validation functions detect missing fields, empty sections, or ID mismatches, they append descriptive errors to an `errors` list. The CLI prints all accumulated errors and aborts execution immediately, ensuring that no patent disclosure document is generated from incomplete or inconsistent data. This prevents legally defective filings from reaching final output stages.

### How does the mode field affect patent disclosure generation?

The `mode` field acts as a workflow switch with values `disclosure` (for full patent drafting) or `reader` (for reference notes). Downstream tools like [`write_patent_obsidian_note.py`](https://github.com/handsomestWei/patent-disclosure-skill/blob/main/write_patent_obsidian_note.py) inspect this field to determine whether to apply strict completeness validation and generate filing-ready documents, or to relax constraints for internal reference materials.