I want Kaliits to become a leading document-intelligence solution in Morocco. The goal is to remove a substantial amount of repetitive paperwork from logistics and finance, while keeping the decisions understandable to the people responsible for them.
That is an ambition, not a market-position claim. I still have to earn it through useful implementations, representative evaluation and evidence from the teams using the work. Saying what I hope to build is different from saying I have already achieved it.
Why documents became the starting point
The first OCRAgent workflow picked up documents from inboxes, read them and compared them. As the idea grew, I could see several possible applications around that same foundation: purchasing checks, import dossiers, ERP handoffs and email tasks driven by document information.
Logistics and finance are the industries I want to serve because those applications connect to their work. I do not need to claim that every company shares the same pain. I need to find a specific recurring process where the proposed change can help.
Why I put the engineering on GitHub
I made the repository publicly available so people could inspect the work, learn from the design and discuss it. I want OCRAgent to be part of a technical conversation, including its limitations and the choices I may need to change.
There is a licensing detail worth stating clearly. The repository currently uses the PolyForm Noncommercial License 1.0.0 and provides a route to request a separate commercial license. Publicly available source does not mean unrestricted commercial reuse. The repository's stated terms govern that use.
Read the repository and its license information
Community work and commercial work have different jobs
The repository can show how I approach document intelligence. A commercial engagement has to address a team's process, access, permissions, data handling, integrations and acceptance criteria. Those obligations do not disappear because source code is available.
Kourchal is where I explain what I am building and what I am learning. Kaliits is where the commercial conversation belongs. Keeping those roles clear lets me share technical work without presenting every experiment as a finished customer solution.
The paperwork I want to remove
My interest is in repeated entry, chasing missing documents, comparing references and preparing the next action. For an illustrative case, that might mean assembling the evidence behind a purchasing mismatch so a reviewer does not have to reconstruct it from several places.
Removing paperwork should also mean avoiding new work created by the tool. If a system produces too many unnecessary warnings, needs constant corrections or requires another round of manual entry, the improvement is incomplete. The evaluation has to include the person doing the job.
Reality has already changed the questions
At SIEMA, a conversation shifted my attention from comparing document values to the evidence of what physically arrived. In the Jev experiment, I overruled a high-fit signal because internal software could not remove the required physical inspection.
Both experiences pushed me toward a more precise question: which part of the problem can the proposed software influence? I want that discipline to shape Kaliits as much as the architecture does.
Read the SIEMA reflection on physical-delivery evidence
Read the Jev experiment and human review
What progress should look like
For me, the next useful proof is a bounded workflow that a team can evaluate against its previous process. The questions include correction effort, time spent resolving exceptions, source evidence and whether the agreed handoff works.
I want the ambition to stay big while the claims stay specific. Becoming a leading solution will require repeated proof that the work helps. The place to start is one recurring document problem, a responsible owner and a pilot whose result the team can judge.