Projects P.05
A system for the company Teramex that turns company documents into searchable agendas: search, chat with page references, filling tables from the content of documents and deadline monitoring. I designed and built it on my own.
S.01
Teramex works with company documents, such as lease and insurance contracts or STK (roadworthiness test) protocols. The system I designed for them takes in the documents, reads them (scans too), sorts them into agendas, meaning registers of one kind of record, for example Vehicles or Insurance, and fills tables from them. You can search the documents and ask them questions in a chat.
The system is still in pilot operation.
S.02
An answer without a source cannot be checked. So the chat names the document and the page it took the information from, and the document opens from the answer. In the screenshot I ask how much is paid for early termination of a mini excavator lease, and the answer points to page 3 of the contract, where that condition is. The reference lets a person quickly check the figure right in the document.
It is not always possible to tell from a document with certainty which record the data belongs to, for example which vehicle. When the system is not sure, it does not write the data into the register. The record waits in the overview of pending records, which shows how sure the system is, and a person approves it, merges it with an existing one or rejects it. Ten are waiting in the screenshot. What goes into the register is decided by a person.
An STK, an insurance policy or a lease runs out and nobody notices in time. So the system watches date columns marked as a deadline and tells apart whether a deadline has already passed, is about to, or is fine. The agenda overview has an Expirace (expiry) panel that lists the watched deadlines from all agendas, ordered by how close they are. For deadlines you can set a rule for how many days ahead and through which channel the system should speak up, in the app or by e-mail.
S.03
S.04
A web app talks to an API that stores documents and records in PostgreSQL with a vector extension, and processing runs through a queue. The application and database run on the client's server, a local model computes the vectors, and an external language model handles reading, classification and answers. The external model can be swapped for a local one once the client decides to invest in its own hardware.
I describe how I build systems like this on the How I work page.