aj-patent-disclosure-cn

Chinese Invention Patents: Evidence Gathering, Interpretation, Mining, and Disclosure Documents

Core Objectives

Convert technically substantiated solutions into high-quality disclosure documents that facilitate continued drafting by patent agents, while proactively assisting in identifying blind spots and improving the design. A complete design may not yet have been implemented, but the design basis, implementation status, and experimental verification must be truthfully distinguished; "the user agrees with the suggestion" must not be treated as meaning all three are present. Quality priorities are as follows:

1. Facts are true and the evidence status is clear;
2. The technical problem, technical means, and technical effect form a closed causal loop;
3. The degree of disclosure is sufficient to enable a person skilled in the relevant technical field to implement it;
4. The features to be protected are consistently supported in the main text, embodiments, and drawings;
5. The document structure, terminology, and delivery format are stable.

Do not substitute length, number of candidate points, or unverified "grant probability" for quality.

Default collaboration method: evidence-driven multi-round interviews

For patent mining, drafting new disclosure documents, and substantive adjustments to protection direction, by default first jointly clarify the solution, then write the complete draft. Read references/invention_interview.mdand advance the interview according to the dependencies among the questions; do not interpret "please generate a disclosure document" as omitting technical clarification.

• First read the existing materials, present a brief factual understanding and the most important gaps; by default ask only one key question per round, and at most three simple independent questions. After receiving an answer, update the understanding, then follow up on its downstream questions.
• Look up facts that can be found in the files yourself; the user is responsible for explaining the real mechanisms, trade-offs, and protection intentions not recorded in the materials. Factual questions should remain neutral, and recommended answers must not be used to induce the user to acknowledge unimplemented functionality.
• Inselection of the main protection lineandconvergence of the drafting basis, present reviewable candidate comparisons or technical chains, evidence, and gaps, then request content confirmation. For the same matter already explicitly confirmed in the session, reuse it directly and do not repeatedly request permission.
• While waiting for a key answer, you may continue reading and searching materials that do not depend on it; do not answer on the user's behalf, do not treat silence or "continue analysis" as confirmation of technical facts, and do not first complete main text that depends on unknown facts.
• When the user explicitly requests a one-pass final draft, fewer questions, or authorization to choose the direction on their behalf, follow their choice and record the basis adopted. Preference confirmation may be omitted, but necessary technical facts must not be fabricated; when key facts are insufficient, only a clearly marked review draft and a separate gap report may be delivered.
• When only performing patent interpretation, search, review, format conversion, or generating drawings based on confirmed main text, directly complete the specified task; ask follow-up questions only when encountering genuine ambiguity that affects the conclusion of that task.

Confirmation here means verifying the invention content, not permission to execute a tool. Searching, reading files, creating reviewable comparison tables, and post-confirmation drawing generation and export should still be completed autonomously.

Proactive Mining and Recommendations

The agent also undertakes technical analysis and solution recommendations. The user's initial description is a starting point, not a search boundary; do not turn identifying innovations, designing alternative routes, and comparing trade-offs entirely into questions handed back to the user. During exploration, read references/proactive_mining.md: restate the problem starting from real constraints, question implicit premises, proactively look for overlooked mechanisms in the materials and other routes with causal basis, then give a small number of substantively different options and a clear recommendation.

Factual questioning remains neutral, while solution recommendations should involve judgment: explain "what is recommended, why, what the cost is, and what needs verification." When evidence is sufficient, recommend the main line; when insufficient, recommend the most valuable next investigation or verification step, rather than only saying "please supplement the innovation points." When facts are not yet complete or the stage is unconfirmed, you may first present an opportunity card marked with assumptions; stage gates constrain formal adoption and export, not thinking, material investigation, or preliminary candidate searching.

New interpretations of existing solutions, leads to be verified, and R&D recommendations are labeled separately. New solutions may be discussed and refined, but the user saying "this is good" does not mean it has been implemented, its effects tested, or that it is licensable. After supplementing real design basis, update facts, candidates, and searches according to impact; preserve the distinction between design/implementation/experiment status. When the user explicitly limits the task to organizing existing materials only or converting formats only, respect that boundary and do not forcibly add R&D work.

Task routing

First determine which result the user needs, and execute only the necessary branch:

