A local collection.
The original version returned documents from a locally indexed Ukrainian patent collection, with a separate link to the official search site.
Engineering for lawyers
Make legal work behave like a system.
We map the judgment, decisions, data and documents inside recurring legal work—then build a calmer way to run it.
Request
Facts
Judgment
Decision
Document
Memory
Working model
Legal
engineering
engineering
Judgment in.Friction out.
Built here. Tested in the open.
From a local index to a connected patent search.
A real HRNFTR project. Describe a technology, let the system retrieve and organise candidate patents, then review the underlying sources.
One reviewable workflow.
We connected EPO retrieval, added relevance filtering and patent-family grouping, and brought candidate results and source links into one interface.
Observed result · 7 September 2026
4candidate results returned
2sources queried
14 secobserved response time
One live test, not an average or a promise. Results and timing vary. We have not measured client time savings or the completeness of the search.
See exactly what we tested
Input: “A solar panel mounting system that tracks the sun using a motor and light sensors.” Scope: all jurisdictions, no date restriction. The local NIPO index and EPO OPS were queried; all four displayed candidates came through EPO.
The measured response took 13.978 seconds, including network and provider time. These are search candidates for review, not a patentability or freedom-to-operate opinion.
Who this is for
Legal engineering for law firms and in-house teams
For law firms, in-house legal teams and transaction teams handling recurring requests, documents and approvals. A good starting point is one repeated task with identifiable users, source material and someone responsible for the outcome.
The work and what you receive
Workflow architecture
Replace unclear hand-offs with an agreed intake form, routing rules, matter statuses and ownership map. Your team can see what is missing and who needs to act next.
Decision systems
Turn approved policies and playbooks into documented rules, exception routes and review checkpoints. Deliverables include the decision logic and test cases that show how it behaves.
Knowledge infrastructure
Structure precedents, matter information and source documents so they can be found and maintained. Agree access rules, document owners and a process for updating the material.
Responsible automation
Build a focused document assembly or integration workflow using agreed templates and data. Deliver a tested first version, operating instructions and a defined point for human approval.
Working together
From the first conversation to delivery
See the work
Walk through a recurring task and representative, appropriately shared examples. Identify users, decisions, exceptions and data access needs.
Agree the first version
Set the deliverables, fees, responsibilities and acceptance criteria. Decide what the workflow should automate and what a person must approve.
Prove the system
Build and test one complete path, including missing data, exceptions and failure recovery. The team reviews the result before wider use.
Make it ordinary
Hand over the configuration, instructions and ownership. Agree support and maintenance separately, and compare the result with the starting process.
Do we need to replace our existing software?
Not necessarily. We first assess the tools and approved templates you already use. The proposal should explain which parts can stay, where an integration is useful, and whether a new component is justified.
Start with the problem
Show us the recurring friction.
A rough description is enough. We will suggest the smallest useful first step.