The archive that decides who may read.
Zybald gathers a company's documents from five channels, reads them, classifies them with the company's rules and with a language model, and files them in the right folders. Its starting point, however, is not classification: it is confidentiality. Every document is visible only to those entitled to it, every read leaves a trace, and not even the person administering the installation can open a document without declaring it. On top of the archive works an assistant powered by a real language model, which searches and reads only what the person asking can already see.
Zybald is the evolution of Vdoc, rewritten on its own document engine.
unified
per folder
permissions are checked
no shared data
Design properties, not operating measurements.
Status, October 2026. Zybald is in development. This page describes the complete product: archive, public links, workflows, portal and assistant. Features go into service in stages, starting with the archive.
What Zybald does.
A document arrives: a PDF invoice, a signed contract, an email with three attachments, a spreadsheet, the photo of a till slip. Zybald records it, recognises whether it is already there, reads it, gives it a title, type, sender, date, the fields of its type and a summary, and places it in the folders set by the company's rules. From that moment on, only the groups with access to those folders can see it.
Three processes, one logic.
Zybald is organised around a logic layer that holds every rule: identity, permissions, archive, versions, search, log. Around it run three separate processes, so that a failure in one does not stop the others.
- The web service exposes the APIs to the interface and to the input clients.
- The worker runs the long jobs in the background: text reading, conversion of office formats and email messages to PDF, classification, indexing, notifications, consistency checks, and the assistant's answers, on dedicated processes so that a conversation does not slow down the archive.
- The channels receive email and bot messages.
When a document arrives, Zybald stores it and answers the channel straight away; reading and classification continue in the worker. An interrupted job resumes after a restart, because the job queue lives in the database.
The interface is an application that talks only to the APIs.
The journey of a document.
Whatever the channel, every document goes through the same seven steps. The first three happen at once, and the channel gets its answer; the others continue in the background.
- 1 · Intake. The channel delivers the file; Zybald computes its SHA-256 fingerprint.
- 2 · Deduplication. If the same content already exists, Zybald says so and creates no duplicate, whatever channel it originally came from.
- 3 · Archive. The file is encrypted and written; the document is born in the "Incoming" folder of its channel. The channel gets its answer.
- 4 · Reading. Local OCR on pages without text, with searchable text and a preview. Office documents become a PDF through LibreOffice, keeping the original; protected PDFs open with the passwords the owner has saved, or with a password given once by whoever holds the document.
- 5 · Classification. First the text rules written by the company, then the language model through AYXZA Relay: title, type, sender, date, tags, type fields, summary, related case. Rules prevail over the model, and what a person has corrected by hand is never touched again. Without a model, Zybald classifies with rules and the date read from the text.
- 6 · Placement. The company's rules, by channel, type and sender, move the document into the right folders; the documents of a case created from a template go to the subfolder that expects them. If no rule applies, it stays in "Incoming", visible only to those who manage it.
- 7 · Notification. The designated people receive a message. Notifications contain no document data, unless the owner explicitly chooses otherwise.
When the AI does not recognise the date or is unsure about the case, Zybald does not guess: it opens an issue that a person resolves, puts it in the "To check" view, and records who resolved it and when.
Five ways to hand in a document.
How a document enters a company depends on who sends it, from where and with which device. The five channels converge into the same path.
Every workstation and every device has its own access key, which can be revoked on its own without touching the others.
Accepted formats: PDF, password-protected ones included; JPG, PNG, TIFF, BMP, WEBP and GIF images, turned into PDF before reading; saved email messages (EML); and, where the installation has LibreOffice, Word, Excel, PowerPoint and OpenDocument office files (DOC, DOCX, ODT, RTF, XLS, XLSX, ODS, PPT, PPTX, ODP), converted to PDF without macros and without network access.
The engine that interprets.
When the company chooses it, Zybald uses AYXZA Relay, AYXZA's engine that makes the language model provider interchangeable. Changing model is a configuration, not a rewrite; a self-hosted model can also be used, through a compatible endpoint.
What the AI does
- It extracts title, type, sender, date, tags, type fields and summary from the content, without rigid templates.
- It reads email messages as text too.
- It recognises the sender even when written differently, with a second opinion when the similarity is uncertain.
- It proposes the case the document belongs to.
What the AI does not do
It does not decide who sees the document: visibility comes only from folders, levels and bans, rules written by people. It does not overwrite what a person has corrected, and it gives way to the rules written by the company.
Data sent to the AI
For classification, the document being classified, for the duration of the classification. For the assistant, the messages of the conversation and the text of only the documents the person has it read, always among those they can already see. Users, groups, permissions and log never leave the installation. Text reading happens locally; AI-based extraction is an option enabled only if the company chooses it.
A model that reads only what you see.
Zybald has an assistant powered by a real language model, not a search box in disguise. It opens from the header, next to the Archive, or from the "Ask" field on the Desk. The switch belongs to the owner: the assistant stays off until they turn it on, and whoever administers the installation does not use it.
The engine
The model is chosen by profile, according to confidentiality, cost and power, and AYXZA Relay routes it: Zybald does not know model names. Usage is counted per person.
Who may read, and how it is proven.
Confidentiality is not a setting: it is the way the archive, access and the log are built.
Export
Data is never held hostage. A server command produces an encrypted package with the originals in clear, ordered by folder, and the metadata, fields, links, notes and log in open formats; every export is logged and notified to the owner. The same package rebuilds an empty installation.
Declared limit
Whoever holds administrator privileges on the operating system can read what the machine reads: text reading and search need the content in clear while it is processed, and the text of the assistant's conversations, like the extracted text of documents, is stored in the database in clear. Zybald makes this access difficult, visible and traced within the application, but does not eliminate it, and states it in the contract.
The installation key
If it is lost, the files can no longer be read. At installation a copy is kept off the machine; the backup includes it only if the owner chooses so, because a backup with the key next to the files cancels the encryption for whoever steals it.
Test pages, in production too.
Test pages accessible only to the owner and the administrator, which write no data and can be used on the live archive. The rules page belongs to the owner alone.
- Health of the processes and fingerprint of the loaded key.
- Dry-run intake.
- "Why they see it / why they don't" comparison between two independent permission calculations.
- Search timings.
- Consistency between archive and database.
- Integrity of the log.
- State of the job queue.
- Fields, issues and "what is missing" in a case.
- Text rules applied as a dry run.
- Language coverage.
- Validity of a public link.
- Dry run of a workflow.
- Scope of an external portal user.
- Assistant, with counts only.
For those assessing the system from an IT standpoint, it is the way to check what it does without trusting the documentation.
What it includes.
The archive is the centre; public links, workflows, portal and assistant work on top of it, with the same permissions.
| Area | Content |
|---|---|
| Archive | Documents, virtual folders and tags, permissions with bans, versions, page operations, text reading, search, fields per type, cases from templates, saved searches, links, bulk editing, five channels, log, emergency access, export. |
| Public links | Link to a single document with mandatory expiry, optional password, read-only and revocable; a link always shows the version it was created for; a ban revokes existing links on its own. |
| Workflows | Graphical editor with parallel branches, conditions, tasks and automatic actions; three ready-made templates (simple approval, double approval, incoming registration); a task never opens the document to someone who cannot see it. |
| Portal | Accounts for clients and suppliers, by invitation only and with a second factor, with their own area, document upload and participation in workflows. |
| Assistant | Personal space, shared projects, confirmed memory, tools with the permissions of whoever asks. |
The tables for public links, workflows and portal exist from the first version of the schema: enabling them does not require migrating the archive.
What the company can change.
Every organisation has its own folders, groups and rules. They are adapted from the interface, without touching the code.
| Area | What can be changed |
|---|---|
| Users and groups | Invitations, suspensions, roles; group memberships managed by the custodian of permissions. |
| Folders and permissions | Folder tree, levels per group, bans with a reason. |
| Channels | Keys of workstations and devices, authorised email senders. |
| Placement rules | Destination folders by channel, document type and sender. |
| Text rules | Words and expressions that assign type, sender, tags and folder before the model. |
| Fields | Fields of each document type, and which ones the model proposes. |
| Case templates | Subfolders and expected documents of each type of case. |
| Instructions for the AI | Company context and classification criteria; the response schema stays locked. |
| Thresholds | Similarity used to recognise senders and cases. |
| Language | Installation language for search, text reading and AI; each person chooses their own interface language. |
| Protected PDFs | Passwords used to open incoming PDFs, stored encrypted. |
| Notifications | Who receives them and whether they may contain document data. |
| Assistant | Activation, default profile, active tools, automatic proposal of memories, retention of conversations. |
| Emergency access | Duration; the notice to the owner cannot be switched off. |
| Retention | Duration of the log (minimum twenty-four months) and of the bin. |
Every configuration change is itself an event in the log.
What lies underneath.
For those assessing the integration from an IT standpoint, a short view of the technical components.
| Component | Technology |
|---|---|
| Operating system | Ubuntu 24.04 LTS |
| Application | Python 3.12, Flask 3 with gunicorn, SQLAlchemy 2 and Alembic |
| Database | PostgreSQL 16, full-text search in Italian and in English |
| Text reading | OCRmyPDF and Tesseract, Italian and English |
| Email PDFs | WeasyPrint, in a separate process |
| Office formats | Headless LibreOffice, optional, without macros and without network access |
| Interface | Vue 3, Vite, TypeScript, in Italian and in English; fonts hosted in the installation |
| AI engine | AYXZA Relay, for classification and the assistant |
| Processes | Three systemd services with a dedicated system user |
| Reverse proxy and HTTPS | Caddy |
| Windows client | Windows program that sends the dedicated folder |
| USB Inbox | Raspberry Pi Zero 2W |
| Backup | Borg, encrypted, to a separate storage, with a restore test on a clean machine at go-live |
No mandatory external service other than the model provider, and not even that, if the company classifies with rules only.
What Zybald does not do.
Zybald is designed to file, classify and protect documents. It does not replace business tools with different responsibilities.
- It is not an ERP. It does not record accounting entries, issue invoices or manage due dates.
- It is not certified email (PEC), nor the Exchange System (SdI), nor compliant long-term preservation. It can receive by email copies of electronic invoices after they have been acquired through the ordinary channels.
- It does not delete on regulatory expiry. Tax and legal retention rules remain the company's responsibility.
- It does not forgive every typo. Search is precise on words; when it finds nothing, it suggests similar terms among titles, senders and tags.
- It does not serve several organisations in the same installation. Each client has its own.
- It does not read barcodes and does not number the archive with physical labels.
- It does not recognise near-identical documents, only identical ones.
- It does not yet connect to company single sign-on.
- The assistant does not browse the web and does not run code.
- It does not replace reading. The summary helps find a document, not decide on its content.