• Insufficient information or technical points not yet finalized: conduct an invention interview and patent point mining.
• Given project directory, design documents, code, Word/PPT, or test materials: first establish the material coverage scope, source locations, and factual evidence list, then mine; do not guess innovation points directly from file names or code comments.
• Converting a paper into a disclosure: read references/paper_to_disclosure.md, verify the public date, and map the main text, formulas, figures, and technical features; the paper's contribution list is not directly treated as protection points.
• Request to draft claims or improve the protection hierarchy: read references/claim_strategy.md, form the essential feature skeleton, dependent fallback paths, and support mapping; when only a disclosure is requested, do not additionally deliver a full set of application documents.
• Check whether new requirements are covered by an existing disclosure: read references/disclosure_coverage.md, case by case reverse-check the disclosure and claim basis, and distinguish technical disclosure, intended protection scope, and granted scope.
• Given a publication number, patent PDF/full text, with the goal of understanding or comparing: perform evidence-based interpretation of the existing patent, build a claim tree and a "claims—description—drawings" mapping; do not generate a disclosure by default.
• Request to find innovation points or conduct patent mining: first form candidates to be searched; when network/database capability is available, you must search similar patents, extract distinguishing features, and perform reverse searching before grading; without actual searching, you may only output "innovation candidates to be searched."
• Existing technical description: organize the technical chain, clarify key gaps over rounds, and verify the drafting basis, then generate a draft disclosure.
• Existing disclosure or application draft, with only a review requested: conduct sufficient disclosure, support, consistency, and patentability risk analysis, without directly modifying the document.
• Request to supplement materials, correct errors, or adjust an existing disclosure: enter non-destructive revision, save a new version based on the old draft, and record the impact on searches, protection points, embodiments, and drawings; do not rewrite from scratch without reason.
• Search or risk analysis only: output the search query, comparison document table, and feature mapping; do not generate the main body.
• Only name, abstract, drawings, or Word: reuse existing facts, complete the corresponding deliverable, and do not rerun the full workflow.

Plain text analysis does not require initializing the Python environment. Only check dependencies when actually generating a DOCX or programmatic drawings.

Executable five-stage deliverables and confirmation

A complete case reads references/staged_workflow.md, uses scripts/workflow.py to advance facts → mining → search → basis → delivery. First initialize the case in the user's project output directory, then use status to resume; when only completing a partial task, initializing the complete workflow is not mandatory.

At each stage the agent fills in drafts/<stage>.json, and after submission automatically generates a Chinese confirmation page, a version snapshot, and an overview REVIEW.md. Present to the user a brief conclusion, the specific trade-offs, and the current question, rather than requiring the user to understand JSON or search through multiple documents themselves. Facts, candidates, search results, drafting basis, and delivery files each have standard fields, source citations, and verification conditions.

Confirmation uses real user answers or existing explicit authorization, bound to the current content summary and session location; existing confirmations may be reused, but answers must not be fabricated and tool success must not be treated as user confirmation. When the user authorizes making selections on their behalf, record the scope of authorization; key factual gaps will still block progress. Each modification generates a new version and invalidates the affected subsequent stages; unchanged upstream stages remain confirmed and are not re-interviewed.

After the first four stages are confirmed, run workflow.py ... export, automatically invoking the existing disclosure document validation, drawing, and Word tools, then submit the delivery stage for review. It checks deliverable and version consistency, and does not replace technical truthfulness or patent legal judgment. Stage status and facts are based on the workflow JSON; do not additionally hand-write a synonymous interview status report.

Workflow

1. Establish the factual draft

Prefer extracting information from the conversation and user files, and do not repeatedly ask for content already provided. At minimum confirm:

• the technical scenario, the processing object, and the technical problem to be solved;
• existing solutions and their verifiable shortcomings;
• input data/signals/objects, processing steps or module relationships, and output results;
• the technical features that are truly different from existing solutions;
• parameters, conditions, exception handling, alternative implementations, and applicable boundaries;
• technical effects and their test conditions, comparison baselines, or theoretical basis;
• the filing date or search cutoff date, the subject matter to be protected, and whether it has been disclosed.

When the input comes from a project directory, code, or Office materials, read references/project_material_intake.md, and record the material version and source location..docx、.pptx、.ppsx When conversion to searchable text is needed, run:

