Patent & R&D Operations — Screen Workflows

Screen Workflows

The 16 screens aren’t 16 independent islands — several of them hand real data to each other. This page traces the major end-to-end flows that cross sub-group boundaries; for a per-screen feature breakdown, see the 4 sub-group pages linked below.

1. Invention disclosure → real patent application

The formal starting point of a new patent. A researcher submits an Invention Disclosure in Invention Disclosure Review; the screen’s two-stage AI flow scores novelty (0–100) and rates commercial readiness (high/medium/low) against prior art found by the Embedding Engine. Once a disclosure is approved (reviewStatus: approved_for_patent_filing), the Promote to Patent Filing action calls promoteToPatentApplication(), which:

• Creates a genuine new PatentRecord in the Patent Portfolio Catalog, seeded with the disclosure’s title, lead inventor and first suggested target jurisdiction — status starts at pending_examination.
• Writes the new patent’s id back onto the disclosure (linkedPatentId), so the ledger shows it has already been converted and can’t be promoted twice.

This is a real cross-screen conversion, not a simulated one — the new catalog record is indistinguishable from one entered by hand.

2. IP valuation → synced onto the patent record

IP Valuation & Royalty produces a fair-market-value estimate for a patent asset. The Sync Valuation to Asset Ledger action calls syncIpValuationToLedger(patentId, value), which writes that number directly onto the linked patent’s fairMarketValue field in the Patent Portfolio Catalog — so the catalog always reflects the latest valuation without a manual re-entry step.

3. Collision scan → flagged to R&D & Legal

When Patent Collision Scanner’s two-stage engine classifies a scan as critical_overlap or moderate_risk, the Flag to R&D & Legal action updates the scan’s flagStatus (critical risk → flagged_both, moderate → flagged_rd). There is no centralised cross-team notification inbox in this codebase yet, so the flag is kept as a field on the scan record itself — a future R&D/Legal screen can filter on it once a shared notification center exists.

4. Jurisdiction annuity → scheduled for Finance

Legal Jurisdiction Setup tracks each patent office’s annual maintenance fee and next annuity due date. The Schedule Annuity Payment action (scheduleAnnuityPayment()) stores a synthetic Accounts Payable reference id on the jurisdiction record (linkedAccountsPayableId) — there’s no dedicated AccountsPayableScreen in this codebase (Finance exposes AccountsPayable.tsx directly), so this is the association point for a future hookup rather than a live Finance write.

5. FTO risk → design-around task

When FTO Risk Analysis finds a product blocked in a territory, Trigger Design-Around Task (createDesignAroundTask()) appends the technical spec of the proposed workaround to the assessment’s task log and, if the status was blocked_by_ip, moves it to conditional_design_around_needed — a design-around in progress is no longer a dead end.

Where each screen’s AI work happens

Every AI-calling function in this add-on follows the same two-stage pattern described in Overview: a local-Ollama-only Embedding Engine (Stage 1) feeds a writerEngine-routed AI Engine (Stage 2). The group pages below spell out each screen’s specific Stage 1 corpus and Stage 2 output shape.

Pages in this section

• Overview
• Operational Setup & Master Data
• Domain Roles & Capabilities
• Patent Registry & IP Setup
• Patent Prior Art & Freedom to Operate (FTO)
• Academic Literature & R&D Synthesis
• R&D Grants & Compliance Tracking

Frequently Asked Questions