AI platform
tm.hub
An AI platform for business automation: modules that solve a specific task on a company's documents and data
The problem first. Then AI
- Role
- Platform from zero: architecture, engine, cabinet, infrastructure, launch
- Period
- August 2026, ongoing
- Team
- Solo, with AI
- Status
- In production, modules being added
- Link
- ai-tm.ru
How it works
01Choosing a module
A catalogue by area: design, construction, procurement, marketplaces.
02Upload
The module knows which documents it needs and checks them before the run.
03The check
Parsing, matching and rule checks — minutes instead of hours of reading.
04The ledger
Findings by severity and amount, each with its file, page and row.
05Verdicts
The customer marks what is disputed; those marks feed back into the rules.
What it is
tm.hub is a platform on which modules are assembled for specific working tasks: checking a design brief, reconciling completion certificates against an estimate, reading a marketplace settlement report, structuring an inbox.
What the modules share is not a subject but a structure: a cabinet, tenant isolation, one document engine and one shape of result. A new module is described by configuration rather than written from scratch.
Problem
Discrepancies in a set of documents are found by eye. An engineer reconciles a certificate against an estimate line by line, a buyer compares supplier quotes, a designer reads a brief for completeness. The work is mechanical and attention runs out before the document does.
Checking with a neural network does not close this: the answer looks convincing, yet a second run can differ, and it cannot be put in front of a counterparty — there is no telling where a figure came from.
How it is built
One engine serves every module: intake, normalisation, field extraction against a schema, the operation, the report. Each step stores its result, so a failed job restarts where it broke rather than from the beginning.
A module is a configuration: which documents are accepted, how rows are matched, which rules are checked, what reaches the report. There is no code for a specific module. If one becomes necessary, the contract has been broken — a reason to look into it rather than work around it.
Where the AI is, and where it is not
The rules are ordinary code. The same set of documents gives the same result today and in a year — otherwise the report cannot be used in a dispute. There are no confidence percentages in it: either a discrepancy exists and here is its source, or the row is not there.
The model comes in where structure does not exist — scans, free-form wording. It extracts fields; it does not pass judgement. The split is deliberate: the less model there is in the pipeline, the lower the cost, the more stable the result, and the easier it is to deploy inside a customer's closed perimeter.
The customer's data
The first objection to any document check is where the contents go. Tenant isolation is enforced by the database rather than by application code: a query physically cannot see another tenant's rows.
The retention period is the customer's choice, down to deletion immediately after the report. It is a mechanism with a background sweeper, not a line in the terms. For those whose rules rule out the cloud, the same system deploys inside their perimeter: one codebase, no rewrite to move.
How it works
01Choosing a module
A catalogue by area: design, construction, procurement, marketplaces.
02Upload
The module knows which documents it needs and checks them before the run.
03The check
Parsing, matching and rule checks — minutes instead of hours of reading.
04The ledger
Findings by severity and amount, each with its file, page and row.
05Verdicts
The customer marks what is disputed; those marks feed back into the rules.
06Export
An xlsx on three sheets: summary, discrepancies, verdicts.
What already works
- A module as configuration
- A new area is a set of rules in JSON, not a separate program.
- Cross-document checks
- Contradictions that are invisible in either document on its own.
- A source for every finding
- File, page and row in both documents — verifiable in a minute.
- Restart from the failure
- Each step's result is stored, so extraction is not paid for twice.
- Retention on your terms
- Down to deleting files right after the report, with a background sweeper.
- Isolation in the database
- Not in application code: another tenant's rows are physically out of reach.
- Cloud or closed perimeter
- One codebase; moving does not mean rewriting.
Interface
Checking from Telegram
The file goes straight to the bot and the result comes back as figures. The full ledger with sources and the export live in the cabinet.
The landing
A real check is put on the front page: 54 requirements, 17 findings, six critical — with a fragment of the report showing exactly where in the document the problem sits.
Module catalogue
Each module is one task and one set of rules. Document modules work on files; conversational ones live in a messenger.
File retention
Retention is the customer's choice, down to deletion right after the report. The promise sits in the interface rather than in the terms.
My role
Designed and built the platform end to end: the layer architecture, the document engine, the module contract, the cabinet, database-level tenant isolation, the infrastructure and the deployment.
Separately, the domain half of the first module: the rules for checking a design brief, including the ones that only surface when two documents are compared against each other.
Stack
- Application
- Python
- FastAPI
- Jinja
- HTMX
- Data
- PostgreSQL
- Row Level Security
- Redis
- Engine
- openpyxl
- python-docx
- очередь задач
- Infrastructure
- Docker Compose
- Traefik
- self-hosted
Current status
The platform runs in production: a cabinet, Telegram sign-in, tenant isolation, plans and payments, observability with alerts.
The first module was tested on a real set — a technical brief and a functional assignment for a data-centre design. Out of 54 parsed requirement rows it produced 17 findings, six of them critical: missing sections of the design documentation and contradictions between the two documents that reading either one alone would not reveal. Every finding was produced deterministically, with no language-model calls.
Results
54
requirement rows parsed from two documents
17
findings, six of them critical
0
language-model calls per check
What I took away
Separating extraction from judgement mattered more than the choice of model. Once the rules were computed by code, the report became reproducible — and could be presented rather than merely read.
The constraint that a customer's data must not leave shaped the architecture before any feature requirement did. It also turned out to be the strongest argument in a sale, and it was worth building in from the start rather than bolting on.
Substring matching is a poor basis for a rule: “section 7” lives inside “subsection 7”. Every cross-document rule had to move to regular expressions, and the quality threshold had to be measured by the share of false positives rather than judged by eye.