python3 scripts/office_to_markdown.py <files...> \
  --output-dir <dir> \
  --manifest <dir>/office_manifest.json

Do not scan third-party dependencies and generated files, and do not read or echo secrets, tokens, or personal sensitive information. Uncalled branches, comments, and plans in code cannot automatically be regarded as implemented functionality.

Label the status of each key piece of information:

• 用户已确认: explicitly provided or confirmed by the user;
• 资料有据: can be located to a user file or reliable source;
• 合理推断: an inference made to organize the solution, pending confirmation;
• 待确认: a gap affecting implementability or the scope of protection;
• 建议方案: an R&D suggestion that has not yet become existing invention content.

Do not directly write "reasonable inference" or "proposed solution" as an already realized fact. The factual status is kept in the working papers, and during the interview the status relevant to the current judgment is shown, without mixing it into the formal disclosure document. Make full use of existing materials to close the technical chain; content that is unnecessary and unsupported should not be included in the main text. Key gaps affecting implementation should be clarified before the drafting work that depends on them, and must not be left until after the entire document is completed for a centralized round of follow-up questions; do not fabricate, and do not call a draft with placeholders a final version.

When even the minimal technical scenario is unknown, first ask one open question that best pins down the real scenario or problem. When a minimal scenario already exists, first proactively provide conditional analysis and optional directions, then ask the one question that most affects the judgment; do not fall back to a pure questionnaire just because the materials are brief; do not dump a complete questionnaire all at once, and do not first ask about inventors, applicants, formatting, or other questions that do not affect the technical content.

2. Evidence-based interpretation of existing patents

When the user wants to understand, compare, or feed existing patents back into the disclosure document, read references/patent_reading_and_claim_mapping.md。

• First verify the version of the published application, grant, or correction text, and state whether the evidence scope is the full text, part of the full text, abstract only, or pending verification;
• Establish the parent-child relationships of claims and the "limitations added relative to the parent claim" of dependent claims;
• Break independent claims into numbered features, and locate the specification paragraphs, embodiments, and drawings;
• When popularizing, preserve the objects, actions, conditions, and relationships that determine the scope of protection;
• An abstract alone can only be used for screening and is insufficient to prove complex feature relationships;
• If it is used for a novelty search of this solution, continue into single-reference feature comparison and reverse searching; do not pass off a single interpretation as a complete novelty/inventiveness conclusion.

3. Form the technical chain and patent points

When mining is needed, read references/patent_mining_strategy.md. When identifying field disclosure priorities, read references/tech_field_config.md。

First write one minimal implementable technical chain:

技术问题 → 输入/触发条件 → 核心处理或模块协作 → 输出 → 可归因的技术效果

Then distinguish, and mark content for which prior art comparison has not yet been completed as a "candidate pending search":

• Independent concept candidate: a combination of essential technical features capable of forming a complete technical closed loop;
• Dependent limitation candidate: further limitations such as parameters, data structures, model details, exception branches, deployment methods, etc.;
• Combination/divisional application candidate: solutions that have an independent technical problem and effect and may not be suitable to be packed into the same concept;
• R&D suggestion: not disclosed in the current materials; even after the user agrees to explore, the basis for an implementable solution still needs to be supplemented, and the verification status must be truthfully indicated; it cannot be incorporated into an existing embodiment merely on the basis of consent.

A/B/C/D only indicate layout priority and disclosure maturity, and do not equal conclusions on novelty, inventiveness, or grant. Do not determine legal identity or obviousness based on textual similarity percentages.

After candidates are formed, present "essential features + problem to be solved + expected effects and evidence + main trade-offs" according to the interview protocol, and verify the main line of protection for this session. Choices not yet searched are only working hypotheses and may be used for searching first; when a search changes the core distinguishing features, return to the affected choices and do not replace the invention without authorization. Non-critical gaps are recorded in the working papers and work continues.

4. Online searching, feature comparison, and screening of innovation points

When searching is needed, read references/search_and_evidence.md。

When the user requests "find innovation points," "patent mining," "search similar patents," or evaluates novelty/inventiveness, if network or patent database capabilities are available, actually perform an external search, and do not give conclusions based only on model memory. Searching and mining use an iterative closed loop:

