Scoring
A score with the evidence and limits attached
Patendra computes the score from four defined signals instead of asking a model for an unsupported number. The same inputs produce the same result, confidence is reported separately, and the underlying search and review record remains available for inspection.
The problem
Why an unsupported score is not useful
A number generated by a model in one forward pass has three defects that make it useless for a filing decision.
It isn't reproducible
Run the same disclosure twice and a model-generated score drifts. A number that changes when nothing else did is a styled guess, not a measurement.
It isn't traceable
When a model says "72", there is nothing underneath to audit. You can't ask which reference cost you points, or what would move the number, which is precisely what an attorney needs to know.
It rewards ignorance
A model that found no prior art (because the search failed, not because none exists) will happily score the idea highly. Absence of evidence gets laundered into evidence of novelty.
Patendra's design rule, applied end to end: the model reasons, the evidence decides. The model argues about references and claim language; arithmetic over verified findings produces the score.
The signals
Four signals, deterministically combined
Each signal comes out of the workflow's examination stage with its evidence attached. The score is a fixed computation over them, with no free-form judgment in the loop.
| Signal | What it measures | Evidence source |
|---|---|---|
| Novelty | Whether any single retrieved reference anticipates the claims, and how much of each claim the closest art covers, element by element | §102 analysis over retrieved, ID-verified references from the four-source search |
| Non-obviousness | Whether viable §103 combinations exist: pairs of references plus an articulated motivation to combine them against the claim set | Simulated examination memo, §103 combination analysis |
| Enablement | Whether the specification supports the claims: make-and-use enablement, written description, and definiteness findings | §112(a)/§112(b) checks, from structural validation plus examination |
| Breadth | How much claim scope actually survived refinement. A narrow claim that survives everything is not automatically a good outcome | Claim structure analysis of the refined claim set |
Reporting
Per statute, never a single badge
Real examination outcomes aren't one light that turns green. The dashboard shows a result strip with an independent finding for each statutory ground, something like this:
§ 102: no anticipation found § 103: combination asserted § 112(a): enabled § 112(b): definite
FIG. 1: Per-statute result strip (example)
There is deliberately no "ALLOWABLE" badge anywhere in the product. A claim set can clear §102 and still die under §103; it can be novel and non-obvious and still fail §112. Collapsing four legal questions into one green checkmark is exactly the kind of comfortable lie Patendra refuses to render. Each asserted rejection links to its ID-verified reference and its element mapping.
Confidence
Confidence is separate from the score
Alongside every score, Patendra records why it believes what it believes, and how strongly.
Every belief has a lineage
The Bayesian evidence chain records each piece of evidence (a reference retrieved, an element mapped, a §112 check passed) and how it shifted the system's belief. Reviewing a score means walking the chain, not re-running the analysis and hoping.
Strong / Moderate / Weak
Confidence is surfaced as a plain label, not a decimal that implies false precision. A "Strong" novelty finding backed by a thorough multi-source search means something different from a "Weak" one backed by thin coverage, and the UI keeps that difference visible.
Honesty
The empty-search trap
The most dangerous number in patent analytics is a high novelty score produced by a search that never really happened.
No results ≠ no prior art
APIs time out. Budgets run dry. Queries miss. A naive scorer treats every empty result set as good news and reports "novel". Patendra distinguishes search failure from empty results at the retrieval layer, and the scoring layer respects that distinction.
Zero references examined never renders as "novel"
If no references were actually examined, the run shows an explicit insufficient-search warning instead of a novelty conclusion. The score you see is always a score of the evidence that exists, never a score of the evidence that failed to load.
Calibration
Local calibration reflects completed reviews
A deterministic formula can still be mis-weighted. Patendra calibrates its weights against the only ground truth available before the patent office speaks: your professional judgment.
-
You rate the finished run
In the dashboard, record your assessment of a completed run: Strong / Moderate / Weak / Rejected. That's the whole interface: one verdict from a human who read the output.
-
Prediction is logged against verdict
Patendra stores what it predicted next to what you concluded. Systematic gaps (say, scores that run hot on enablement in your domain) become visible data instead of a vague distrust.
-
Weights and confidence recalibrate
The scoring weights over the four signals and the confidence labels adjust to your track record. The search-strategy optimizer and experiential memory learn from the same runs. There is no fine-tuning and no data leaving your machine. The calibration lives in your local data directory. See the learning loop.
Scope
What the score is not
What the score is good for: triaging which disclosures deserve counsel's hours, catching killer references before filing fees are spent, and giving the drafting stage claims worth writing a specification around.
Inspect the score and its evidence
Install the desktop app, add a Claude or Gemini API key, and score your first disclosure: four signals, per-statute findings, full evidence chain. Plans on the pricing page.