Domain Monitoring

17 min

\ domain monitoring \ helps you keep a technology domain up to date after the initial research project is finished instead of manually reopening datasets, checking for new patent activity, and rerunning the same analysis questions, you can monitor a project on a cadence and review what changed use it when you want odin to keep watch over a competitor space, material platform, application area, or technology landscape that matters to your strategy \what problem does domain monitoring solve?\ technology landscapes change continuously new patents are published, new assignees enter a field, competitors shift their filing activity, and technologies move from early research toward industrial readiness without monitoring, teams often rely on one off searches or occasional refresh projects that makes it easy to miss a competitor starting to file in a space you own a new entrant appearing in a technology area a material, process, or application trend gaining momentum a domain moving faster or slower than expected a technology becoming mature enough to buy, partner around, or invest in domain monitoring turns a static project into a recurring intelligence workflow it keeps your patent datasets fresh, reruns deep dive questions on a schedule, and tracks how technology maturity (trl) changes relative to improvement rate (tir) over time \common use cases\ use domain monitoring for competitor watch track whether competitors are filing more actively, entering adjacent topics, or changing their technical focus new entrant detection identify first time filers or unexpected assignees appearing in a domain technology landscape tracking follow how a set of technologies develops over time portfolio review monitor which technologies are becoming more mature, more active, or less relevant material and process scouting surface new materials, formulations, production methods, or use cases as they appear in patent data strategic decision support use the trl x tir matrix to decide what to monitor, fund, phase out, or ignore recurring stakeholder updates build a repeatable flow for weekly, monthly or quarterly domain updates \relationship to the trl x tir dashboard\ the trl x tir matrix maps technologies using two dimensions trl, or technology readiness level how mature the technology is, from early research to proven industrial use tir, or technology improvement rate how quickly the technology appears to be improving, based on patent activity and development signals domain monitoring adds the time dimension each successful monitoring run creates a new snapshot, so you can see whether a technology is becoming more mature improving faster or slower than before moving into a more strategically important area of the dashboard gaining / losing momentum compared to the other technologies in the same project staying stable while adjacent technologies accelerate together, trl and tir help you decide how to act matrix quadrant what it usually means typical action rising star low trl, high tir emerging technology with strong momentum monitor closely fund high trl, high tir mature technology that is still improving fast buy, leverage, partner, or invest phase out high trl, low tir mature technology with limited improvement maintain carefully or discontinue gradually ignore low trl, low tir early technology with weak momentum watch lightly or deprioritize you can use this progression to prepare strategy reviews, decide which domains deserve deeper investigation, identify technologies that are becoming investable, or spot areas where a previously promising technology is slowing down the matrix is most useful when comparing technologies within the same project or domain it is a dynamic view, meaning that it includes all datasets added to the project, even after monitoring was created tir is a directional signal, not a guarantee of commercial success trl may need to be reviewed or manually adjusted when a dataset is missing maturity information or when your team has better domain knowledge than the available evidence the trl x tir dashboard is a strategic level capability it requires the project to have an agentic workflow stored with a clear problem statement odin uses that problem statement as context for the trl and tir analyses, so readiness and improvement are interpreted against your actual strategic objective rather than as generic patent statistics if the project does not have the required agentic workflow and problem statement, the trl and tir signals cannot run automatically you can still monitor datasets and use bulk deep dives where your plan allows it, but the trl x tir progression history will be limited to work around this, you can use the export chat feature in agents, and save the relevant context into the target folder where your monitoring project lives \how domain monitoring works\ on each scheduled run, odin can refresh the monitored project check the datasets for new patent families apply saved filters and llm filters to the new material update the trl x tir dashboard and version history run scheduled deep dives at bulk the result is a time based view of your domain you can compare current results with previous runs, view deep dive results per dataset and version, and review how your technologies shifted in the trl x tir matrix \\ for the best results, prepare the project before enabling monitoring save the datasets you want to monitor inside one project folder use subfolders if you want the trl x tir dashboard to group technologies by theme make sure the datasets have useful saved filters apply llm filters where you want odin to classify new patent families during future runs check that dataset names are clear, since they appear in monitoring results and dashboards review or set trl values for important datasets when needed for strategic trl/tir monitoring, make sure the project has an agentic chat file inside the folder with a clear problem statement domain monitoring works best on focused, well structured projects very broad or noisy datasets can produce less useful monitoring results \set up monitoring for a project\ open the project folder you want to monitor go to the monitoring tab for the project click set up monitoring choose a cadence weekly for fast moving areas monthly for most domains quarterly for slower moving areas choose the first run date the earliest available start date is usually tomorrow save the monitoring setup after monitoring is created, odin runs the scheduled tasks automatically in the background larger projects can take longer to process monthly monitoring is usually the best starting point quarterly monitoring can work for slower domains, but longer gaps can make each run heavier to analyze, and bloat the context window of llms because more new patents accumulate between runs \add scheduled deep dives\ scheduled deep dives let you ask the same strategic question to multiple datasets on every monitoring run for example which competitors are filing the most, and how is that changing over time? are any new assignees entering this space? which new materials, composites, or production methods are appearing? which applications are becoming more common in recent filings? what changed since the previous monitoring run? to add a scheduled deep dive open the monitored project go to the monitoring tab click + add deep dive select the datasets in your project that you want the deep dive to apply to type the question you want odin to answer per dataset, on the monitoring cadence revise the plan, or accept & save signal odin creates one scheduled (monitored) deep dive result per dataset in scope after every run for example, one deep dive signal applied to 12 datasets creates 12 monitored deep dive results per run scheduled deep dives count toward https //docs getfocus eu/domain monitoring#plan limits and restrictions users on the research plan can create (or actively have) 60 scheduled deep dives per month, whereas users on the strategic plan can create (or actively have) 200 \what happens on each scheduled run?\ monitoring runs are queued and processed in the background results are not instant at a high level the monitoring setup becomes due on the selected start date and cadence odin checks the project datasets for newly available patent families if a dataset has an llm filter, odin applies that llm filter to the new material if an llm filter is already running, dependent monitoring results are delayed and queued until the llm filter is finished the trl x tir matrix is updated for eligible projects with the required agentic chat deep dive runs produce one deep dive result for each dataset in scope, after the dataset has been updated results appear in the monitoring tab as each deep dive run completes when you schedule a new deep dive, odin creates a first run immediately future runs follow the monitoring cadence \review results\ use the monitoring tab of the project to review the current monitoring status the next scheduled run scheduled deep dives generated deep dive results trl x tir dashboard snapshots from previous runs movement in the trl x tir matrix the trl x tir dashboard can also be exported as an image or spreadsheet for use in updates and reports \edit, disable, or delete monitoring / scheduled deep dives\ you can edit the monitoring cadence, disable (pause) monitoring, re enable it later, or delete it deleting monitoring will delete all of its associated assets like trl x tir matrix versions and scheduled deep dive results disabling monitoring stops future scheduled runs it does not delete previous monitoring results, deep dive outputs, or trl x tir dashboard snapshots you can also enable, disable, edit, or delete individual deep dives this is useful when a question is no longer relevant but the overall project should continue to be monitored editing a scheduled deep dive only affects future runs, not already generated results follow up questions asked in each deep dive chat screen only affect the corresponding version (of the resource table) of the corresponding dataset if you want these follow up questions to be reflected across all datasets for the upcoming runs, you need to edit the scheduled deep dive and instruct the agent to add a new column to the resource table \plan limits and restrictions\ the current release has plan based limits for domain monitoring and deep dives plan scheduled deep dives patents per deep dive research 60 per user per month 200 patents strategic 200 per user per month 1,000 patents a scheduled deep dive run is one deep dive question applied to one dataset during a signal run for example 1 deep dive question across 10 datasets uses 10 deep dives 3 deep dive questions across 10 datasets uses 30 deep dives the monthly scheduled deep dive rate limit is counted per user and resets each calendar month the patent limit applies to all deep dives, including regular deep dives (in chat with set) and monitored deep dives it controls how many patents odin can process in an individual resource table to return a deep dive result dataset refreshes can also be limited by processing safeguards for datasets with an llm filter, odin processes up to 10,000 newly discovered or previously unprocessed patent families per dataset refresh run very large or very broad datasets may therefore need careful filtering to keep monitoring results useful \practical tips\ start with one focused project before monitoring a broad portfolio use monthly cadence unless the domain is clearly fast moving or slow moving keep scheduled deep dives specific and repeatable review trl values before relying on the trl x tir matrix for strategic decisions make sure the agentic chat file reflects the strategic question you want the trl x tir matrix to answer treat domain monitoring as a recurring intelligence workflow, not a one time report if you have any questions or need assistance with domain monitoring, please contact us at support\@getfocus eu