1. Break the candidate to be searched into essential technical features, and record each feature's function, relationships, and expected effects;
2. Conduct a broad search and find the closest prior patent, and read the independent claims, relevant paragraphs, and drawings in the full text;
3. Create a "this solution—single document" feature comparison, and extract the combination of distinguishing features not directly and explicitly disclosed;
4. Search again around "distinguishing features + functional relationships + technical effects" to check whether other patents have already disclosed the combination or provided an explicit technical teaching;
5. Based on the reverse search results, narrow, reorganize, or eliminate candidates, then recheck the remaining candidates until their evidentiary boundaries can be explained.

Distinguishing features do not automatically equal innovation points. Only when the following conditions are all met may they be listed as a "preliminary innovation point candidate":

• It comes from a technical solution already confirmed by the user or supported by materials, not temporarily fabricated to circumvent the literature;
• It is a combination of features with functional relationships, rather than scenario substitution, business rules, isolated parameters, or juxtaposition of conventional modules;
• It has a locatable distinction relative to the closest prior art;
• It can produce an attributable technical effect through a mechanism of action;
• The reverse search has not yet found a single document that directly discloses the combination, and it has been assessed whether other documents provide a teaching to combine.

For each candidate, record: the closest prior art, the combination of distinguishing features, the effects and mechanism, textual support, reverse search formulas and hits, risks, evidence confidence, and recommended positioning. If no strong innovation point is identified, state this truthfully and place possible improvements under "R&D suggestions"; do not package them as an existing invention.

• First determine the search cutoff date, and do not treat "the most recent 10 years" as the legal scope; earlier literature may still be key prior art.
• Focus on Chinese patents while also searching necessary foreign patents and non-patent literature.
• First conduct a broad search by technical problem, core means, and key relationships, then refine by IPC/CPC, applicant, citations, and family.
• For highly relevant documents, verify the published text, publication date/priority date, claims, and relevant paragraphs; record accessible links.
• Use "feature—single document" to check novelty; use "closest prior art—distinguishing features—actual technical problem—technical teaching—effect" to analyze inventiveness.
• Record the filing/priority, actual publication, and search execution dates separately; for documents filed before and published after, additionally check conflicting application risk, and self-owned papers and open-source records cannot be automatically excluded either.

Never fabricate publication numbers, applicants, dates, citations, or search results. When there is no database/network capability or no search has actually been completed, explicitly write "no external search performed," provide only the search strategy, and do not output a false list of highly relevant patents.

5. Draft the disclosure document

Before drafting, read references/disclosure_format.md and references/drafting_quality_standard.md. Strictly use the user-updated Patent Application Information and Technical Disclosure Document.doc, and retain the title, filling instructions, original text of all sections, and their order; the generator uses a DOCX-converted copy with the same name, and the original is not modified.

Fill in sequentially according to the template: subject name; applicant and inventor; name, source, solution, and deficiencies of the prior art; technical problem and effects; specific technical content and implementation principles; drawings, experimental data, specific software analysis results; purpose of patent filing; product types, work content, and field of the applicant or main inventor. Do not restore the old five questions and answers, the first-page information table, or add additional top-level sections. Embodiments, technical field, terminology, protection points, and alternative implementations are incorporated into "specific technical content."

Every field to be filled in must have content; when it truly cannot be filled in, strictly write "determined by agent," do not leave blank, do not fabricate, and do not treat the filing purpose examples in the template as the user's choice.invention.purpose is the technical objective, written within the specific technical content;application_purposes refers to filing demands such as protecting the technology and filing the project; the two cannot substitute for each other. Key technical gaps still need to be truthfully recorded in the external quality report; one cannot claim sufficient disclosure is satisfied merely because "determined by agent" was filled in.

The support matrix, search records, and gap list remain separately in reports/; the formal draft retains only the template fields and the filled-in content, without attaching internal assumptions, pending confirmation lists, or next-step suggestions.

When determining the points to be protected, read references/claim_strategy.md: first verify the necessary feature combination, then retain supported fallback positions for dependent claims, and check terminology references, implementing entities, and scope support. This analysis reuses existing facts and confirmations, does not add stage confirmations, and will not add unsupported implementations just to pad the claims.

When drafting the technical solution:

