I designed and built Praviar, a chemical patent research application. I was its sole engineer, bringing together patent retrieval, chemical-structure recognition, model-assisted analysis and a workspace for reviewing the findings.
The work started with a compound and a research question. Answering it could involve patent claims, drawings, related publications and records from external sources. I wanted a researcher to be able to follow a finding back to the material behind it, including gaps that the analysis had not resolved. Reading a chemical drawing was one part of that work; establishing what it meant in the patent required the surrounding text and the facts of the investigation.
Praviar is now open source, and I am no longer developing it. The drawing recognisers, analysis pipeline and review application were implemented, but an important connection remained unfinished: a recognised structure could trigger deeper claim analysis without its drawing evidence reaching the agent doing that analysis. This account follows the work far enough to explain both the useful mechanisms and that gap.
1. The problem behind the report
Praviar starts with a compound and the scope of a research matter: what product, process or use is being investigated, where, and over which period. A name alone can be ambiguous. Different identifiers may refer to a parent compound, a salt or a particular stereochemical form. Resolving that input is already an analytical task, before the system searches for patents.
The retrieved material introduces another set of differences. Publications can belong to the same patent family. A record may contain an abstract but lack the claims needed for a particular question. A drawing may depict one compound or use variable groups to represent a family of structures. Legal status and prosecution information come from other records, with their own gaps and dates.
I treated the report as a place to assemble evidence and expose uncertainties for a qualified reviewer to investigate. Praviar produces patent intelligence; it does not provide a freedom-to-operate opinion. Grouping related publications or recovering a molecular structure can help someone examine a patent, but neither establishes what its claims cover.
To explain the design, I will use an illustrative matter involving “Compound A”. A researcher supplies a structure and a proposed manufacturing use. A potentially relevant patent contains a drawing and a claim involving drying under reduced pressure. The matter does not say how the proposed process will dry the compound. The run is interrupted, then continued, and a reviewer later challenges a finding that assumes this missing fact. This is a constructed walkthrough of supported behaviours, not a customer story or a recorded end-to-end experiment. The application captures use a separate synthetic fixture, “Example Molecule Alpha”, to show the controls and a different evidence gap.
The researcher may have to act before the whole matter is resolved. A retrieved record may be missing the claim text needed for analysis. A recognised structure may remain experimental, outside the evidence admitted to the report. Even a completed report can have an outstanding review decision that blocks export. The application needs to show what is available and what still requires attention at each stage.
2. Requirements and workload
I organised the application around the work involved in investigating and reviewing a matter.
The workload is uneven. Resolving one identifier may be quick, while another input needs more investigation. A patent can contain several drawings, and each drawing can contain several chemical regions. Recognition can invoke multiple models for a crop. Claim analysis can escalate when the initial result does not satisfy the configured checks. A single analysis request can therefore expand into a substantial amount of work.
External sources add latency and partial failure. A slow response should not make the web application hold a request open for the entire analysis. A missing source should not disappear from the record merely because other providers replied. The system also needs bounds on work: candidate counts, page sizes, image dimensions, concurrency and deadlines all affect how far an analysis can proceed.
I do not have a production traffic profile or a validated availability target for this architecture. Capacity estimates would need to account for the expansion within a matter: how many records survive triage, how many pages need processing, how many crops reach recognition and how much additional analysis is requested. A count of submitted matters alone would say little about that workload.
A report with more findings also demands more reviewer attention, even if generation becomes faster. Preserving intermediate results is of limited help if the supporting passage is difficult to find. The workspace needs source navigation, visible failure states and stable finding references so the reviewer can examine a disputed result without reconstructing the run.
I used explicit contracts at the boundaries. The Python application and pipeline exchange validated models, and TypeScript contracts are generated from backend-owned definitions. A finding's identifier, review state and supporting evidence therefore have a shared representation in the API and browser. Changing that representation affects the generated contract; it does not depend on someone remembering to update a second handwritten definition of the same JSON.
3. How the application fits together
The Next.js workspace presents matters, progress and reports. A FastAPI application owns authentication, organisation-scoped access, persistence and the review and export operations. The analysis runs through a separate Python pipeline library. Research tooling and evaluation assets are kept outside that runtime library, so an experiment does not silently become an application dependency.
For Compound A, submission creates an analysis within the authorised organisation. The application can return an identifier while the longer work proceeds separately. The browser follows progress and later opens the evidence report. Closing the tab does not make the browser responsible for restarting that work; execution state belongs to the worker and its saved records.
Figure 1. Implemented application responsibilities and the hosted execution reference. The reference cloud topology is not evidence of an operated production service.
PostgreSQL holds application records, including analysis state, progress events and reviewer decisions. Redis carries live progress delivery. After a lost connection, the browser can recover missed updates from the persisted events. Pipeline resume checkpoints live as authenticated files in configured runtime storage; those restore the worker's execution state.
The hosted reference uses a durable task to reach a short-lived worker launcher, which reserves an execution identity and starts a separate analysis job. That avoids making a queue delivery wait for an entire research run. An execution fence identifies the attempt allowed to update the run; a lease records time-limited ownership. Together they help coordinate overlapping launch requests and workers. The repository includes this design and supporting implementation, but its cloud infrastructure remains an unvalidated deployment reference.
Within the application, organisation identity has to accompany the work. The API checks the authorised organisation when it reads a report or records a decision. Database row-level security adds another boundary around tenant-owned records. A long job, a progress subscription and an export request are separate entry points; each must preserve the appropriate scope. A browser-supplied analysis identifier is a locator, not permission to read it.
A matter defines the investigation, and source records with their provenance support its findings. Report generation collects those findings into a snapshot. Reviewer decisions refer to findings within that snapshot, so changing the report can change which decisions count towards export. The application has to retain those relationships as the matter progresses.
The pipeline runs compound resolution, retrieval, family handling and triage before the deeper analysis. Drawing work applies to the patents that survive triage. Drawing results have two further boundaries to cross: permission to influence the analysis, and delivery to the code that interprets the claims. The default shadow configuration withholds that permission. The incomplete agent handoff affects the permitted path too. Figure 2 follows those connections rather than treating every stored result as evidence the claim agent has read.
For our matter, a failed recognition request concerns the affected patent and drawing. A lost progress connection interrupts the browser's view of the run. Those failures call for different responses: one needs investigation of the source or recogniser, while the other needs a replay of progress. The records retained by each path determine how much the application can explain afterwards.
4. Reading chemistry from drawings
The drawing in our illustrative patent first has to be acquired and located. A page can contain explanatory text, reaction arrows, tables and several molecular depictions. A detector or segmenter identifies regions; a classifier routes the resulting crops. Optical chemical structure recognition, or OCSR, then attempts to turn a supported image into a machine-readable structure.
I integrated several recognition models rather than building a new foundation model for this task. Their outputs need a common representation before they can be compared. SMILES represents a molecular structure as text. RDKit parses and normalises candidate structures, allowing the system to compare molecular representations instead of treating every different output string as a different answer.
That comparison does not make a candidate correct. A model can return a valid structure with the wrong bond, substituent or stereochemistry. The pipeline therefore has separate checks for chemical validity, confidence, plausibility and available text cross-signals. It retains the source page, crop location and image hashes so an extracted structure can be traced back to what was actually read.
For Compound A, suppose the drawing produces competing candidates. If none passes the resolution gate, the result remains unresolved and no candidate becomes an accepted drawing-structure record. Crop and source context can support diagnosis, but a rejected candidate is not necessarily retained as a drawing-structure record. Returning the highest-scoring candidate regardless would give later analysis a structure the checks had already rejected.
I separated extraction from permission to influence analysis. The checked-in configuration defaults to shadow rollout. In that state, collecting an experimental result does not grant it authority over the report's conclusions. Influence-capable operation additionally depends on configured evidence gates and verified bindings for the relevant tools and calibration. Missing prerequisites can stop that path; an ordinary absence of a drawing or a crop can instead produce a per-item abstention.
An empty drawing result needs care. In shadow mode, acquisition, segmentation or recognition failures can be logged while leaving an empty result, just as an ordinary absence of material can. That result alone does not tell a reviewer whether there was nothing to read or the attempt failed. When drawing evidence may influence analysis, an acquisition failure that leaves no pages even after fallback, or a segmentation failure, raises an error instead.
The historical experiments also need to be separated from the final configuration. A five-model crop benchmark recorded 410 exact canonical structures from 447 crops. The full page-to-structure run recovered 62 exact structures from 86 labelled target occurrences, or 72.1%. Among the 70 it resolved, 62 were exact, or 88.6%. The larger conditional percentage leaves out unresolved targets. The page artifact also repeats some inputs, so these are recorded occurrence counts rather than an independently sampled set. The companion examines both the denominators and the repeats.
The checked-in segmentation default is DECIMER, and the configured ensemble roster contains MolScribe and MolSight. The five-model experiments used a different configuration, including models with separate licensing or provenance constraints. Their scores do not measure the default installation.
Markush drawings add a further complication. Their variable groups can describe a family of structures rather than one fixed molecule. The specialist path has its own configuration and validation conditions. A governed Markush result uses a different structure representation and does not simply pass through the fixed-molecule similarity calculation. The experimental scope work remained separate from a reliable general interpretation of chemical claims.
The vision companion shows correctly recovered, incorrect and unresolved structures beside their source drawings. The application can retain origin and status with an accepted structure, but that retained record still has to reach the analysis using it. Recognition quality and evidence delivery need separate checks.
5. Making an analytical finding accountable
What supports the finding
The next step in our example is a claim-level finding relating the patent text to the matter's scope. To review it, someone needs the supporting passage. A reference to the whole patent leaves them searching for the basis of the model's interpretation.
The report model includes a map between assertions and source spans. A span identifies the relevant supporting text and its provenance. Verified claim text has additional integrity bindings, and the review preparation checks those bindings against the report. A model-authored citation cannot grant itself the status of verified source material merely by supplying the expected fields.
The assertion-to-source mapping lets the reviewer inspect the passage behind an individual finding. It also records assertions that need review or lack support, so the interface can show those conditions against the affected statement.
Application view. The synthetic “Example Molecule Alpha” fixture shows a missing verified source span. It is a different problem from Compound A's missing fact about the proposed use: here the source support itself is incomplete. The matrix places that source status beside the interpretation and reviewer disposition.
In the illustrative matter, the passage describing drying under reduced pressure has a verified source. What is missing is a fact about the proposed process: does it use that drying step? Reading the drawing correctly cannot answer that question. A claim element is an individual requirement within the claim, such as this drying step. Its assessment should remain unclear, and the analytical assertion remains marked needs_review. Verifying the quotation does not verify the interpretation. This finding can remain in the report for a person to assess.
Explicitly unsupported assertions take a different path. The finalisation checks can reject them before the report-review checkpoint, including missing claim or element coverage in the required high- and medium-risk analyses. The test suite exercises those hard failures separately from findings that need review. It also checks tampered claim text and model-authored evidence that cannot establish its own provenance.
A source attestation is an authenticated record binding the evidence to the report. Changing the cited text should invalidate its prior support, and reusing an attestation from another report should not establish support in this one. The checks require that binding as well as a populated citation field. They can detect a broken source relationship without determining whether an inference from an intact source is correct.
Choosing how to investigate a patent
The analysis chooses an execution path for each patent. Where no escalation signal is present, it assembles the available claim, specification and prosecution context for a structured analysis call. The output decomposes claims into elements, with an assessment, reasoning, evidence and confidence for each element. An evaluator then checks the resulting analysis for issues such as inconsistent element and risk assessments or poor quality.
Some material goes directly to the research-agent path. The execution planner looks for signals including long claim sets, Markush or formula language, relevant drawing structures and uncertain triage. It records the reasons for that choice. A result from the simpler path can also be escalated when the evaluator marks its quality as poor. The order therefore depends on the input; every patent does not pass through an identical chain of calls.
The research agent can fetch the specification, search it for definitions and look up basic patent details. Claims are pre-parsed where possible. An ambiguous term can therefore lead to another source lookup before the agent returns its analysis in the same structured contract. Its bound toolkit does not include the prosecution-history tools described in some of the project documentation; that broader description exceeds this implementation.
The matter-context handoff differs between the two routes into the agent. Direct escalation from the execution planner forwards the matter's product, intended-action, jurisdiction and development-stage context. Escalation after a poor evaluator result does not forward those fields in the snapshot examined here; they default to empty values. The agent still receives the compound and patent, but this further investigation can have less matter context than the call it follows.
The agent's instructions leave missing product, use, territory or timing facts unresolved instead of inferring them from the compound name. That instruction applies both to facts the researcher never supplied and to context omitted by the handoff. The assessment retains its source relationship and review state after the agent finishes. If the evaluator itself fails, the runtime records a quality-gate failure and marks the analysis for review.
After the model-assisted stages, deterministic verification checks consistency before reporting. The code records pass, failure and unavailable-check information. It also records when a check validated no items, which would otherwise appear as a pass. Schema validation can establish that an output is well formed, source binding can establish its provenance, and deterministic checks can find internal inconsistencies. Whether the interpretation follows from the evidence in its legal and scientific context remains a separate review question.
Where drawing evidence stops
The drawing-evidence handoff has a separate gap. In a normal fresh run, only drawing evidence admitted by the rollout gate reaches the analysis planner. For an analysed patent with structures in that store, the planner chooses the agentic branch and records a drawing-evidence escalation reason. That branch did not forward the drawing store to the claim agent. A separate single-pass helper could format drawing summaries, but the normal route for that patent bypassed it.
Report generation separately received the permitted drawing store and could include drawing fields. The later matter evidence index and graph were assembled from non-vision records. Completing the integration required both a handoff to the selected claim-analysis path and a way to join image-derived assertions to that later evidence inventory. The existing helper covered only a path that the drawing-triggered analysis bypassed.
Figure 2. Permitted drawings affect routing and report fields. The normal drawing-triggered route did not forward that evidence to the claim agent, and the later matter evidence graph did not directly index it.
The runtime's clearance labels are application outcomes under configured rules. A label such as CLEAR cannot be read as a professional freedom-to-operate opinion. Its meaning depends on the evidence coverage, gates and scope that produced it. That distinction becomes especially important when a source is missing or a visual interpretation exists only in shadow.
6. Keeping long analyses recoverable
By this stage, Compound A may have accumulated retrieved records, triage decisions, source-health information and analysis results. Losing all of that because a process stops would be expensive. The runtime saves completed stages and can restore their typed state from a checkpoint, subject to authentication, integrity and schema checks.
A checkpoint contains more than a step number. It saves the compound input, completed stage and relevant results, including source-health information and escalation reasons. Continuing after triage requires the retrieved and selected records, not just a flag saying that triage finished. These saved results make it possible to avoid repeating completed stages.
The checkpoint files use HMAC authentication, a keyed check of their contents, and restoration validates their integrity and schema. The loader selects the checkpoint with the highest saved step number; if that file fails validation, it raises an error rather than automatically falling back to an earlier step. Saved provenance fields also have to pass the required evidence checks. Loading a field named “verified” cannot establish its authority.
Figure 3. Checkpoints restore completed execution state under current settings. Durable events restore the browser's progress history; execution ownership coordinates workers. Work after the last completed checkpoint can repeat.
In our example, assume triage has completed and been checkpointed before the run is interrupted during later analysis. If the checkpoint passes its checks, resumption restores the completed state and starts the remaining work from that boundary. Work performed since the checkpoint may be repeated. A saved stage is not a transaction covering every external request, and a process interruption does not tell us whether a provider already processed its last call.
Recovery can therefore repeat work and incur another provider charge; it does not guarantee exactly-once execution. Preserving the execution context helps identify what is being resumed, but an external source or model may have changed since the previous attempt. The resumed analysis can receive different responses.
A valid checkpoint can supply earlier results to work performed under current settings. The checks do not guarantee that the original analysis policy is being resumed. Although the schema rejects removed fields, it accepts an unrestricted name for the saved execution profile, the policy under which the work ran. During startup, the runtime restores that name and then replaces it with the current profile. It restores the compound input and completed results, but not the full original matter configuration. Current settings and overrides govern the remaining work, so they need to be inspected alongside the checkpoint.
The browser needs a different recovery mechanism. Progress events are persisted and can be replayed when a client reconnects. Live delivery through Redis provides updates while work is running. A reconnecting client should recover the account of what happened from durable events rather than assume that missing notifications mean no progress occurred.
Execution ownership is separate again. In the hosted reference, a durable launch request, an execution fence and a job lease coordinate whether a worker should run. These controls address duplicate deliveries and competing ownership; the checkpoint provides the state from which the accepted execution can continue.
The runtime also records timing and cost information and handles cancellation and deadlines. A stopped run can retain its completed checkpoint without producing a final report. In Compound A's case, that leaves triage available for inspection even though later analysis did not finish. A checkpoint, a completed report and a successful export are separate outcomes.
A stalled progress display calls for checking event delivery. A worker failure calls for checking execution ownership and the completed checkpoint. If evidence is missing after resumption, the restored state and source conditions need inspection. The saved records help separate these failures before another attempt is launched.
7. What a reviewer can actually decide
Two report-review mechanisms matter here: an early checkpoint during execution and a later workflow for the completed report. They present different material to the reviewer and record approval against different versions of that material. The pipeline also supports checkpoints for earlier identity, triage and analysis decisions.
When configured, the runtime checkpoint presents a bounded decision brief. It includes the upstream risk, counts, an executive-summary excerpt and aggregate information about the assertion/source ledger. A digest, computed from the payload, binds the brief to the complete underlying records: the map linking assertions to source passages, and the hashes identifying the prompts used. The brief shows aggregate information about those records rather than displaying their full contents. Here, reviewer attestation means an explicit acknowledgement of the review context before approval is recorded. Malformed context cannot be approved through that path.
The runtime computes later clearance metadata after this checkpoint, outside the scope of its approval. The checkpoint can also be unconfigured; it is not an unconditional stop in every run.
The later review application works with a completed report. Here, decisions are attached to a finding and the report's fingerprint: a value calculated from the report payload to identify that version of its content. The reviewer can accept, reject or propose an edit. The service checks that the finding exists in the current report and that the actor is authorised. It records the decision and audit information within the application's persistence rules.
Figure 4. Early checkpoint approval does not replace final-report review. Export checks current report state, evidence readiness and the decisions required for its findings.
Return to our illustrative finding, treated here as a medium-risk finding requiring review. The reviewer reads the drying-step passage and sees that the proposed process is insufficiently described. They propose an edit stating that the assessment depends on whether that process uses drying under reduced pressure. The application records the proposal separately from the report text; it does not silently apply it and treat the changed text as accepted. The proposed edit blocks export. A rejection likewise cannot be outvoted by collecting additional accepts for the same unchanged snapshot.
Application view. A demonstration edit and rejection remain separate from the report text. These are real interface states with fictional data; the demonstration saves decisions in browser memory.
If the report changes, decisions tied to the old fingerprint do not count as approvals of the new version. The current findings need decisions against their current content before they can satisfy the export rules.
The requirements are also more specific than one global approval button. Medium- and high-risk export-relevant findings require accepting decisions for the current snapshot. High-risk findings require two distinct accepting reviewers. The loading path counts eligible active attorney/admin users, and a rejection or unapplied edit remains a blocker. These are application rules for review completeness, not a measurement of the reviewers' competence or the report's legal accuracy.
Export then checks the broader state. A completed report payload must exist. The report's export-readiness gate for legal review, called counsel mode in the application, must be open. Its persisted review status must be approved, and the relevant finding decisions must pass. Additional evidence and drawing-governance checks can still block the operation. Passing one condition does not erase a failure in another.
This places the decision on the server. A disabled button can help explain why an export is unavailable, but the API must make the same determination from current records. The user may have left a tab open while the report changed or while another reviewer rejected a finding. The visible state needs refreshing; the backend cannot rely on the browser having noticed.
The interface has to explain the action needed to clear each blocker. An unavailable source needs investigation; a proposed correction needs to be addressed in the report; a decision on an old version requires renewed review. At the early checkpoint, the reviewer also needs to know what is absent from the brief and what will be computed afterwards. At final-report review, they need to see which finding and version their action applies to.
Walkthrough. Inspecting a fictional citation, saving a demonstration rejection and checking existing export blockers. The blockers are already present in the fixture; the clip does not show the rejection causing them or exercise backend persistence.
Walkthrough transcript
The 35-second recording uses the working interface in local demo mode. Example Molecule Alpha, its patent references, findings and reviewer are fictional.
- 0:00–0:03.5. The report opens with its demo banner and fictional compound identity.
- 0:03.5–0:10.8. A citation opens the source drawer, showing a fictional passage and its claim and element reference.
- 0:10.8–0:15. The reviewer opens the decision ledger and selects the second finding. Demo decisions stay in tab memory; no backend write occurs.
- 0:15–0:20.5. The reviewer chooses reject and types: “The fictional source does not establish this finding. Keep it out of the reviewed conclusion.”
- 0:20.5–0:25.8. Saving changes the interface to “Rejected” and retains that rationale beside the finding.
- 0:25.8–0:35. The reviewer opens the report's existing export blockers. These were present before the new decision; the clip does not exercise server enforcement.
The report's fixed overall counts and the interactive review panel's counts describe different fixture scopes. The recording demonstrates interface behaviour, not a provider-backed analysis or database persistence.
8. What the evidence establishes
The source and tests, synthetic application tour, provider-backed runs and vision experiments answer different questions. The tour shows how the review controls behave with fictional data; its decisions stay in browser memory. Provider-backed runs establish that retrieval and analysis executed for particular inputs. Vision evaluations measure recognition under their recorded conditions. None is a complete evaluation of the application.
For the review path, tests cover changed report fingerprints, stale findings and cases where reviewer state should block export. The source-span tests include tampering, missing support and cross-report replay. Their presence documents the expected behaviour; it does not establish that every deployment has passed them or that the legal interpretation in a report is correct.
A retrieval sweep across 50 named therapeutic compounds completed for 49, with one provider request failure. The completed searches returned 17,584 deduplicated and ranked patent hits. That is evidence that retrieval executed across those inputs. It does not establish that the search found every relevant family or that all returned records were relevant.
Crop recognition, detection and the complete page-to-structure path have separate results and denominators. The companion keeps them separate. It distinguishes the historical cached summary from the paired comparison calculated for this essay by rescoring stored structures. It also examines repeated inputs, sampling and missing historical configuration. These limits determine how far the measured recognition results can be generalised.
9. Tradeoffs and unfinished work
More recognition models add execution time, dependencies and licensing questions. On the 76 comparable recorded rows, the ensemble kept the best individual voter's 59 exact recoveries and added three. That count includes a repeated unsuccessful record; the companion shows the paired calculation and its limits. Deciding whether the gain justifies the extra models would also require measurements of their operating cost and performance on other material.
Abstention reduces the number of cases the system resolves automatically. It can also preserve the distinction between missing evidence and a negative finding. The corresponding product task is to make unresolved work visible and actionable. A pipeline that abstains responsibly but gives a reviewer no way to inspect the source has left the practical problem unfinished.
Detailed provenance creates more data to store and more relationships to maintain. In return, a challenged finding can lead back to a particular source and report version. The drawing handoff is the clearest unfinished connection: the selected claim agent needs the admitted structure and source context, while the evidence inventory needs to represent what the drawing supports. That requires image-specific contracts for the supporting crop, its transformations and what becomes invalid when the interpretation changes. The text-source relationships provide a starting point, but a higher recognition score would not repair those missing connections.
Authenticated checkpoints, event replay and execution ownership add operational complexity. A resumed worker, a reconnecting browser and a duplicate launch request each require different handling. The implementation separates them, but operating that design would also require testing the interruptions together and making failures diagnosable from the saved records.
The early and final review stages expose a related tradeoff. Binding a decision to a payload helps establish what was approved, but the early brief does not display everything covered by its digest, and later metadata has not yet been computed. A larger payload alone would not fix that mismatch. The reviewer needs a clear account of the visible material and the scope of the decision, while the application needs to preserve those limits when later content is added.
Hosted operation would need its own evidence: populated storage, realistic source delays, interrupted workers and observed recovery under load. The reference architecture provides places to measure those behaviours, but the measurements remained work to be done.
Compound A ends with a generated report and an edit decision that blocks export until the question about the proposed process is addressed. Recording the decision leaves the report text unchanged. If the researcher supplies the missing fact, the same patent passage can support a revised assessment without changing the source. The report fingerprint changes, so the old approvals cannot authorise the revised content. That is where keeping source evidence, interpretation and reviewer decisions separate has a practical effect: a correction can change one without silently carrying the authority of the others with it.
The open-source project contains the implementation, architecture documentation and recorded evaluation summaries. The companion essay, Reading chemical drawings: what Praviar’s vision system recovered, examines the recognition experiments and their limits.