--- name: docnav-litigation-analytics description: Run empirical litigation analytics in Docket Navigator across any library — judge, court, party, firm, or counsel outcome rates on any motion or document type, benchmarked against peers, traced back to the underlying orders, and saved to a binder with alerts. Use when a user asks how a judge or court rules on something, what a party's or firm's track record looks like, whether timing or posture changes the odds, or asks to compare, benchmark, monitor, or chart litigation outcomes. Triggers on "how does Judge X rule on", "what are the odds of", "grant rate", "success rate", "win rate", "compare judges", "compare courts", "benchmark", "how often is X granted", "track record", "should we file now or wait", "show me the orders", "monitor this judge", or any request for data-backed litigation strategy from Docket Navigator. --- # Docket Navigator litigation analytics This skill runs the full arc of an analytics question: from a strategic question, to verified numbers, to the underlying orders, to a saved and monitored binder, to a chart a client can read. It works the same way in every Docket Navigator library — patent, trademark, copyright, trade secret, antitrust, securities, SEC, UPC — because the mechanics are identical and only the vocabularies differ. The output is only as good as the filter discipline behind it. Most wrong answers in this workflow are not tool failures. They are correctly executed searches that asked a slightly different question than the user meant. ## The arc 1. Frame the question and identify the decision it serves 2. Resolve every value against its vocabulary 3. Build and validate one search, then vary one thing at a time 4. Read the numbers with their grain in mind 5. Retrieve the underlying documents 6. Save, monitor, chart Steps 1 through 4 are mandatory. Steps 5 and 6 depend on the ask. ## 1. Frame the question Before touching a tool, settle three things. **What decision does this serve?** "How does this judge rule on motions to dismiss" is a research question. "Should we file now or after the scheduling conference" is a decision. The second one needs a timing split; the first does not. Ask if it is unclear, because the answer changes which searches to run. **Whose behavior is being measured?** Judge, court, party, firm, or counsel. Each is a separate criterion with its own vocabulary. **What is the comparison?** A grant rate with nothing beside it is close to useless. Default to benchmarking the subject against the court that contains them, and against a peer venue the user cares about. Offer the comparison even when it was not requested. `docnav_plan_search_workflow` is a reasonable opening call for an unfamiliar area. It surfaces relevant targets and product features. Treat its output as orientation rather than instruction, and note that its convenience categories can be broader or narrower than the specific document type the user means. ## 2. Resolve values, never guess them Every controlled value comes from `docnav_lookup_search_values`. Names, ids, and abbreviations are never typed from knowledge or from a prior session. ``` docnav_lookup_search_values( library_name="", criterion_name="judge_and", joinpath_name="judge_id", lookup_kind="autocomplete", text_query="" ) ``` Use `autocomplete` for names, `list` for closed sets, `tree` for hierarchies. **Ids are namespace-scoped.** The `event_group` criterion has four slots — cause, action, issue, result — and each has its own vocabulary. The same integer means different things in different slots. An id resolved from `event_group_action` is not valid in `event_group_result`. Keep each id in the slot it came from and never move one across. **Resolve the document type precisely.** Search `event_group_action` for the exact document type rather than accepting a broad category. Categories often bundle several related types, or omit the specific one the user means. If the user says "motions to stay pending IPR," resolve that exact string rather than using a generic "motions to stay" grouping, and confirm the resolved title in the response echo. **Resolve the result vocabulary before analyzing.** Pull the full `event_group_result` list once. Outcome sets are richer than granted and denied — expect variants like granted in part, denied without prejudice, denied as moot, and deferred. Which ones exist, and how they distribute, is frequently the substance of the answer rather than a rounding detail. ## 3. Build one search, then vary one thing Compose the search, validate it, and read the echo before trusting any number. ``` docnav_validate_and_preview_search( library_name="", target_name="", search={ "library_name": "", "target_name": "", "field_names": [], "criteria": [ {"name": "judge_and", "joinpath_name": "", "value": []}, {"name": "event_group", "joinpath_name": "", "value": [{"cause": [], "action": [], "issue": [], "result": []}]} ] } ) ``` ### Join paths belong to the criterion-and-target pair This is the single most common source of wasted effort. A join path is not a property of the criterion alone. The same criterion needs different paths on different targets, and `judge_and` on one target may take `judge_id` while on another it takes a case-scoped path. When a filter comes back as unapplied or unknown, that is a wrong join path, not a missing feature. Do not conclude the product cannot do it. Re-resolve with `docnav_discover_search_options` against the exact target, check `known_joinpath_examples`, and if the target has no example for that criterion, borrow the path a related target uses for the same criterion. Case-scoped filters such as date ranges and court frequently share a path shape across targets. The most reliable source of a correct path is a search object you did not write. `docnav_inspect_binder_tab` on a profile's saved analytics tab returns a complete, working search handle. Start from that handle and change one criterion at a time. ### Read the description echo every time The response includes a `description` block naming every applied filter in plain product language. Read it. It is the cheapest available check that the search asks what was intended, and it catches transposed ids, wrong document types, and unapplied criteria before they become numbers in a memo. ### Vary one criterion at a time Establish a baseline count, then add or change exactly one thing. When a number moves unexpectedly, the cause is unambiguous. Building three criteria at once and getting a surprising count means starting over. ## 4. Read numbers with their grain ### Posture is not optional The `cause` slot distinguishes how a motion arrived: contested motion by a party, stipulated or agreed, sua sponte, renewed, on reconsideration, on review of a magistrate's report. **Leaving this slot empty blends all of them into one rate.** This matters more than any other single parameter. Unopposed and stipulated motions are granted at rates that bear no relationship to contested ones, and mixing them produces a headline number that overstates a litigant's real odds, sometimes by a factor of two or more. Default to the contested posture for anything meant to model a litigated outcome. Then pull the stipulated posture separately as its own figure. The gap between them is often the most actionable finding in the whole analysis, because it prices what the other side's agreement is worth. ### Counts are usually coded decision documents Most outcome targets count coded document-type events rather than distinct motions. One motion that generates a magistrate's report and recommendation plus a district judge's adoption order can appear twice. Responses disclose this through `result_grain`, `unique_document_count`, and accompanying notes. Read those fields. Practical consequence: report percentages with confidence and treat raw counts as an upper bound on distinct motions. Cross-check against a pendency or motion-count target when the absolute number matters. ### Choose the date basis deliberately Targets typically offer several: document or order date, case filing date, case age at document filing, current case age, and termination date. These answer different questions. - Recency of the ruling itself → document or order date - Cohort of cases → case filing date - How far into a case something happens → case age at document filing State which basis is in use whenever a date-limited figure is reported. A rate restricted by case filing date is not the same as one restricted by ruling date, and conflating them misleads. ### Understand any special or saved filter before relying on it Profiles and binders can carry saved special queries, including custom ones built by the vendor or by a colleague. These are powerful and often encode exactly the distinction a user needs. They also usually arrive with a title and nothing else. Before a special filter's output goes to a client, establish what it actually compares, and disclose that it is a saved filter rather than a native field. If the definition cannot be established, report the number with that caveat attached rather than describing the filter in terms that were assumed. ### Sanity-check the arithmetic Result categories should approximately sum to the unfiltered total. A gap means either an unqueried result category or records the filter could not classify. Name the residual rather than letting the categories imply full coverage. ## 5. Retrieve the underlying documents Rates establish the pattern. Orders explain it, and a strategy memo needs both. Run the same criteria against the library's documents target rather than the analytics target. This returns individual documents with case citations, filing dates, document identifiers, and — where the editorial team has annotated them — summaries of the holding with issue tagging. Read the annotations for recurring language. When a court has a settled practice, the same formulation tends to recur across orders, and that phrasing is what belongs in a brief. Also look for the outlier: the order where the court reached the same result on additional independent grounds. That one usually matters more than the pattern, because its reasoning survives a change in circumstances that would otherwise reset the analysis. Annotation coverage varies. Absence of annotation text across a consecutive recent run is itself a signal, usually that the court has moved to short-form dispositions on a settled question. Use `docnav_resolve_product_link` and `docnav_read_filing_text` to get from an identified document to the filing itself. Quote courts, paraphrase the editorial annotations. ## 6. Save, monitor, chart ### Binder Create a binder when the research will be revisited, shared, or defended. ``` docnav_create_binder( library_name="", title="", description="", tabs=[{"title": "", "search": {}}] ) ``` Every tab must hold a search object that has already validated. Give tabs titles that name the population rather than the filter syntax. Put the reconstruction parameters in the binder description: the resolved document type, the posture convention, the date basis, the counting grain, and the provenance of any special filter. A binder without this is a set of numbers nobody can defend six months later. ### Alerts Alerts attach to a whole binder, not to a single tab. A binder containing broad benchmark tabs will generate alerts dominated by the benchmark population. **Create a separate, narrow monitoring binder.** One tab, scoped to exactly what should trigger a notification, then subscribe to that. ``` docnav_create_alert( binder_ref_or_url=":binder:", alert_rate="", alert_history=false ) ``` There is no generic weekly rate; weekly means naming a day. Use a library-qualified binder reference. Set `alert_history=false` unless the user wants binder edit notifications mixed in with filings. Keep monitoring tabs broad on outcome and narrow on subject. A newly docketed order may not yet have every downstream linkage resolved, so a monitoring search built on derived or cross-referenced filters can miss or delay exactly the rulings the user most wants to see first. Filter on the subject and the document type; let the outcome categories come through unfiltered. ### Charts For a client-facing comparison, a horizontal 100% stacked bar per population reads best: one bar per group, segments per outcome category, percentage labels on segments, counts in the tooltip. Rules that keep a chart defensible: - Put every bar on the same basis. Do not mix an all-time population with a date-limited one in the same chart. - Keep the residual category visible so bars sum honestly. - Label the population size for each bar somewhere the reader can find it. - Footnote the counting grain. - Preserve outcome distinctions the analysis turned on. A four-bucket rollup that folds a meaningful variant into a generic denial destroys the finding. ## Reporting Lead with the number that answers the decision, not the largest number found. Separate what the data shows from what it cannot see. Outcome rates do not capture what the movant offered, how the parties relate, or how comprehensive the underlying petitions or claims were. A baseline is a starting point, not a prediction for a specific motion, and saying so is part of the answer. State the caveats that materially bound the figure — grain, date basis, posture, saved-filter provenance — and keep them to a line each. When a number that was already reported turns out to be wrong, correct it plainly, say what the right number is, and say what caused the error. Do not let a superseded figure survive in the conversation because restating it is awkward.