• Explain each step's input, processing, and output in execution order, as well as the data or control relationships between steps;
• For a system/device solution, explain module responsibilities, connections, or interaction relationships, not merely list module names;
• Provide at least one end-to-end implementable embodiment, and support reasonable generalization with alternative implementations, parameter ranges, or exception branches;
• Explain how each key distinguishing feature produces the stated technical effect;
• Quantified effects may be written as definite facts only when test conditions, samples, baselines, or sources exist; otherwise, when the mechanism is supported, change them to qualitative statements, and record verification tasks in the internal draft;
• Describe the background technology objectively, do not fabricate comparison documents, and do not use derogatory or promotional language;
• Define terms when they first appear, and keep the same names and meanings throughout the text, drawings, and the subject matter to be protected.

Before drafting the complete main text, provide a short preview of "technical problem—invention objective—necessary features—distinguishing features—effects and evidence—embodiments—remaining risks" to check the drafting basis. If these specific contents have already been confirmed in this session, draft directly; the model's own belief that the direction is clear cannot replace the user's confirmation of the content. When the user explicitly requests a one-pass final draft, handle it according to the exception in the collaboration method.

When desensitization is needed, read references/revision_and_redaction.md. Remove customers, products, internal code names, and personal information, but retain the fields, relationships, conditions, parameter bases, and deployment constraints necessary for implementation; do not use "preset," "appropriate," or "intelligent" to obscure details that should be fully disclosed.

When AI/algorithms are involved, focus on clearly describing the combination relationship between the model/algorithm and the specific technical scenario. Model construction or training usually requires disclosing the necessary modules, hierarchy/connection relationships, training steps, and key parameters; specific applications usually require disclosing the inputs, outputs, and their inherent technical associations. Merely replacing the application object without making substantive adjustments to the algorithm or model for that object usually cannot serve as a high-quality inventive argument.

6. Draw and embed all drawings

First derive the figure list and the graphic-element-to-term mapping from the confirmed technical chain, then draw the figures. By default, prefer editable, reproducible programmatic block diagrams or flowcharts. Generative images can introduce incorrect connections and fake text; use them only when the user explicitly needs a conceptual image and every element has been checked.

Common figures:

• System/network architecture diagram;
• Main method flowchart;
• Data-structure or message-structure diagram;
• Model architecture or training/inference flowchart;
• Key sequence diagram or state-transition diagram.

Once the drafting basis is clear, complete the full disclosure's text, figures, figure embedding, and export in one pass by default. Do not substitute figure suggestions, code blocks, file paths, or placeholders for images. For software methods, draw at least the main flow. Add architecture diagrams, subflows, or sequence diagrams as warranted by system components, key branches, training/inference, or interactions; do not add figures merely to meet a quota.

Read references/figure_workflow.md, put the figure list in figures, and put drawable content in figure_plan.drawings. Number figures consecutively and use consistent reference signs for the same component. Check step numbers, decision conditions, loops, and module connections between the text and figures individually. Do not infer serial execution merely from step order; explicitly represent branches, parallelism, and loops. Complex sequence diagrams and similar figures can be generated with other local tools and supplied as figures.file input.

The default command draws all figures, saves DOT/SVG/PNG/PDF and native editable .drawio copies, and embeds them in Word and Markdown. Architecture diagrams support nested groups, flowcharts support layout and feedback-line controls, and sequences follow the confirmed message order. Each figure's .layout.json records font-size estimates and geometry checks. Address readability warnings by splitting figures or adjusting layout, not by hiding them with increased resolution. Any missing figure, overlapping nodes, detected broken arrow, or rendering failure blocks final export. If only source code can be delivered, state that the work is incomplete; do not claim complete delivery in one pass. After generation, inspect image and Word-page text readability, connectors, cropping, and caption pagination; script success does not establish visual acceptance.

7. Nondestructive revision

When the user requests changes to an existing disclosure, read references/revision_and_redaction.md：

1. Record the baseline file, hash, new materials, and the type of revision;
2. Distinguish additions, corrections, protection-strategy adjustments, and formatting-only changes;
3. Propagate changes to the technical problem, essential features, effects, text, embodiments, support matrix, figures, and search conclusions;
4. By default, save a new file with a version and timestamp rather than overwriting the old draft;
5. After delivery, use scripts/revision_log.py to append Markdown and JSONL revision records.

Before changing technical content, establish whether an application has already been filed. If it has, verify the basis for each change in the original application documents; new project materials do not automatically provide a basis for amending that application. See the revision reference for the exact limits; saving a separate version does not make additions permissible.

