Company vault
Your knowledge in files you own
Every company gets its own folder on the server. Inside it there is standard Markdown, the original files you uploaded, and nothing else. The search index and the graph rebuild from that folder, never the other way round.
- Mode 0700 permissions
- Your binaries, exactly as uploaded
- Daily backup kept for 14 days
One folder per company, isolated by the filesystem
Creating a company creates its directory at mode 0700, owned by the server user. Another company's process cannot read it, and neither can an unprivileged system user. That is an operating-system boundary, not a condition inside application code.
- One directory per company, created at signup and reconciled idempotently
- Isolation does not depend on every query remembering to filter
- Optional: the same lifecycle over S3-compatible storage
- vault/
- c_9f2c…a71/
- sales/
- sales.md
- proposals/
- _personal/u_412/
- c_4b81…c30/
Disk is the source of truth
Search and the graph are derived indexes: delete them and they rebuild by reading the folder. The folder cannot be rebuilt from them, which is why it is the thing that gets backed up, copied and carried away.
- .md notes with [[wiki]] links and YAML metadata: they open in any editor
- The database is stock PostgreSQL, dumped daily
- Backup at 03:30, 14-day rotation and hard-link snapshots of the vault
- Index deleted accident or migration
- Reindex by reading the folder
- Same result nothing lost
A personal note is private, from the owner too
A note marked personal lives under its own folder, and one single service decides who can open it, the same service that answers for department notes. Company owner and administrator roles do not open it. Drag it out of that folder and it becomes a department note, and the server applies that on the move, not the browser.
| Document | You | Area lead | Company owner |
|---|---|---|---|
| Department note | Yes | Yes | Yes |
| Your personal note | Yes | No | No |
| Someone else's personal note | No | No | No |
| A note of yours that you shared | Yes | per the permission | per the permission |
Sharing adds access and never removes it
A per-file permission stacks on top of what the role already grants: read, write or delete. Because it only ever adds, sharing cannot lock out somebody who already had access, which is the classic access-list mistake. Granting is limited to the owner of a personal note, the department lead and the company administrator.
- Company role the floor
- Department seat the branch you work in
- Per-file permission adds only
Upload the original file and read it in place
Upload a PDF, a DOCX or an image and the binary is stored as is, with a companion note written next to it, and that note is what gets indexed. File type is verified by reading the first bytes rather than trusting the extension. After that it opens inside the application, with no download to your desktop.
- PDFs, DOCX files and images render on the same screen as the rest of the work
- A byte-identical re-upload is discarded instead of leaving you "file (2)"
- Deleting a folder is a soft delete: it goes to the Trash and restores without overwriting anything
---
title: Quito proposal 2026
source: quito-proposal.pdf
type: application/pdf
size: 2.4 MB
---
# Quito proposal 2026
The text of the PDF ends up here, searchable and linkable like any other note.
The original binary sits next to it, untouched.
What never enters the vault
Before indexing, anything regenerable and anything that should not be there gets dropped. Dependency folders, source histories and build output are filtered because they take up room and say nothing. Secrets are filtered for a different reason: so they are never stored and never searchable.
- On the test corpus, 188 MB and 7,250 files came out as 112 MB and 5,575 notes
- That figure comes from our beta corpus, not from a company in production
# regenerable
node_modules/ .git/ dist/ build/
*.lock *.map
# secrets
*.env *.pem *.key
*credential* id_rsa*
None of this reaches the index or the graph.
What it does not do yet
Two people cannot write the same note at once
There is no live collaborative editing. If two people open the same note and save, the last save wins, so it pays to have each person working on their own material. That is a scope decision and not an oversight: we would rather have a vault of plain files that open in any editor than a format with shared state.
In the meantime, the department conversation sits next to its notes, which is where in practice people sort out who is touching what.
Start free. Pay when it earns it.
Starter credit so you can try it against your own real documentation. No card and no sales call. If it works, you pick a plan.
- Starter credit on the house
- No credit card
- Every feature included