OfficeBrief: Architecture & Technical Reference

OfficeBrief is a desktop file manager with six built-in document tools: a dual-pane browser, full-text content search, OCR, document conversion, template-based printing, and archive handling, plus an optional smart-card scanner. It is an Electron desktop application — there is no server component, no account system, and no network dependency for any feature.

This document describes the architecture and data flow of each tool so a security or procurement reviewer can evaluate the product without relying on marketing claims.

The application is built on Electron, pairing a Chromium-based UI shell with a local Node.js process that performs the actual file and document work. The interface is built in Angular 20 with TailwindCSS 4 and PrimeNG 19; document jobs run as asynchronous local tasks with progress reporting and cancellation, rather than blocking the UI thread.

There is no client-server split in the network sense: the 'backend' is a local process on the same machine as the UI, communicating over Electron's IPC, not a network socket.

• Desktop runtime: Electron 34
• UI: Angular 20, TailwindCSS 4, PrimeNG 19
• Drive discovery and file operations run natively per OS (Windows, macOS, Linux)

The browser lists drives and folders natively per platform and supports side-by-side panes for copy, move and batch operations. Batch jobs (copy, move, delete, convert, rename) run asynchronously with live progress and a cancel path, rather than as one blocking operation.

Browsing and previewing are read-only: nothing is written to disk until an explicit action — copy, move, rename, delete, convert — is confirmed.

Content search performs case-insensitive plain-text substring matching across document bodies. It is not semantic search: there is no embedding model, no vector index, and no ranking by meaning — a match is a literal string occurring in the extracted text.

Text is extracted per format using dedicated libraries: Mammoth for DOCX, pdf-parse for PDF, and officeparser for other Office formats. Binary, video and audio files are skipped. Because extraction and matching both happen in-process, no document content is sent anywhere to be searched.

Optical character recognition runs on Tesseract.js, an open-source, deterministic OCR engine — not a large language model. Tesseract.js runs entirely in-process; an image is read in and text is read out, with no network call in between.

Supported input formats are PNG, JPG, JPEG, BMP, TIFF and WEBP. An image-quality pre-check (orientation and script confidence) runs before recognition, so a badly rotated or low-quality scan is flagged rather than silently producing poor text.

Recognition currently covers English text. Additional language packs are on the roadmap; we don't advertise a language mode until it's fully wired into the product.

Conversion between PDF, HTML, DOCX and TXT is performed by LibreOffice, invoked headlessly as a local subprocess. There is no cloud conversion API in the path — the same LibreOffice engine that powers a desktop office suite runs the conversion on the machine running OfficeBrief, and can be batched across a whole folder in one job.

Template printing uses docxtemplater. A user selects a .docx file containing placeholders in the form {fieldName}; OfficeBrief scans the document and lists every placeholder found, the user maps each one to a value, and docxtemplater renders the filled document, which is then sent to the system print pipeline.

Field mappings can be saved as a named, reusable template. There is no bulk mail-merge mode (one document per spreadsheet row) in the current version — each print job fills and prints one document at a time.

A mapped field's value can be typed manually or, when a smart-card reader is attached, populated directly from a card scan (see below).

Smart-card support uses PC/SC (via pcsclite) to detect a connected reader. On detection, OfficeBrief invokes a small platform-native helper component (a separate executable per platform) that performs the actual card read and returns the card's data as a structured response; that response can then populate a print template's fields.

If no reader is attached, the integration is simply inactive — the rest of the application is unaffected, and no error is surfaced to the user. Card data is used only to fill the active template in memory; it is not stored, logged, or transmitted anywhere.

No tool in OfficeBrief makes an outbound network call as part of normal document processing. There is no telemetry collection, no usage analytics phoning home, and no account or login system to manage. Documents, scans, templates and card data all stay within the boundary of the machine and the storage locations the user points the application at.

Because of this architecture, OfficeBrief does not give an organization a reason to fail a HIPAA or GDPR data-residency review on the file-management layer — data sovereignty is a property of how the product is built, not a configuration a customer has to get right.

OfficeBrief ships as a native desktop application for Windows 10+, macOS 12+ and Linux, distributed as a perpetual, machine-bound licence. Free, Pro and Enterprise tiers differ in usage ceilings (batch size, OCR throughput, smart-card access, volume licensing) and support — every tier runs the same underlying engine, with no feature withheld behind a separate, less-audited code path.