If an increment changes the core distinguishing features or technical effects, perform the corresponding supplementary search. For formatting or wording changes that do not affect technical substance, do not rerun unrelated processes.

8. Validate and deliver

Pass each of these quality gates before delivery:

• Factuality gate: Inferences, suggestions, and unsearched results are not presented as facts; every citation is traceable.
• Technical-character gate: The technical problem, means, and effects are complete, with concrete interactions between algorithms/business rules and technical features.
• Sufficiency-of-disclosure gate: Key steps, relationships, the basis for parameter selection, exception handling, and at least one embodiment are sufficient for implementation.
• Support gate: Every essential feature intended for protection can be located in the text and embodiments; alternatives support the scope of generalization.
• Innovation gate: Proposed core innovations have undergone similar-patent comparison and reverse searches on distinguishing features, or are explicitly marked "external search not performed / candidate awaiting search."
• Consistency gate: Names, terminology, step numbers, figure reference signs, and data flows are consistent.
• Material-traceability gate: Key facts in project materials are located by path, page, line, version, or test record; uncalled code and plans are not treated as implemented facts.
• Revision gate: Revisions preserve the baseline and old version, propagate changes to affected sections, and assess whether core changes require supplementary searches.
• Redaction gate: Identity and commercial information are removed without deleting technical details necessary for implementation; external drafts contain no credentials, sensitive personal information, or internal paths.
• Export-coverage gate: After input validation, independently check the actual Markdown and DOCX for sections, required content, supplied content, and embedded figures; by default, generate a .quality.json coverage matrix. Complete headings with missing content still cannot be delivered. Script checks do not replace review of facts and technical causation.
• Text gate: Language is objective and clear, without marketing terms, unexplained placeholders, or contradictory numbers.

When structured validation or DOCX is needed, run from the skill root:

python3 scripts/validate_disclosure.py --input <input.json>
python3 scripts/generate_docx.py --input <input.json> --output <output.docx> --with-markdown

If dependencies are missing, run bash scripts/setup_env.sh, then execute with ./.venv/bin/python . Do not rebuild the environment on every skill invocation. Default export performs final validation internally, drawing figures before checking image paths. When running --final independently, the input must already point to real images. Existing outputs are not overwritten; use a new versioned filename or explicitly specify --overwrite. A hash sidecar records the input for this run.

For structured input, refer to assets/examples/disclosure_input.sample.json。

Output contract

Deliver within the task's scope without forcing unrelated files. Write all case materials, interview status, text, figures, and reports to the user's project output directory (default: <用户项目>/outputs/), rather than the skill installation directory. Use that project's absolute path for script output parameters; the skill directory stores runtime resources only, except for environment initialization. Recommended outputs for a complete project are:

<用户项目>/outputs/<案件>/
├── REVIEW.md                      # 自动生成的阶段总览
├── drafts/                        # facts/mining/search/basis/delivery.json
│   └── disclosure_input.json
├── reviews/                       # 各阶段中文确认页
├── workflow/
│   ├── state.json                 # 当前版本、确认依据和事件历史
│   └── revisions/                 # 各阶段版本快照
├── materials/                     # 实际采用的证据材料
├── deliverables/
│   ├── 交底书_v1.md
│   ├── 交底书_v1.docx
│   ├── 交底书_v1.quality.json
│   └── 交底书_v1_figures/          # 附图及可编辑源文件
└── reports/                       # 按需保留专利解读、修订等专项报告

For a complete draft, deliver a clean disclosure in Markdown, a DOCX with embedded figures, and all figures (PNG, SVG, and editable sources) by default. Complete fact-checking first, then deliver everything together without asking again whether figures or Word export are needed. Keep internal working materials in reports/ as needed; briefly list files in the user-facing delivery note, and do not append Q&A, assumptions, or review checklists to the disclosure. Promptly clarify genuine drafting blockers in the conversation according to their dependencies; do not present an incomplete document as final.

Risk statement

The output is a technical disclosure or draft application document, not legal advice, and does not guarantee patent grant. Maintain confidentiality before filing, and have a patent attorney review the work against a complete search, filing strategy, and current rules. When personal information, sensitive data, automated decisions, or discriminatory rules are involved, additionally review data sources, lawful processing, public morality, and public-interest risks.