Every company has a document dump. invoice_final_FINAL_v3.pdf on someone’s desktop. Three quarters of supplier spreadsheets in Downloads. Customer lists in Drive that nobody remembers uploading. Inside those files sits the company’s actual data — accounts, expenses, orders, personnel records — but none of it is data. It’s files. You can’t search it, filter it, report on it, or link it to another record.
The classic way this data enters a system is well known: somebody opens the file, reads it, and types it in row by row. In small teams that job usually lands on the most valuable person, because they’re the only one who knows which line belongs where. Data entry is a tax nobody lists as a budget item and everybody quietly pays every month.
In our MindCro project we built a component that attacks this problem head-on: MindCro Bridge — a desktop app that runs silently in the background, captures documents in the folders you watch, parses them locally, and imports them into MindCro modules with your approval. This post walks through how it works and the architectural decisions we made along the way — because most of those decisions are the kind every team building document automation will face.
Context first: what is MindCro?
MindCro is an AI-first management dashboard platform where teams build their business processes by talking. You tell the chat “open a table for supplier tracking with these fields,” and the platform builds the table, kanban, or list for you. Every structure is a module: Accounts is a module, Expenses is a module, Projects is a module. We’ve written before about how AI is transforming business operations; MindCro is that idea turned into a product.
But no matter how smart the dashboard is, data still has to come from somewhere. The user’s daily reality isn’t the web panel; it’s the PDF on the desktop, the Excel from the accountant, the order export from the browser. Bridge is the bridge between that reality and structured modules.
The flow the user sees
You install Bridge and sign in with your company email — the app routes itself to the right company environment based on your email domain, so nobody has to memorize a server address. Then you pick the folders you want watched: Desktop, Downloads, the local Drive copy, a shared network folder — as many as you like.
From there:
- Capture. When a new file lands in a watched folder, Bridge picks it up and queues it. A notification drops from the system tray: “3 new documents waiting.” Close the window and the app keeps living in the menu bar.
- Analysis — but only when you ask. Files in the queue go nowhere on their own. When you hit “Sync,” the file is parsed locally and the AI, looking at the schema of your company’s existing modules, produces a plan: which rows should be extracted from this document into which modules?
- Preview and correct. The plan lands in front of you as a table. You can check rows individually, click any cell, and edit it in a drawer that slides in from the right. Records that already exist in the system are flagged as duplicates, so you never insert the same thing twice.
- Approval. When you hit “Apply” — and only then — the records are written to MindCro.
The part of this flow we like most is a single invoice feeding multiple modules. Upload a supplier invoice and the AI extracts the supplier record into Accounts, the amount line into Expenses, and the document record into Invoices — all from one read. We call it the multi-module cascade: one document, one pass, many targets.
What if the document fits no module? A module gets created.
The genuinely interesting scenario is when a document matches no existing module. Say your company has no structure for vehicle tracking, and you drop in a fleet list. A classic import tool gives up here: “no matching target found.”
The analysis layer behind Bridge doesn’t give up — it proposes a new module: “This looks like a vehicle list. Shall we create a ‘Vehicle Fleet’ module? Suggested fields: Plate, Make, Model, Inspection Date, Assigned Employee.” The proposal arrives complete with field types, the department it should attach to, and sample records already extracted from the document. Approve it, and the module is created on the spot with the records flowing in. The system isn’t just pouring data into an existing shape; it grows the shape itself by reading the document. No code, no form designer, no ticket to IT.
This is the natural extension of MindCro’s build-by-chat approach: in the platform you construct structure by talking; in Bridge, structure sprouts from the document itself — with the final word always yours.
Architecture: what we chose and why
Bridge is built on Tauri 2: a Rust core, the system WebView, and a React UI. The install bundle is about 10 MB — a tenth of what an equivalent Electron app would weigh. For a tool that runs in the background all day, a small memory footprint isn’t a preference; it’s a requirement.
Some of our decisions are general good practice; some are the product of expensive lessons:
Parsing happens locally, in Rust. .txt, .md, .pdf, .docx, .xlsx, .xls, and .csv files are read on the user’s machine. The raw file never goes to the AI — only extracted text and table structure do. That’s both a bandwidth decision and a privacy decision: knowing and limiting what you send to a model has become the core principle of data protection in the AI era. If the document itself never leaves your machine, it cannot leak.
Lazy parsing. We do not parse when a file is captured. A watched folder can receive a hundred files a day, and the user will import ten of them. Parsing plus the AI call runs as one atomic step when the user hits “Sync.” Not burning idle CPU and not paying for wasted model calls are two faces of the same decision.
Two separate approval gates — deliberately. AI analysis starts with one approval (because model calls cost money), and writing records happens behind a second approval (because it touches the database). Collapsing those two gates into one “magic automation” was tempting; we resisted. AI output is a proposal, not a verdict. Making human approval the spine of the flow rather than its decoration is the cheapest path to both user trust and regulatory defensibility.
Half files, twin files, same files. Folder watching sounds simple; it isn’t. Catch a large file mid-copy and you read half its content — so file events are processed only after a 1.5-second quiet window. The same document can sit in two folders or under two names — so every file is hashed with SHA-256 and identical content is never imported twice. The queue lives in an on-device SQLite database running in WAL mode; pending work survives an app restart.
All API traffic leaves from Rust. The React UI makes not a single fetch call; every HTTP request is issued from the Rust core. The session token is stored in the macOS Keychain, Windows Credential Manager, or Linux Secret Service — the UI layer never touches it. The principle we argued for in our secure application development post applies here too: the layer where secrets live and the layer where the UI lives should not be the same place.
Large documents are chunked and analyzed in parallel. Feeding a five-hundred-row Excel to a model in one request fails in one of two ways: the output gets truncated at the token limit, or the request hits a timeout. The analysis layer splits the document into chunks, processes them in parallel, and merges the results; model output is captured through a forced tool call (structured output) rather than free text, which eliminates the “truncated JSON” error class entirely. This analysis work lives in a dedicated AI gateway service, not inside the API — a small but clean example of drawing service boundaries along responsibilities: the gateway’s job is AI, the API’s job is data.
Distribution is automated too. macOS (Apple Silicon + Intel) and Windows packages are built by a GitHub Actions matrix on every desktop change that touches the main branch, and the app silently updates itself when a new release ships. A desktop app’s delivery pipeline demands no less discipline than a web service’s — it demands more, because you can’t roll back what’s already on a user’s machine.
Why this matters: data entry is a product problem
Document automation is usually framed as an OCR/technology problem. Our conclusion is different: it’s a trust design problem. If users know that nothing gets written to the database before they see what the AI extracted from their document, they use the system. If they don’t, even the most accurate model loses to the nagging question “what did it just do?”
That’s why every design decision in Bridge serves the same principle: the machine reads, the human approves. The preview table, row selection, cell editing, duplicate flags, the two-stage approval — all different phrasings of the same sentence. And the principle scales: it works for a single document, and it works for bulk sync, where twenty documents are analyzed in parallel and approved together in one preview.
The same data also shows up instantly in MindCro’s mobile app — the invoice you approve at your desk appears as a record on your field team’s phones. That’s the bridge’s real value: a document stops being a file and becomes a living record the whole team can access, filter, and build work on.
For your own document chaos
You can explore MindCro and Bridge at mindcro.com and request a demo; the project also lives in our portfolio.
For broader needs: if you want a similar “capture → parse → propose → approve → write” pipeline built into your own systems — whatever your document sources, data model, and compliance requirements — talk to us. One conversation is enough to establish which parts of this architecture fit your problem.
Your documents can stop living in folders. Your data can start working.
